I think it is safe to say that everyone that leads or is part of a product development project starts out with the intention of delivering a winning product. We define a winning product as a product that delivers what is needed, with the expected quality, within schedule and budget constraints.
To deliver winning products, all product development projects should be driven by tenets that are derived from the Agile Manifesto: “Deliver working products that meet the customer’s expectations.”
As to delivering products that meet the customer’s expectations, we are often asked:
- How do you know what is needed?
- How do you know what the customer’s expectations are?
- How do you know what the expected quality is?
- What is a working product?
Our answers:
- Requirements!
- Requirements!
- Requirements!
- A product that meets requirements and the customer’s expectations!
Whether your project approach is Agile, Incremental, Spiral, or Waterfall, our answer remains the same…REQUIREMENTS! (See my blog “The Lean, Agile Project Manager” for more detail on these various approaches as well as hybrid approaches to product development.)
I get it…you want more than a one-word answer, so let’s take the first three questions:
How do you know what the customer expectations are, what quality is expected, and what is needed?
Answer: You define scope before writing requirements. You work with the customer and other relevant stakeholders to understand the problem the product is to address (or opportunity you want to pursue), the features, capabilities, functions, and performance characteristics that are expected. To do this you need to develop and get stakeholder agreement upfront as to exactly what the overall “Need” is, the goals to meet that need, and the objectives that, when met, result in the goals being achieved. Defining the Need, Goals, and Objectives (NGOs) in a very simple and concise manner, helps align everyone to a common vision. What happens if the developers don’t understand the customer’s vision? Failure to meet the customer’s expectations! What happens if the customer has one vision and the developers a different vision? Failure to meet the customer’s expectations!
Once you have defined the NGOs, your team needs to work with the customer and other stakeholders to define the drivers and constraints that need to be addressed by the product solution. These include understanding which standards and regulations you need to be compliant with, higher level requirements (including business requirements) that apply or have been allocated to your system, interactions (interfaces) with other systems, and the technology, cost, and schedule constraints.
Then, within the identified drivers and constraints, your team needs to work with the customer and other stakeholders (internal and external) to come up with at least one feasible concept that will result in the NGOs being met within the identified drivers and constraints. This activity needs to be done upfront before requirements are written. Common methods to gain this knowledge include use cases, stories, scenarios, system concepts, etc. As part of this effort, prototypes (some design) may need to be developed in order to understand 1) what is possible and 2) what the customer and other stakeholders really need and expect. These scope definition activities are needed to gain the knowledge you need to write requirements.
Keep in mind, that there is no expectation that you have to (or even can) define scope and requirements for the entire system and subsystems or modules that make up the system at the beginning. Systems Engineering is a recursive and iterative process. You look at your system like layers of an onion. You start with the first layer, then the next and the next, iteratively and recursively. For more guidance on this translation process see my blogs “Going from system concepts to requirements.”
With a solid foundation of knowledge and a common vision, the next step is communicating customer and stakeholder needs and expectations to the developers clearly and unambiguously. The tried and true method of accomplishing this communication clearly and unambiguously is through well-formed requirements.
From a requirement-driven product development standpoint, the requirements are what the developers design to, build to, and test to. The requirement set represents a contract between the developing project and the customer. To protect the developers from requirement creep and to protect the customer from the developers delivering a product that is not what they need and doesn’t work, you need a well-formed set of requirements.
Looking at this from a contract standpoint, there needs to be a set of requirements between your project and the customer as to what the expected outcomes are. These are best communicated via a set of requirements that both sides agree to. Agreement to the set implies the requirements are needed, clear, unambiguous, verifiable, and achievable (cost, schedule, technology). If the requirement set doesn’t have these attributes why would you sign the contract and agree to implement them?
For help with developing well formed requirements and sets of requirements send me an email at info@argondigital.com and I will send you a copy of our “Checklist for Good Requirements”.
When baselining your requirement set make sure the customer signs off on the requirement set. This baselined set of requirements is then an agreement with the customer that if your developers deliver a product that meets the requirements, the customer will be satisfied. Failure to get a sign-off from the customer can lead to scope creep as well as the likelihood you may deliver a product the customer is not satisfied with.
With a baselined set of requirements, all design efforts and reviews will focus on how well and to what extent the design addresses the requirements. With confidence that this is true, the product can be developed based on a requirement driven design process.
Now for the last question:
How do you know if you have a working product to deliver to the customer?
Answer: Once the product is built, you need to address the question: “Does the designed and built product meet the agree-to requirements?” The way you prove this is system verification. To complete system verification your organization must plan for and execute a verification process that addresses each requirement and shows proof that the product does meet (or exceed) the requirements. Common methods used for verification are not only test, but also demonstration, inspection, and analysis. To learn more about this process see my paper: Thinking Ahead to Verification and Validation.
The final step is system validation – making sure the designed, built, and verified system meets its intended purpose in its operational environment. Where did you define the product’s intended purpose and it operational environment? At the beginning!! This was during scope definition where you took the time to learn what the customer expectations were, what was needed, and what quality was expected.
Following this requirement-driven product development approach no matter what development approach you choose to use will lead to success rather than failure – it will go along way to help you deliver a winning product – the first time.
As always, comments to this blog are welcome.
If you have any other topics you would like addressed in our blog, feel free to let us know.
