The Big
Project
Requirements Management
By: Mark Pendergast, PMP
For Project Managers
What are requirements?• A key element of scope• The things a solution must do• The way the solution must do them• The results the business needs to achieve• They are the immediate goal of the project
• There are many types of requirements?
Functional• The things the solution must do• Transactions• Reports• Business Rules• Security• Information Retention • Interfaces• Administration
Non-Functional• The way the system must do things• Performance• Usability• Capacity• Scalability• Availability• Supportability• Reliability• Fault tolerance• Disaster Recovery• Corporate Standards Compliance
varooom
Business• Cost• Timing• Level of Risk• Organizational change• Business results internally• Business results in the marketplace• Regulatory Compliance
Why should the PM worry?• Key element of one of the legs of the “Iron Triangle”
(Scope)• Directly drive the business benefit of the project• Must be held ‘constant’ throughout project Phases• Huge translation effort from ‘business’ to ‘technical’
requirements• Defects are difficult to identify• It is one of the key measurements of when the project
is done!
• How do I know if I have ‘good’ requirements?
Fidelity• Key quality of ‘Good’ requirements• Venn Diagram – should be 100% overlap• ‘Needed’ area is omission• Risk to project success
• ‘Requested’ area is distraction• Waste of project resources
• Dependent on stakeholder knowledge and viewpoint
Needed
Requested
Fidelity
Alignment• Key quality of ‘Good’ requirements• Venn Diagram – should be 100% overlap• Non-Alignment areas lead to conflict• These impede sign-off of requirements• Can add to the ‘Requested’ area of Fidelity
• Can cause frustration and disengagement• Dependent on stakeholder dynamics and personalities• Difficult because most stakeholders don’t know the
whole
Stakeholder 1
Stakeholder 2
AlignmentStake-holder 3
Stake-holder 4
Iron Triangle
Scope• Requirements are a huge part of scope• Requirements drive activity to meet the requirements• The activity creates deliverables• The deliverables must be validated against the
requirements• The project must deliver all that is needed (fidelity)
and should meet all stakeholders expectations (alignment)• Requirements must be actively managed though the
entire project • Scope should be controlled with change management
Schedule• Requirements management will impact the project schedule• Key schedule elements are:• Elicitation• Documentation• Validation• Change Management
• Requirements drive many other project activates• Development of test cases• Testing (unit, integration, regression, user, performance, stress, etc.)• Training• System Remediation
Cost• Requirements management will impact the project
costs• Key costs in the project budget:• Business Analysts• Business Subject Matter Experts (SMEs) • Requirements tracking system
• Requirements drive other project costs• Testers• Test management system / defect tracking system• Effort to remediate defects
Risk• Requirements are one of the riskiest elements of a
project• Key risks that must be considered:• Low fidelity• Poor alignment• Insincere sign-off• Late changes
• I always assume I have missing or flawed requirements• Read between the lines on every discussion to find them• Assure that the BA is not passive
Phases
Initiation • Key Question: How big is it?• Key activities:• Staffing the requirements activity• Engage key stakeholders and ensure basic alignment• Estimate budget and schedule for key requirements
activities• Key goals:• Make sure you have the key SMEs engaged• Alignment on high level requirements• Make sure you have enough time based on local culture and
needs
Planning• Key question: What needs to be done to be done?• Key activities:• Gather detailed requirements• Ensure requirements have high fidelity and alignment• Ensure requirements fit project budget and timing• Sign-off of requirements (finalize scope)
• Key Goals:• Ensure elaboration converges and stays in budget (constant
scope)• Translate business requirements to technical requirements• Know what needs to be delivered to be done!
Execution• Key question: Are we done?• Key Activities:• Test to validate requirements are met• Change control• Punch list of defects• Final project acceptance sign-off
• Key Goals:• Identify and gaps between requirements and deliverables (defects)• Identify any gaps in requirements (changes)• Ensure change management for ALL changes• Get done!
Processes
Elicitation• The process of engaging the subject mater experts
and extracting the things that must be achieved by the project• Ensure correct staffing• Ensure correct representation• Monitor progress and participation• Ensure compliance to Budget / Timing
Progressive Elaboration• The process of progressively adding more details to
high level requirements without expanding scope• NOT: the process of progressively adding requirements
until the project is so elaborate that it blows the budget and schedule• Remember the budget is a requirement just as much
as any feature• Prioritize requirements to ensure you can cut back the
less important ones to keep scope constant• Use a ‘parking lot’ for ideas that are good, but not in
scope
Validation• The process of confirming the requirements are complete
and valid and aligned with the budget and timing• Ensure fidelity – is everything needed included and is
everything included needed• Ensure alignment – ensure the right hand knows what the
left hand is doing. Build common understanding (even if it did not exist before)• Traceability - ensure each requirement is covered in the
solution and the solution does not include effort that does not support a requirement• Final validation is actually done at acceptance test
Change Management• The process of altering the documented requirements
to conform more closely to the needs while maintaining budget and timing • Change management is as much about avoiding
change as facilitating it• Changes are not free!• Ensure you cover costs and schedules
• Change management is your ‘get out of jail free card’
Technical Design?• Technical design is not really a requirements step• It is a significant requirements interpretation step• Many projects go off the tracks at this step• Most users do not understand how the design relates
to their needs• Technical reviews are helpful• Agile methods were largely developed to address this
gap
Failure
How to Fail• Ask management to provide SMEs• Ask them what is needed• Write it down• Ask them if the written requirements specification is
correct• Execute• Fail• Start over
X
Common failure modes• Driving to closure too quickly• Ignoring conflict• Implied requirements • Stakeholder conflicts / Unrepresented stakeholders• Technical Design does not fully address requirements• Failure to meet business needs
Tips and tricks
Stakeholders• Make sure ALL stakeholders are represented• Understand that corporate culture is a stakeholder• Ensure stakeholder alignment• Leadership to workers• Process owner to practitioner• Function to function
• Beware of “complete reengineering of the way we do work”• Ensure all voices are heard – separate sessions if
needed
Damage control• Emphasize budget and timing as requirements• Prioritize requirements• Unbundle requirements (Partial implementation)• Focus on ‘Victory conditions’• Leverage the change process• Use the Parking lot
Summary• PM needs to be engaged in all phases• Functional, non-functional, business, cultural• Fidelity and alignment• All areas and phases
• Requirements are never done till the project is done
Questions?
Thanks for your interest!
Mark Pendergast, PMP
???