The best business case he’d seen

On Friday I wrote about standing up in front of a room of police officers who’d stopped believing promises about their dispatch system. That’s what lost trust looks like. This is a story about how a business case earns it.

At another organisation, I was a contractor in IT, working on something else. The head of the organisation wanted to change how the public dealt with it. Everyone in IT knew the change had to happen. The expectation had already been set, at a very low cost, with no documentation behind it.

There was no project management method, and four or five of the last six releases of the core software had been pulled. This was an organisation with good reason to be cautious about another change.

Nobody was allocated to the work, and nobody wanted to do it. I told my boss we had to do something about it.

Weeks before anything else

I asked for one person who knew the system extremely well. The two of us took ourselves away and spent more than six weeks reviewing the whole system, every point where the public met the organisation, and what would have to change behind each one.

One Friday morning we sat in the room, confident we had designed the new system. We had mapped it all out. Then I asked one question: what happens when the user hits this key?

The answer came back: “We don’t know.”

We were lucky. We were working in an operational area, so the answer was simple: go and ask the people who were doing the work.

That review became the project brief. The brief became the business case. Because the organisation had no project management method, we set one up alongside it.

The business case came in at several times the figure that had been expected. The head of the organisation approved it, and called it the best business case he’d seen.

Why a bigger number was believed

A business case that multiplies the expected cost has every reason to be sent back. This one wasn’t.

I can’t say exactly why the head of the organisation accepted that increase, but I know what we put in front of him.

We had examined the whole system, so the numbers had something underneath them. We had identified what needed to change, including the work behind the parts the public would see.

We had also addressed the risk everyone already knew about. An organisation whose recent software releases had been pulled could not afford another one. We put months of testing into the schedule, brought people from the operational areas into the project teams, and went out to the business areas to set expectations before anything was built.

The risks weren’t hidden to make the case more attractive. They were written down, along with what we proposed to do about them.

I think that’s what made the business case credible. The writing helped, but the work behind it did more.

Trust that outlasted the author

We were well into the build when I left the project. I was setting up the testing team, its procedures and its workflow.

I kept in touch with people there, and they told me what happened. They followed the schedule and the documentation after I left. The release went in extremely well. A few minor bugs were fixed in the week after it went live, which the plan had allowed for.

The credit belongs to the people who did that work: the colleague who knew the system and spent those weeks with me, the operational staff who joined the project teams, and the team who carried the plan through after I’d gone.

The people who followed had a plan they could understand and use, even after I’d left.

That matters.

In an organisation where the last few releases had been pulled, the successful release was important. But so was the fact that the work continued after I left, with the people responsible for delivery able to follow what had been agreed.

That’s what trust looked like.

What a reviewer can see

If you review business cases, trust is something you can check for.

Can you see the work behind the numbers, or only the numbers?

Are the risks everyone talks about in the corridor written into the case, along with what will be done about them?

Does the schedule include the testing the organisation’s history says it needs?

Have the people who’ll live with the change been brought in, or only told?

And if the person who developed the case leaves tomorrow, will the people who follow understand what was agreed and why?

A good business case doesn’t eliminate uncertainty. It makes the assumptions, risks and commitments visible so the people approving it know what they’re taking on.

It also gives the people responsible for delivery something they can work from, rather than leaving them to reconstruct decisions made months or years earlier.

That organisation kept the project management method and the governance we’d established. They knew it added cost, but they kept it because errors were reduced on the work that followed.

The business case helped get one project approved. It also changed how the organisation approached the next one.