How to Deliver a $2M failed Project for $190K

• Stop clinging to bloated documentation—it's not saving your project.

• Define success in real-world terms: Judy goes home on time.

• Prove value with a working pilot, not PowerPoints.

Getting a failed digital project back on track is surprisingly easy if we depart from the governance and delivery approaches of the 1950's.

To illustrate this, I'll step through a real "rescue" project from 2013, involving the largest Victorian government department at the time.

This was a project rescue, but I have employed exactly the same approach on around 300 projects, a mix of rescues and greenfields projects.

Background and engagement

In the two years leading up to our appointment, the project had failed twice. The total budget of these failures totalled a smidge over $2 million.

I got the call on the day that the second attempt was canned. It was a Friday afternoon, not much before 5 pm.

This was not a coincidence. When prospective clients asked me to describe the type of project they should first refer to me, my standard response in those days was "something that's failed twice."

My methods are extremely simple, but they are non-standard. I have found from experience that new clients are more willing to try something outside the box if all other approaches have already failed them.

I hasten to add that this selection criteria is just for the first project at a new client, because once they've seen a successful alternate approach there's no resistance applying it to new projects and getting the job done right the first time (skipping the need for "rescue").

Step one – Relegate pre-existing documents

As much as it stings, this step is absolutely necessary.

If the team continues to refer to any form of scope-oriented documentation (including technical) as the basis for its work, it will undermine and scupper any alternative form of governance. This includes "epics," "stories," and "cards" from agile practices, as well as "requirements," "specifications," and all forms of architecture documentation.

Through no fault of the people involved to date, these documents are going to be a poor translation of what the system needs to do in order to deliver the intended business outcome. There were no controls in place when these documents were first penned, to make sure the "in scope" feature set would demonstrably result in a business outcome.

I explained this logic to my client (the Deputy Secretary) and he didn't have any objections.

As always, my team was instructed to refer to these documents when and if they felt it might save them time. They were a resource, not the basis of sequencing work.

We started with a clean slate.

Step two – State the project's goal in terms of a measurable business outcome

This is also simple, but I've never seen it employed anywhere (other than the client I learned it from in 2001).

When I arrived, different people on the client's team described the project's goal quite differently. This is what I expected because I've never found it any other way.

Most commonly, the project was described as "replace the old Lotus Notes system."

This isn't a business outcome though, so it doesn't qualify as a good "outcome statement" or "success statement." Anything that mentions technology, systems or processes is a poor indicator of what we're trying to achieve. Think of it this way—I could deliver a like-for-like replacement of the current system and deliver zero business value. There's nothing in the "statement" here that we can use to reliably govern the team toward an outcome.

It's hard to imagine how any project succeeds really, when in almost every case, the team can't state the business outcome they're trying to achieve.

Again, this isn't the team's fault; it's just the way the process has evolved over the past half-century.

As always, getting to a well-stated "outcome statement" took a few questions. In this case it only took around 15 minutes because we had the right person in the room from the first meeting (through request)—that is, the person who suffered the most pain from the current process.

This was Judy. Judy would be up till midnight 2 to 3 days every sitting of parliament (fortnightly, for the parliamentary season). She was "coordinating" the process of collating ministerial briefing papers for a selection of briefing paper authors in her sub-department.

Judy was being treated for work-related stress disorders. There were around 1,500 people like Judy across Victorian government in a similar position.

So our "outcome statement" was: "Judy goes home on time, almost always."

This is typical of a good outcome statement because it's short, so the whole team can rattle it off (and they often do). It becomes part of the team's DNA. It's also easy to measure; we just ask Judy if she'd been going home on time, almost always.

Step three – Build and run a pilot

No, not a proof of concept.

A "pilot" is a system that a tiny group of people use in their day job—that is, "in production."

Pilots need to be temporary and small-scale because we don't have time to build all the supporting administrative functions and systems integrations that we'll eventually need.

In many cases, data from the pilot will be rekeyed by the project team into their existing systems so that if or when the pilot is paused, business carries on as usual. I use the phrase: "no humans were harmed in the filming of this pilot."

The purpose of the pilot isn't to prove that we can build a system. It must prove we can deliver the stated business outcome.

The technology is almost irrelevant. We don't have to demonstrate the system is manageable behind the scenes. I've run pilots where we throw away the solution and just use the team's experience to guide package selection. It's far more cost-effective than writing documents for a month, because those documents have no bearing on the outcome.

Put another way, the pilot is intended to prove the business benefit without worrying about cost. The fact we're using "human APIs" (our team rekeying information into a backend system) is not an issue because we know we'll eventually replace it with automation.

I had my first chat with the sponsor and Judy on the Tuesday morning following the first-call Friday. I had primed the sponsor on the Friday to choose a pilot group and given him a few tips on what to look for. He chose Judy's team.

By the end of the week, Judy and the people she coordinated were looking at a partial solution, and by the following Wednesday, they used the new solution to produce their first briefing paper to a minister. Those documents were retrofitted by our project team into the existing Lotus Notes-based system.

As it sometimes turns out, Judy's team never stopped using the pilot solution.

On the second Friday following our Tuesday kickoff, we had built enough for Judy and team to use for a few weeks, so we stopped building.

It only took one fortnight for Judy to declare the pilot a success. When we asked the question, she burst into tears. The system was super simple and nothing compared to the full solution, but it got the job done and literally transformed Judy's life in a few weeks.

Step four – Scale out

We regrouped for a couple of weeks to develop and communicate a gradual build and scale plan. This is a non-technical task; it's just about "who's the next Judy?" and thinking about inflection points for scale.

At this point we gave a firm estimate to complete the whole project. We simply had enough experience to know that "a standard team will nail this type of thing in 10 weeks max."

Our estimate was for a total of $210k for 10 weeks; in the end, we stopped at the end of week 9 for $190k.

Simpler than you think

Whenever I share stories like this, I'm understandably met with a healthy degree of scepticism—about the approach in general, but also specifically about how easy it is to try for the first time.

What I've reliably found is that it only takes one practice before this approach becomes second nature—not just for the project team, but also for the user groups they're interacting with.

My teams often tell stories of a user arguing against the development of a feature they originally proposed, like Judy retracting a request on the basis that "it's not going to help me go home any earlier."

Andrew Walker
Consulting to for-purpose CEOs to deliver more impact with existing teams and systems - by freeing humans up from admin.
https://www.linkedin.com/in/andrew-walker-the-impatient-futurist/

Did someone forward this email to you? Want your own subscription? Head over here and sign yourself right up!

Back issues available here.