Four Ways to Rethink How We View Project Failure
For years, project managers have been taught that projects are either successful or not. It was a holdover from Waterfall project management. And as I suggested in a book review on Jennifer Pahkla’s book, Recoding America, we need to move to a paradigm of using project data as a dashboard of insights to help us know when to turn the wheel, rather than a final report card on the project’s performance. With that in mind, I want to outline four different ways that we could rethink how we view project failure.
1. Define success criteria from the outset and measure what you agree on
All projects are different. Not every project needs a fixed final deadline. Some projects are more time-sensitive than others. An event project has a very fixed final deadline. And a residential construction project may have a target move-in date, with a customer who is much more interested in getting their dream house built than worrying about moving in on that date. A new pharmaceutical development project may be much more focused on the effectiveness and safety of the final drug that is being developed rather than a fixed launch date.
The key is to understand, as a project team, what your client or management team believes success looks like. Know for sure what project failure means. It’s not going to be the same for every project. And then, at the end of the project, you need to prioritize understanding whether the project was a success or not. Sometimes it will not be completely black and white. A project does not have to be either successful or a complete failure. We can have projects that are moderately successful and ask what the lessons are. Those conversations help us grow as teams.
To do that, you need to talk through how you plan to measure success at the end. This should be an early conversation for the team. For example, on that event project, will you measure success by net dollars raised or number of tickets sold? On an IT project to build a new feature for an existing software tool, will you measure success through time to stage, time to production, dollars spent, or customer feedback? There are many ways to view project success and I usually don’t find that teams do a very good job of understanding success from the beginning. And I often find that clients may not want to think about it either.
2. Define the benefit(s) the project will realize and measure those
Projects are undertaken to realize benefits. Frequently those benefits don’t materialize for months or years after the project is completed. For example, consider a project to open a new retail operation. The hope is that the store will generate sales, producing net profits. But that won’t happen for a while.
Your project team cannot be held responsible for whether the project it undertakes meets the revenue or profit targets for the next five years. But someone needs to be monitoring that.
This is a perfect job for your PMO — or Project Management Office. When the project is being conceived, and this happens before your team is in place, the PMO should define the benefits and understand how they will measure them when the time comes.
It’s important to understand that you might want to use both approaches on the same project. The project team will ensure that management’s (or the client’s) project success criteria are understood by the team, together with how these criteria will be measured. And then, at the end, they will measure the success of the project and report back to management or the client. That teams needs to know what project failure means.
And then, later, the PMO will begin to measure the benefits. And so, in the case of the new retail establishment, the project team is not penalized for a store that doesn’t perform well. That goes back to the management team that developed the idea for the new store.
3. Allow for projects where the team gives it their best shot for a specific time block
This is a particularly popular kind of project in companies that are always experimenting with the development of new ideas. Suppose you have a consumer products company that wants to develop an entirely new line of kitchen products. That project is all about experimentation and requires considerable agility.
Why can’t we have a project that is completely open-ended, but has a specific end point? Your success criteria might be a working prototype. You might specify that the prototype design has been approved by your patent lawyer, for example. Or not. You might specify that it’s a prototype that has been built, or you might specify that it’s just a design. Or you might specify that it’s a design of the entire line. A lot depends on how much time the company wants to give the team.
The longer the company gives the team, the greater the risk. So having a smaller scope and shorter timeline will reduce the risk. I recommend that you set the team up for success by giving them a reasonable timeline, scope, and defined success criteria. Be clear in the beginning about what project failure looks like and whether there are consequences to the team if it fails. You cannot expect every experiment to be successful and you should have clear expectations with your team about what you expect.
4. Deliver real value to the client regularly and rapidly and embrace failure
Some projects simply require more innovation than others. And some clients are more tolerant of project failure than others. If I was the homeowner building my dream home, I wouldn’t be very tolerant of failing to deliver a properly wired home, for example. Or, plumbing that leaked.
On the other hand, if I’m the federal government trying to push out a new system for accepting tax returns, I need to understand that a project of that nature will have bugs in early iterations. I need to embrace failure and insist on plenty of iterations during which the team will test the system and work out the kinks. I don’t need to embrace failure on the scale of the healthcare.gov disaster to embrace failure on early test iterations.
This is the value of an Agile approach, with short sprints where software is delivered at the end of every sprint. And yet, on the tax return example, I would lobby for having a well-constructed project plan before major execution is started. You need to know what the ultimate success criteria is on that system and how you will measure it. You need to understand the risks, stakeholder roles, and people dynamics before you start spending millions of dollars of taxpayer funds.
We CAN reimagine project management! It doesn’t have to be the way we’ve been doing it for years. We don’t have to continue to tolerate massive lost dollars on unsuccessful projects, rationalized as the cost of doing business. Who is interested? Reach out to me.
