Senior
Partners
Guild
©2003, Senior Partners Guild1
Managing in the Yellow Zone
Getting the troubled project under control
(and keeping it there)
Philadelphia Software Process Improvement Network November 20, 2003
Senior
Partners
Guild
©2003, Senior Partners Guild2
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
Senior
Partners
Guild
©2003, Senior Partners Guild3
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
Senior
Partners
Guild
©2003, Senior Partners Guild4
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
Senior
Partners
Guild
©2003, Senior Partners Guild5
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
Senior
Partners
Guild
©2003, Senior Partners Guild6
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
Senior
Partners
Guild
©2003, Senior Partners Guild7
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
Senior
Partners
Guild
©2003, Senior Partners Guild8
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
Senior
Partners
Guild
©2003, Senior Partners Guild9
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
Senior
Partners
Guild
©2003, Senior Partners Guild10
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”
Senior
Partners
Guild
©2003, Senior Partners Guild11
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….
Senior
Partners
Guild
©2003, Senior Partners Guild12
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
Senior
Partners
Guild
©2003, Senior Partners Guild13
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
Senior
Partners
Guild
©2003, Senior Partners Guild14
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
Senior
Partners
Guild
©2003, Senior Partners Guild15
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
Senior
Partners
Guild
©2003, Senior Partners Guild16
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
Senior
Partners
Guild
©2003, Senior Partners Guild17
The Yellow Zone Management infrastructure
Processes People Tools
Senior
Partners
Guild
©2003, Senior Partners Guild18
Processes
Business case revalidation Requirements triage Retrospective Verification and Validation of
deliverables Risk-Driven testing
Senior
Partners
Guild
©2003, Senior Partners Guild19
Business case revalidation
May prevent exercises in futility May find legitimate, previously unrecognized
justifications to continue– Additional or extended financial benefits– “Intangible” operational benefits
Senior
Partners
Guild
©2003, Senior Partners Guild20
“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)
Senior
Partners
Guild
©2003, Senior Partners Guild21
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
Senior
Partners
Guild
©2003, Senior Partners Guild22
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
Senior
Partners
Guild
©2003, Senior Partners Guild23
Retrospective Verification and Validation
Business Case
Business
Requirem
ents
IT
Requirements
Specificati
ons Code
Forward expectations and boundaries
Retrospective validation
Senior
Partners
Guild
©2003, Senior Partners Guild24
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
Senior
Partners
Guild
©2003, Senior Partners Guild25
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
Senior
Partners
Guild
©2003, Senior Partners Guild26
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
Senior
Partners
Guild
©2003, Senior Partners Guild27
More information?
Robert Benjamin, Partner
609 448-1963 (P)
609 977-6214 (M)
609 371-1322 (F)
www.SeniorPartnersGuild.com
Top Related