The foundation for successful project management!
The foundation for successful project management is being able to express your stakeholders (users, re-sellers etc.) most critical requirements. Stakeholders have requirements at the level of the improvements they expect to gain for themselves (i.e. savings, better customer relations), and at the level of the product (i.e. improved usability, security etc.).
Most conventional requirement methods are so weak, in so many respects, that everyone involved in writing and reading requirements are uncomfortable with the process. Something is clearly wrong, but people struggle to explain how requirements should be written.
We tackle the Requirement process head on. Grouping the Requirements at the appropriate levels (Stakeholder, Product, Sub-Product etc.). Categorizing the Requirements into logical and useful types (Function, Scalar, Constraints etc.). We optimize the description of the Requirement according to level and type (Functions without Design, Product Qualities quantitatively with Past, Tolerable & Goal levels, etc.). To manage and relate the Requirements, we use a set of parameters attached to each requirement (Version, Stakeholders, Impacts, Assumptions, Risks, etc.)
And finally we teach the art of raising the whole Requirement process from 1000 sub-requirements to a few critical Requirements that serve as the main guidance to the whole project.
Gilb's Requirement method is a real wake-up call for all software managers, and provides an exciting tool for all types of project managers and engineers.
Requirements, the root to failed projects.
Professor Peter Morris, in The Management of Projects found that problems with requirements were top of the list of why projects had problems. Projects in NASA found that they could reduce project overruns substantially (30% to 130% overrun to 10% to 20%) by investing 5%-9% of the total project time on requirements as opposed to 0.5% to 4%. Investing enough in good requirements has a clear payoff. However, it is not a matter of quantity of time spent but how well the time is spent getting the requirements right.
To be competitive, focus on Stakeholder Value Requirements as well as Product Quality Requirements, and Development Resource consumption.
When we buy something, like a car, the core function (what the system does) is a given. The system must simply have the core function, in order to be in that particular market .
Function = a place in the market.
Then we evaluate the product qualities. In a car we might look for style, performance, cost of ownership, comfort, safety, etc.
Quality = better or worse, quality; which differentiates products.
Then we look at price, and our budget.
Qualities/Cost = Competitiveness
This is the most advanced and comprehensive requirements specification technique.
This requirements method is distinguished from others by its ability to integrate multiple quantified quality and cost requirements with functions and constraints.
This method permits and encourages detailed specification of requirements so that requirements can better assist us with risk management, prioritization, estimation, design, quality control, and project management
These methods are well defined in our Competitive Engineering and Evo - Evolutionary Project Management & Product Development books.
Specify top level Stakeholder Value and Product Quality requirements quantitatively.
Integrate multiple stakeholder values and product quality requirements, together with multiple development resources, and multiple constraints.
Planguage (our planning language) is based on well-defined rules for specification, on numeric process entry and exit conditions, on well-defined engineering processes, and well-defined concepts (see Concept Glossary).