Requirements, or
How do I know the Project is Done?
The PMI “2014 Pulse of the Profession Study” found 37% of organizations blamed inaccurate requirements as a primary reason for project failures. The PM Solutions 2011 study, “Strategies for Project Recovery” found that requirements issues were the # 1 reason for troubled projects. Looking at these and previous studies, the trend is clear. The systemic problem of writing requirements that result in successful project completion has not been resolved.
According to the Project Management Book of Knowledge (PMBOK) a requirement is,
“A condition or capability that must be met or possessed by a system, product, services, result of component to satisfy a contract, standard, specification or other formal imposed document. Requirements include the quantified and documented needs, wants and expectations of the sponsor, customer and other stakeholders”.
Requirements should possess each of the following traits:
Unambiguous, measurable, testable, traceable, complete, consistent and acceptable to stakeholders.
All requirements should be documented in the following reports:
· Project charter
· Stakeholder register
· Requirements document
· Requirements management plan
· Requirements trace matrix.
Regardless of how well written the requirements, the project manager still has to face these dilemmas:
• Schedule, cost, people/technology/material resources limit what can be done
• Sponsor assumes what customers want
• Customers don’t know what they want/need/how to use until they try it
• Sponsor/stakeholders don’t know what technology can/can’t do
• Integration issues not identified
• Communications
There are well-known root causes for poor requirements and failed projects. A partial list includes the following:
· Multiple groups involved in requirements process: user/customer, marketers, business analysts, project manager, project workers (programmers, builders, etc.), sponsors, stakeholders
· “Interpretation of the elephant” (how does customer, stakeholder, marketer, sponsor, developer see the product/service)
· Communication failures
· Failing to consider integration with existing products/services or planned products/services
· Changing requirements without consideration of impacts on the project
· Funding/schedule/resource constraints
· Failing to manage change/requirements
Individually and collectively, the root causes will affect cost, schedule, risk, resources, personnel, quality, production, support, training, sub-contracting, marketing, and configuration control. All of these either individually, or a fatal combination, can spell disaster for any project and project manager.
Knowing how to reduce the impact of poor requirements and how to manage requirements during the project life cycle are key project manager knowledge and required skills. Key to the entire requirements process is developing and implementing the requirements management plan. (Note: a template is available at Project Management.com as well as other sites/resources). The plan defines how to address requirements during the project life cycle. The plan should include: how requirements are planned, tracked, and reported, configuration management, prioritization, metrics, and traceability.
A requirements traceability matrix (see example below) should include traceability to:
· Business needs, opportunities, goals, objectives
· Scope/Work Breakdown Structure
· Design
· Product development
· Test strategy
· High to low requirements
Common methods for requirements definition include:
· Brainstorming
· Expert analysis
· Delphi techniques
· Interviews
· Mind mapping software tools (see Google search for list of products).
In summary, requirements definition is still much of an art. There are tools and processes to help customers/sponsors/stakeholders/project teams make the definition process more of a science. However, each project requires unique methods and each project manager must keep the toolbox full with the latest information to use in creating the best requirements for the project team.
Links: http://www.projectmanagement.com/tools/
How do I know the Project is Done?
The PMI “2014 Pulse of the Profession Study” found 37% of organizations blamed inaccurate requirements as a primary reason for project failures. The PM Solutions 2011 study, “Strategies for Project Recovery” found that requirements issues were the # 1 reason for troubled projects. Looking at these and previous studies, the trend is clear. The systemic problem of writing requirements that result in successful project completion has not been resolved.
According to the Project Management Book of Knowledge (PMBOK) a requirement is,
“A condition or capability that must be met or possessed by a system, product, services, result of component to satisfy a contract, standard, specification or other formal imposed document. Requirements include the quantified and documented needs, wants and expectations of the sponsor, customer and other stakeholders”.
Requirements should possess each of the following traits:
Unambiguous, measurable, testable, traceable, complete, consistent and acceptable to stakeholders.
All requirements should be documented in the following reports:
· Project charter
· Stakeholder register
· Requirements document
· Requirements management plan
· Requirements trace matrix.
Regardless of how well written the requirements, the project manager still has to face these dilemmas:
• Schedule, cost, people/technology/material resources limit what can be done
• Sponsor assumes what customers want
• Customers don’t know what they want/need/how to use until they try it
• Sponsor/stakeholders don’t know what technology can/can’t do
• Integration issues not identified
• Communications
There are well-known root causes for poor requirements and failed projects. A partial list includes the following:
· Multiple groups involved in requirements process: user/customer, marketers, business analysts, project manager, project workers (programmers, builders, etc.), sponsors, stakeholders
· “Interpretation of the elephant” (how does customer, stakeholder, marketer, sponsor, developer see the product/service)
· Communication failures
· Failing to consider integration with existing products/services or planned products/services
· Changing requirements without consideration of impacts on the project
· Funding/schedule/resource constraints
· Failing to manage change/requirements
Individually and collectively, the root causes will affect cost, schedule, risk, resources, personnel, quality, production, support, training, sub-contracting, marketing, and configuration control. All of these either individually, or a fatal combination, can spell disaster for any project and project manager.
Knowing how to reduce the impact of poor requirements and how to manage requirements during the project life cycle are key project manager knowledge and required skills. Key to the entire requirements process is developing and implementing the requirements management plan. (Note: a template is available at Project Management.com as well as other sites/resources). The plan defines how to address requirements during the project life cycle. The plan should include: how requirements are planned, tracked, and reported, configuration management, prioritization, metrics, and traceability.
A requirements traceability matrix (see example below) should include traceability to:
· Business needs, opportunities, goals, objectives
· Scope/Work Breakdown Structure
· Design
· Product development
· Test strategy
· High to low requirements
Common methods for requirements definition include:
· Brainstorming
· Expert analysis
· Delphi techniques
· Interviews
· Mind mapping software tools (see Google search for list of products).
In summary, requirements definition is still much of an art. There are tools and processes to help customers/sponsors/stakeholders/project teams make the definition process more of a science. However, each project requires unique methods and each project manager must keep the toolbox full with the latest information to use in creating the best requirements for the project team.
Links: http://www.projectmanagement.com/tools/