The only ones left to take the blame

A police organisation I worked in had tried more than once to replace its computer-aided dispatch system. Each time, expectations had been set with the operational staff. Each time, nothing was delivered.

I hadn’t been engaged for that work, but somehow I was given it. The task was to go to tender for a new dispatch system, with GPS tracking of vehicles and a move from analog to digital radio. It needed an enormous amount of work. It was just me. There wasn’t even a steering committee.

I remember standing up in the major incident room in front of a group of operational officers. Police don’t believe anyone. It’s part of the job, and the last few promises about this system had given them good reason.

I think they were looking for somebody to fail again, and somebody to blame.

I couldn’t undo the promises others had made. What I could do was work out what the system actually needed to do and get those requirements written down.

The usual ending

When I was sent in to rescue a troubled project, the brief and business case were among the first documents I went back to. Too often, the people who had made those decisions had moved on. The team that inherited the project was left trying to explain, and sometimes answer for, decisions it had never made.

Unfortunately, they were the only ones left to take the blame.

The decisions were made early

Most of the decisions that shape a project are made before the project exists. They’re made in the brief, in the business case and in the meeting where the case is approved. Sometimes they’re made in a promise to the people who’ll use the system, long before anyone has written down what it will take.

People don’t put enough resources into that front end. The brief and business case need the right people, with enough time to develop them properly. That’s the cheapest place to fix problems.

The numbers have pointed this way for a long time. In 2008 John Mankins, writing in The Space Review, cited a finding from NASA’s budget office in the mid-1980s: “no project enjoyed less than a 40% cost overrun” unless at least 5–10% of the eventual budget had first gone into studies and technology work.

That finding came from technically demanding projects, and the percentages shouldn’t be treated as a universal rule. But the principle is worth remembering. What an organisation saves by underinvesting in the front end can cost considerably more once delivery begins.

Culture comes from the top

The front end is also where the organisation’s culture first reveals itself. If there’s only grudging agreement in the senior executive team at this early stage, how do you really expect the project to perform when the pressure is on?

Culture flows from the senior team. The people it hires, rewards and encourages become the culture. A project puts the organisation under stress, and that pressure shows what the culture really is.

Why nobody volunteers

After a few failed attempts, nobody wants their name on the next one.

There’s a related problem with reporting bad news once a project is underway. In 2008 Park, Im and Keil tested how willing people were to report bad news about a troubled software project. Participants were more willing to report when responsibility for the problem could be attributed elsewhere, and when little time remained to correct it.

It was a role-play experiment with 159 students, so it measured what people said they would do rather than what experienced project managers actually did. It also examined reporting bad news, which is a different thing from taking on a failed project.

But both situations raise a question about accountability. What happens when the person expected to speak up or take responsibility is also the person most likely to carry the blame?

In the police organisation, the earlier failures had already shaped expectations. The operational staff had heard the promises. They were still waiting for someone to deliver.

That time the work fell to the contractor.

What was written down

I developed the tender requirements, had them reviewed by legal and got the tender out. My contract ended once the responses were in.

They selected the successful tenderer and installed the new dispatch system successfully, with the radio split off into a project of its own. The dispatch system also had to be integrated with their existing back-end applications.

The people who built, integrated and installed it did that work. Most of the credit belongs to them.

What they had from me was a document they could follow.

That mattered because I was no longer there. The requirements didn’t depend on my memory, or on somebody being able to find me and ask what I’d intended. They were available to the people who had to make the system work.

When they’re written down, the project has a better chance of outlasting its author.

Before you approve the case

If you review business cases, you’re in the room where much of this is decided. The questions worth asking are about people as much as numbers.

Ask what has already been promised to the people who’ll use the system, who made those promises and whether they’re reflected in the case.

Ask whether the people needed to develop and deliver the project genuinely have the capacity, or whether the resource plan simply counts their roles as filled.

Ask who owns the commitments and whether that accountability will survive changes in management.

Ask whether the agreement around the executive table is wholehearted or grudging, and how bad news will reach the steering committee when those commitments come under pressure.

Ask who will be there to harvest the benefits, long after the project team has gone and the people who approved the business case have moved on.

The quality of the front end matters because it’s where the organisation decides what it is prepared to promise, what it is prepared to resource and who it expects to deliver.

If those answers aren’t there, the case has already decided who will take the blame.