Why Do Programs Fail?

scaled-agile
Posted by Huimin

28 July 2015

Since I’ve been working on Mingle’s product team for years, I’ve noticed that most of the time we are asked to help our customers by suggesting best practices for project and program management . This has given us an incredible opportunity to work with many different types of program managers and walk in their shoes. We did a series of interviews and summarized top reasons why your program might fail.

Incomplete Understanding of Feature Requirements

Interview question: ‘Day to day, what’s the most frequent, hands-on task you do to ensure the program’s success?’

Answer: ‘Make sure there is a coordination of dependencies. Projects get the right things at the right time.’

Many scaled agile programs fail because team members, program managers, or clients lack a complete understanding of the project feature requirements.

Understanding your feature requirements completely doesn’t mean you need to do a waterfall-style design upfront. This wouldn’t be much use since we know it’s impossible to analyze every detail of the feature without any iterative feedback. It’s even more true for programs.

So, how does a program manager understand feature requirements in a dynamic, agile environment? First of all, in the planning phase, it’s very important to have a clear vision of the program. What is the goal you are trying to achieve in this program? Spell out the expected results and success criteria. This helps ensure teams make informed decisions and stay aligned with the organizational goals.

Secondly, in the execution phase of your program, you need have visibility into the components of your big picture: knowing what you planned, what is happening now, and the expected results. Be aware of scope creep and work with teams to resolve it.

Look at re-plan as an opportunity to make things better than you planned at the beginning.

Thirdly, implant adaptive replanning strategy in your program team. Look at replan as an opportunity to make things better than you planned at the beginning. Users and customers are a great resource. Implementing a solid build-measure-learn loop with Continuous Delivery is crucial. In tight feedback loops, you can deliver functionality, and validate if you’re heading in the right direction. This also makes 80/20 decisions much simpler—if your customers are getting most of the value with a handful of the scope you thought was required, it’s a great opportunity to evaluate if all that scope is necessary.

Missed or Incomplete Understanding of Dependencies
Across Teams and Third Parties

Interview question: ‘Imagine you’re running a big program. What’s your most important job at a high level to make the program successful?’

Answer: ‘Make sure there is a coordination of dependencies. Projects get the right things at the right time.’

rica

Since scaled agile is deployed at the enterprise scale, such programs typically involve a sizable number of teams as well as third parties. You can leverage some principles to minimize the cross-team dependencies, but you cannot avoid them completely.

There are two different levels:

No visibility into the dependencies

It is a big risk if program managers are not aware of cross-team dependencies. Even for mature agile teams that successfully establish small world networks, creating a stage for everyone to raise and resolve the dependency by themselves is still a big challenge. This is where program managers need show up and help out. Knowing—and understanding—cross-team dependencies should be the No. 1 priority for program managers.

Being aware of the dependency but failing to resolve them effectively

Every dependency has an implicit impact on your program, but they are not always equally urgent or important. Just knowing that the dependencies exist is not enough: you also need to understand where each dependency sits in relation to “the big picture” of your program, what the CoD (Cost of Delay) is, what is the estimated lead time to resolution is, etc.

Development Complete vs. Production Ready

dev-complete-mwahahah

Interview question: ‘Imagine that someone told you to make a big program that you did in the past simpler. What would you do?’

Answer: ‘Deployment may be a problem. Think about deployments ahead.’

There is a big gap between “development complete” and “production ready”. A dev-complete is when the development team agrees that the code needed for the features has been added to the product. But prod-ready implies many different things:

Failure to realize the gaps and plan accordingly will result in your program delivery being majorly delayed, and most of the time this will hurt team morale. If you leave the gap until near the end of your program, it will be even more painful to bridge it. The course of action to remedy this situation isn’t mysterious: ‘If something hurts, do it more often.’

One way to do make bridging the dev-complete/prod-ready gap less painful is through continuous delivery. If your team keeps producing production-ready software in short cycles, it can demo deliverables more frequently, which ensures the confidence on the entire program. And as a plus, program managers can better predict the program’s delivery time based on the lead time of past cycles.

Budget/Cost Overruns

Usually, budget overruns are a symptom of one of the above problems. At its simplest, a budget overrun happens because you think a program is going to cost X and once you get into it, you realize it’s going to cost Y.

Budget overruns usually occur because the program is taking longer than you anticipated. Incomplete understanding of the scope, failing to manage dependencies, or overlooking the gap between dev-complete and production-ready can all cause that. There’s one special case that’s worth pointing out—say you know the scope pretty well, you’ve managed your dependencies, and you’re doing Continuous Delivery, but you’re just developing functionality at a much slower pace than you expected. Lean Enterprise Delivery can help to figure out that you’re going slowly early on instead of halfway into a program. Additionally, if you’re really experimenting, you won’t batch up a huge amount of work to finish in a program, you’ll incrementally deliver value within the constraints of the value parameters your business has set.

Recommended Reading

Embracing the Zen of Program Management

Scaling Agile—What About the Teams?


comments powered by Disqus