Their own words were in it

Last week I had coffee with Diane Dromgold. We talked about project management and the work we’d both seen, and one point she made has stayed with me since.

Researchers, she said, spend most of their time studying what went wrong in projects. Maybe we should look at what went right.

Her example was childbirth. In nineteenth-century Vienna, mothers were dying of puerperal fever at very different rates in two maternity clinics. Ignaz Semmelweis investigated the differences between them and found that doctors’ handwashing made an enormous difference. The answer came from comparing outcomes, not simply recording another death.

She also told me about Rocky Flats, a nuclear weapons plant in Colorado. In the mid-1990s, the clean-up was projected to take decades and cost tens of billions of dollars. Instead, the major clean-up was completed in about ten years at a fraction of the projected cost. Two academics, Kim Cameron and Marc Lavine, wrote a book on how it was done. Most of us could list a dozen failed projects before morning tea. I’d never heard of this one.

My last four posts were about what goes wrong: the risk nobody scheduled, the resource plan that named roles instead of people, the blame that lands on whoever’s left, and the business case that could have been sent back. This one is about a sign that a project was going right.

The sign I looked for

For me, it was documentation. If the key governance documents were being written on time and approved by senior management, the project was usually in good shape. If they weren’t getting done or weren’t getting approved, that raised a red flag.

An on-time, approved document can tell you two things. The team understood the work well enough to write it down by the date they’d promised. And the people who had to decide had made the decision.

A late document usually meant one of two things had slipped: the team couldn’t yet say what it was doing, or management hadn’t made up its mind. Neither was a good sign.

That’s why I watched the dates. They could tell me something was going wrong weeks before the problem appeared in the budget or the schedule.

But the date alone wasn’t enough. A document could be approved on time without anyone having seriously questioned what was in it. I wanted to know what had happened before the signature.

How the approval became real

An approval can be a rubber stamp. What made it real was the work done before the document went up.

When I was drafting, I’d take each document to senior management and have them read it one by one and tell me where they had difficulty with it. I’d resolve those at the time, with the general manager.

Sometimes they challenged an assumption. Sometimes they wanted something explained differently. Sometimes they knew something about the organisation that the project team hadn’t taken into account.

By the time it came up for approval, it had already cleared the hurdle with senior management. Their concerns had been addressed, and their wording was often included in the text.

The credit for that belongs to the general managers and senior managers who gave the time. Reading a draft properly and arguing with it is work, and they did it.

What a reviewer can check

If you’re reviewing a project that looks healthy, the governance documents can tell you something about whether it is.

Were they written when the plan said they would be? Were they approved on time, or did they sit waiting for a signature?

And whose words are in them?

If senior management’s concerns appear in the approved version, that’s evidence that someone walked them through it and addressed the difficulties. If a document went up unchanged and came back signed, the signature may tell you very little.

The point isn’t that every document needs rewriting. A sound draft may need very little changed. What matters is whether anyone tested it, raised difficulties and resolved them before approving it.

One level up

Where a document was going to the board, the same thing happened one level higher.

Before it was submitted, the chairman read it and made suggestions, which were incorporated as well.

The board looks at a business case from a different position than management. The chairman’s questions were often different from those raised by the general managers. They could expose assumptions that had survived every discussion within the project team.

That was the value of having the chairman read the document before the board meeting. The point was to let another level of governance challenge the case while there was still time to improve it.

It was better to hear those questions before the board meeting than in it.

What we leave behind

Diane’s point stands. We record failure carefully, in post-mortems and lessons-learned registers. The signs of a project going well are mostly left to memory.

Some of them were never hidden.

They were in the approval dates, in the drafts that went backwards and forwards, and in whose words made it into the documents.

A reviewer looking at those records might learn something about the decisions being made, the people making them, and whether the project had the attention of the organisation’s leadership.

That’s worth studying, just as we study the warning signs of failure.

When a project I worked on went well, part of the reason was simple. It’s very hard not to approve a document when your own words are in it.