Sometimes the most profound points are the simplest. This article is about the essential foundation of achieving good or extraordinary delivery results from any major program or project. Make a plan, manage the issues. This is the essence of project management, and program management.

Let’s take a real example – rather a small one by some standards, but one that reflects a common experience in software development.

Context

The context was this. I had been given responsibility for a very large program to develop a software and business solution for a number of British utilities. That program had started a number of months back, and was troubled. The original plan has been created with misaligned expectations between the parties involved – expectations around the balance of scope, schedule and budget. That took careful, close work with the clients and suppliers involved to unpick. In the end, the program would be delivered just under the revised budget I had planned, and the solution would support at peak near 25% of UK electricity production.

An Impossible Schedule?

But that lay in what seemed a distant future. Right now, I was deep in discussion with my good friend Leon. Leon would himself go on to become a true master of deliveryand lead gigantic programs for significant and global clients. But on that particular day we faced the daunting task of testing and fixing the business functionality of a vast system in just 8 weeks to fit in with our complex overall schedule, a schedule determined as always by business dates. The test phase alone would involve the work of around 100 people, including our clients. It was the critical path on which all else depended.

How to decompose the problem? And to ensure success? Leon and I spoke at great length. The insight we had was simple, but critical. We had to form the best plan we could, then manage the inevitable issues that would arise given scale and speed.

Planning and Preparing …

The core plan was formed using a standard estimating model, but we knew we had to prepare to manage the coming issues, defects and changes exceptionally well. So, we added or extended the following:

1. Systems and resources to record status by individual tester, individual software defect and much more. We wanted to have perfect insight into exactly where we were, and in a way that wasn’t a burden on the team.
   
2. Earned value tracking that showed how much we had achieved versus the ambition of the plan. We wanted to know exactly how well we were doing.
3. The technical capability to create almost an arbitrary number of virtual testing environments. In these days of the cloud, this would have been much easier. However, even with more primitive tools, we very deliberately invested in understanding and then provisioning what we needed. We made sure we could rebuild the application fast. We wanted to make show intellectual effort wasn’t held up by basic resource constraints.
4. Automated regression testing. Even today, this is a build effort that many try to avoid. But there is no better way of ensuring that a system remains stable as it is changed via multiple paths, and by multiple hands. We wanted to ensure we always had a working application, and did not accidently break it.
5. A twice-daily meeting structure that focused only on issues and their resolution.We wanted nothing to slow down the rhythm of progress.

Communication, Building Support, Making Culture

And then came more expectations management. We took the team – across suppliers and client personnel, from junior developer through to board level sponsors, through our plan. We would need their help. We wanted no surprises in status. We wanted people to own their issues, to pro-actively seek resolution and not hand-off trouble in emails. We needed our clients to support the drive for schedule, while we needed to support the drive for accurate scope and a system that would work functionally. The hard cultural and client work we had put in paid off. We gained much support.

We were exceptionally well prepared.

Wheels, Buses …

So, we started our eight weeks of test execution. Even assuming a 7-day week, each day represented almost 2% of schedule.

This was scary stuff, but we were exceptionally well prepared.

The first day didn’t go well. This was probably fine. Any new undertaking will have teething issues. Then the second day passed, and progress was slower than the plan demanded. Maybe that was fine as well. It was still early days.

A week passed. Almost 13% of schedule. We were 50% behind were we planned to be. This was a major issue. The traffic lights on our status reports glared red. A dark cloud settled over the team. This was the time when temptation may make leaders bang tables, and add extra people without the time to train them.

The Team Looks for Solutions …

But issues are there to be managed, and not all risks can be predicted. So Leon looked at the data, and spoke to his team. The team’s insight was of course the most valuable, and they weren’t defensive. They had been well trained. They were looking for solutions.

Leon and the team made the following changes, with precision:

• Increased the number of test environments even more
• Made productivity improvements to a test data tool
• Gave two hours training on test data to the team
• Introduced even finer reporting, not so much to give management extra visibility, but to allow the teams to see hourly and daily inch progress. And that we made visible on whiteboards, so all could see progress.

We had included the smallest amount of schedule contingency in the planned. We used it, and recast the plan.

We started to meet our new plan. And by the end of week 8 we hit the date – at great velocity maybe, but we hit the date, and the software moved into an implementation phase. It would go live successfully, down the implementation road that lay ahead.

On reflection, we had prepared a decent plan – maybe even an exceptional one – and the investment in systems, reporting and environments had been highly worthwhile. We had created a platform, where small changes had helped recover the plan.

But above all, we had been prepared – with tools, processes and more – to handle the inevitable issues. Most importantly, we had been culturally prepared to have the honesty to face up to our execution issues and fix them.

Make a Plan, Manage the issues.

To put it simply: we had a simple goal, a plan, ambition, and confidence we would try our best. But that is never enough. We were prepared from the first moment as a team to understand and proactively fix our mistakes, knowing that is part of any large undertaking. And that is the essence of good delivery.

Keith Haviland is a business and technology leader, with a special focus on how to combine big vision and practical execution at the very largest scale, and how new technologies will reshape tech services. 

Former Partner and Global Senior Managing Director at Accenture, and founder of Accenture’s Global Delivery Network. 

Published author and active film producer, including Last Man on the Moon. Advisor/investor for web and cloud-based start-ups.