Project Gateways: Land Or Abort?

A while back, I heard an airline pilot interviewed on the radio. There had been hurricane force winds, and the pilot was explaining how pilots deal with having to safely land aircraft in situations like this. One key decision is whether to continue to attempt the landing or whether to abort and ‘go around’ (attempt the landing again).

I was really intrigued to hear that pilots are taught to teach every approach as if it will end up being aborted. In fact, the pilot explained that they are taught that even in good conditions they should plan for an aborted landing as the default response, and this only changes once the relevant conditions for a safe landing are met.  Even though aborting a landing is the exception, it is considered so important that they plan for it on every single approach.

Project Landing Strips

As a BA, it struck me that there is a parallel to be drawn with the project world. There is often an understandable and admirable optimism on projects, with a genuine desire to get the delivery ‘over the line’ in the required timescale and within the required budget. Yet history shows us that being ‘on time’ and ‘on budget’ alone are not enough… delivering a solution that doesn’t actually solve a problem or meet a need (or is not aligned with the organizational strategy) is unlikely to achieve the required benefits.  With few or no benefits, what was the point in the first place? Spending good money after bad on a project that should have been canceled months ago is crazy, but it happens.

Now, I’m no PM, but I would expect that any good project method will require regular benefit reviews and there will be approval gateways where the project could (in theory) be stopped. Yet we have probably all experienced how this becomes harder and harder as time passes and as the budget gets spent. It would be a brave sponsor that aborts a project that has been in execution for a year and has spent millions of dollars. The ‘sunken cost’ fallacy comes into play here, along with the political ramifications of making a decision like this. Yet there may be times when it is the right thing to do… if the choice is to write off the existing spend or continue and commit another ten million dollars to deliver something nobody wants or needs, then surely the logical thing to do is to hit the ‘stop’ button?

Advertisement

This is perhaps where a subtle change could help. Project gateways and reviews are, in my experience at least, often progressed with the assumption that the project will continue unless it is proven that there is a major problem. As long as everything can be shown to be within agreed tolerances, it’ll pass through with flying colors. What if that perspective was changed so that the default is to stop—or at least pause—the project unless it could be established that the benefits will still be achieved?  If the emphasis changed from “prove it won’t work” to “prove it will work”? If red lines or “key failure indicators” were defined up front and examined too?

Ironically, this was probably the original intent of project gateways. They ought to provide efficient, fast and robust scrutiny on project investments. However, I’m sure we’ve all worked in situations where they are seen as somewhat of a ‘tick in the box’ exercise. I remember hearing a colleague report that they’d found benefits being double-counted in a business case. They were shocked with the response “oh, don’t worry, we need to get this one through—we’ll leave it in as we can always find some benefits elsewhere if we need to”. I feel sure they will have escalated the matter, but this illustrates the types of challenges that practitioners face.

But Don’t Go Too Far!

There is one additional aspect that should be considered here. As Christina Lovelock argues in her excellent article “Practicing Practical Optimism”, there can be a tendency to place too much emphasis on risk. These things are always a balance, but just as the pilot plans for an aborted landing even though they don’t expect to need to do it, perhaps project reviews should prepare for pausing/stopping projects even though they don’t expect to do so very often.  After all, you probably buckle up your seatbelt every time you drive your car even though you don’t expect to have an accident. A good project gateway could perhaps be seen as the project’s emergency brakes, seatbelt and airbag. Where braking is necessary, it’ll be much more comfortable for everyone involved if it’s done early and gradually!

If your project gateways are already working like this, that is fantastic. If not, perhaps this is food for thought