Explain Program Risks with Cost of Delay
Johanna Rothman works with companies to improve how they manage their product development. She is the author of Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects, 2nd edition, Agile and Lean Program Management: Scaling Collaboration Across the Organization as well as several other books including the newest: Create Your Successful Agile Project: Collaborate, Measure, Estimate, Deliver. See her blogs and more of her writing at jrothman.com.
Product and feature delays can adversely affect adoption for IT projects and revenue for commercial products. Cost of delay (CoD) is a way to explain and calculate those costs. Here’s how one agile program manager used CoD to explain risks.
Cindy, an agile program manager, was concerned. Several trends bothered her. Her program had worked hard on finishing a Very Important Customer demo six weeks ago. Up until about a month before that demo, they’d been proceeding in a fairly predictable way. Each team had been able to finish a small story every day. They’d built the entire product at least once a day and it had worked.
No longer. Now, each team’s cycle time was increasing (not by a lot, but by about a day every month). It now took each team at least two days to release a feature. Some teams needed three days. And the cumulative flow measurements were increasing. More teams had more work in progress (WIP) in all columns—not just in testing (which Cindy had expected), but more WIP in development in the coding columns. All the trends were wrong.
Cindy called Ruby, the program architect, to see what the problem was. Ruby said Stan, the program product owner, was no longer a rational human being.
Cindy said, “I was just looking at the program data. I’m a bit worried by the teams not making the progress we made before the demo. I…
Please log in or sign up below to read the rest of the article.
ADVERTISEMENT
Published at Thu, 19 Jul 2018 04:00:00 +0000
