An assumption that is often made by many people is that if the proper training is provided, an organization will be able to produce winning products – products that deliver what is needed, within budget, on time, and with the necessary quality.

Personally, I feel this is a false assumption…one often propagated by companies that only do training.  The same is true of tool vendors – adopt their tool and all your problems will be solved; as well as proponents of various processes – adopt model-based a systems engineering or an agile development approach and all your problems will go away!

I recognize that while training, tools, and processes are all important, they may only address a part of the problem.  How easy is the tool to use, what is the learning curve, how well does it fit with your overall process? Is the tool compatible with your development approach?  Is the development approach compatible with your product line, customers, or organizations’ culture?  Training is necessary but is not sufficient if you have a process issue or have not provided your team the proper tools needed to implement your process.

Capability thinking

So, to my question…”is training sufficient to developing a winning product?  My opinion?  No, no it is not.  In order to be successful, you need to look at the big picture.  What is the capability you need?  Viewing this as a capability issue, you need to consider what is needed to provide a capability: people, process, and tools within the context of your specific organization and domain.  Focusing on just one, and failing to address the others can lead to failure.  It is like a puzzle where all the pieces need to fit together to successfully complete the puzzle.  Training the people, but not having a well defined processes and not providing the team with the correct tools, will not solve your real problem!

While my focus is on requirements, I understand how requirements fit into the big picture and believe that requirements are the common thread that ties all product development activities together.  Because of the importance that requirements play, a major reason why projects fail is poorly written requirements. Having poor requirements places projects at risk of significant cost overruns, schedule delays, and performance shortfalls.  However, poor requirements are not the only reason projects fail to deliver a winning product. You can read my paper on risks and requirements to better understand the impacts requirement issues can have on your ability to deliver a winning product.

Reasons why projects fail

Usually, when a client asks for requirement training, whether our generic classes or tailored classes, I find their issue is more than just a poor requirement issue.  Other common issues are shown below.  (Click here for a checklist you can use to assess your overall process and determine which areas need improvement.)

1. Failure to properly define the problem the product is addressing
2. Failure to establish a vision (need), goals, and objectives that clearly communicate the stakeholder expectations
3. Failure to include all the relevant stakeholders
4. Failure to address all the drivers and constraints
5. Failure to define at least one feasible (cost, schedule, technology) concept that will result in the need, goals, and objectives being met within the defined drivers and constraints.
6. Failure to address all the interfaces – both between the system being developed and other systems as well as the interfaces between the development organization and other groups within and external to the company.
7. Failure to understand that the requirement set forms a contract between the organization and the stakeholders (internal and external)
8. Failure to come up with a design that will result in the system defined by the requirements. (Traceability)
9. Failure to define and plan for verification and validation– especially underestimating the cost and schedule associated with these activities.
10. Failure to understand the relationship between requirements at the various levels in the system/product hierarchy. (See our blog “Layers of Requirements above the System Layer” to learn more on this topic.)
11. ……………………

As one can see, this list involves activities that occur across the entire product development life cycle.  So even if a company has trained their team to produce a well written set of requirements, there may be other issues in the company’s development process that will keep them from delivering a winning product.

Seeing the pink elephants

Often, these other issues are the “pink elephants” that few within an organization want to admit are in the room.   However, if you want to deliver a winning product, you need to take a capability view and look at the big picture and look beyond just training and identify the areas in your organization that need improvement.  It may be just a training issue, but it also may be a process or tool issue.

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 via our “Ask the Experts” page and we will do our best to provide a timely response.