Managing in the Yellow Zone

1. Managing in the Yellow Zone Getting the troubled project under control (and keeping it there) Philadelphia Software Process Improvement Network November 20, 2003

2. Topics • What is a Yellow Zone project? • What’s in a color • Preventing the Yellowing of the Green • When it goes Yellow anyway • A Yellow Zone rescue infrastructure • The Orange Zone: unsalvageable Yellow Zone projects • Questions

3. What is a Yellow Zone project? • Green, Red, or Yellow? • Green Zone – Projects that are on schedule and on budget, with no significant risk factors • Red Zone – Projects that are in serious trouble, with a high likelihood they will fail • Yellow Zone – Projects at risk, but potentially salvageable • The line from Green to Red usually passes through Yellow • Up to 70% of all active projects are in the Yellow Zone

4. What’s in a color? • The Business Case is the reference point • Green Zone Project will probably achieve the goals and objectives of the business case • A Yellow Zone Project may fail to achieve at least one goal or objective in the business case • A Red Zone Project will probably fail to achieve the goals and objectives in the business case • Green Zone projects can turn Yellow, and Yellow can turn Red or back to Green • Red is likely to stay Red until Dead

5. What defines a Green Zone project? • All business requirements are traceable to the business case, and the entire business case is covered in the requirements • All IT requirements are traceable to the business requirements and all business requirements are covered by the IT requirements • Requirements baselined and under change control • Clear lines of communication understood and followed • Ownership is being accepted • Milestones are being managed successfully • Minimal impact from rework time and costs

6. top causes of yellowing… • Bad idea in the first place • Overambitious • Ambiguous • Dubious measurability • Aim at the wrong business drivers • Inadequate verification and validation of “upstream” deliverables, e.g., business cases, requirements, and specifications, can defeat even a GOOD idea • Poor communication between users and developers • Scope creep

7. Preventing the Yellowing of the Green • Establish a sponsor-IT partnership at the beginning • Focus on business user-IT communication from the beginning • Revalidate upstream deliverables against their predecessors whenever there is a change • Control scope creep relentlessly • If it is not required by the business case, leave it out • If no longer required by the business case, TAKE IT OUT

8. The kiss of death • No audit trail showing that clear lines of communication are understood and ownership is being accepted • Clear lines of communication enable information to flow efficiently and effectively • Ownership prevents confusion or denial over authority and responsibility • Both are essential to correcting problems in anything else • If these are lacking, everything else will eventually spin out of control

9. When it goes Yellow anyway • Happens when prevention is applied too late • Most frequent causes • Inadequate requirements management • Poor communications between business and development • If caught early enough, may be correctable or reversible • BE PREPARED FOR MERCY KILLING

10. Early signs of Yellowing • More and more meetings accomplish little • Critical path action items start to remain open • Unanticipated pressures on cost and schedule drivers • Degrading relationship between developers and users • Churn among key team members • Difficulty in decisions about core requirements • Significant changes in probability and/or potential impact of exposure factors • Changes in “drivers of complexity”

11. why kill a Yellow Zone project? • It all comes back to the business case • How deep in the Yellow Zone? • Is acceptable payback still possible? • Is acceptable ROI still possible? • Does the original business case still make sense? • If the answers don’t make a good case to continue, logic says to kill the project • Still….

12. Doomed projects are hard to kill • Every project develops its own interest groups • Sponsors with a political stake • Developers whose jobs may depend on the project continuing • Vendors with a sale to protect • Champions with an emotional stake • Cancelled projects can create organization problems • Cancelled projects may have already burned a lot of money • Cancelled projects may result in cancelled jobs • Few projects have an Exit Champion

13. The importance of an Exit Champion • The “Devil’s Advocate” for technology decisions • Resists the political and emotional arguments to continue a doomed project • Provides Management with the information that enables Decision-by-Fact

14. The Kill or Cure-and-Continue decision • Start with high-level project review • Evaluate project viability against known exposure factors • Revalidate the business case against the current project state • Give as much credence to the Exit Champion as to the Continue Champions • Decide whether to Kill or Cure-and-Continue • If the decision is to Cure and Continue • Reassign personnel wherever necessary • Appoint a Team Catalyst • Create the infrastructure to permanently correct the exposure factors • Add a recurring revalidation process to ensure continuing alignment with the business case

15. The importance of a Team Catalyst • “The problems of software are not so much technological as sociological” • Tim Lister and Tom DeMarco, “Peopleware”, 1979 • A Team Catalyst can help restore cooperative working relationships and help ensure that they stay cooperative

16. Initial anti-Yellowing actions • Ensure effective meeting management • Acknowledge and resolve relationship issues • Take control of team churn • Enforce timely resolution of critical path action items • Resolve requirements issues through facilitation • Strengthen contingency/continuity management components of risk management process • Establish a “rapid response” process to manage impact of changes in “drivers of complexity” • Use all of the above to create a Yellow Zone rescue infrastructure

17. The Yellow Zone Management infrastructure • Processes • People • Tools

18. Processes • Business case revalidation • Requirements triage • Retrospective Verification and Validation of deliverables • Risk-Driven testing

19. Business case revalidation • May prevent exercises in futility • May find legitimate, previously unrecognized justifications to continue • Additional or extended financial benefits • “Intangible” operational benefits

20. “intangible” benefits • Often higher value than hard dollar benefits • Can strengthen a marginal business case • Can often be translated into tangible benefits • Examples: • Improved customer satisfaction • Improved employee morale • Increased user self-sufficiency • Recommended reading: • “Making Technology Investments Profitable: ROI Roadmap to Better Business Cases ” by Jack M. Keen and Bonnie Digrius (Wiley, 2003)

21. Typical Activities • Identification of Business Requirements • Risk Assessment for Project and Product • Risk-Driven Testing • Decomposition of Critical-risk Requirements into testable parts • Creation of Test Scenarios • Execution of Test Scenarios • Defect Reporting and Tracking • Status Reporting • Intra-phase reviews and quality gates

22. Requirements Triage • Re-evaluate every requirement that has not been completed for • Criticality to the first release • “Implementability” • Impact on other requirements • Impact on cost and schedule • Eliminate or defer any requirement that is not critical to the business case in the first release

23. Retrospective Verification and Validation Retrospective validation Business Case Business Requirements IT Requirements Specifications Code Forward expectations and boundaries

24. Risk-driven Testing • Includes • Decomposition of Critical Requirements into testable parts • Creation/Execution of Test Scenarios • Defect Reporting, Tracking and Status Reporting • Traces back to prioritized business requirements • Seeks to limit business exposure • Seeks “Big Bugs” first • Focuses on impact to the business case more than probability of occurrence • Requires a high-efficiency method, e.g. table driven scripts

25. Intra-phase reviews and quality gates • Re-assess business drivers and adjust business case • Re-prioritize business requirements • Re-prioritize IT requirements • Update test strategy to reflect reprioritized IT requirements

26. Summing up • Prevention pays • Communication and partnership are essential • Every project creates an interest group biased toward continuing the project • Revalidate the business case before adding to the investment • Recover only what is worth recovering • It takes courage to kill a doomed project

27. More information? • Robert Benjamin, Partner • 609 448-1963 (P) • 609 977-6214 (M) • 609 371-1322 (F) • Inquiries@SeniorPartnersGuild.com • www.SeniorPartnersGuild.com