pdd 2016 mark pendergast - requirements management

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

???