Episode #89:
Are all projects doomed?

The ‘On Time, on Budget’ Myth

Is it really inevitable that all projects will go overtime and over budget? 

I cut my leadership teeth as a project manager on large software development projects, and I’ve had executive accountability for mega-projects in construction, procurement, major asset overhaul, and capital efficiency.

This episode takes a fly over the top of all things project-related. Why do they fail? What are some of the common misconceptions about projects? How do you improve the chances of success for any project? 

Although I don’t necessarily believe that all projects are doomed, in my experience it is quite rare to see one done really well.

We’ve also created a free PDF resource, the ‘7 Ways to Nail Your Next Project’, which you can download below.

We have had thousands of leaders download this free resource!

Get yours delivered straight to your inbox by filling out the below form 👇

Are all projects doomed? The ‘On Time, on Budget’ Myth

Episode #89 transcript

Hey there, and welcome to Episode #89 of the No Bullsh!t Leadership podcast. This week's episode: "Are all projects doomed? The 'on time, on budget' myth." Many of you probably wouldn't know that I cut my leadership teeth on large software development projects as a project manager, and throughout my career I've had executive or sponsorship accountability for large projects in construction, procurement, major asset overhaul and capital efficiency. So it's like putting on a favourite old pair of slippers to answer a question this week from Douglas, who asked if all projects are doomed to fail? Douglas' question comes as a result of a conversation he had with a capable and highly respected leader who said, " It's inevitable that all projects will go over time and over budget." "Surely not?" asks Douglas.

Well, let's talk about all things project and why I don't necessarily believe that all projects are doomed, but in my experience, it's quite rare to see one done really well. We'll start by exploring what project levers we have and why we so often need to make trade offs. I'll then explore why the stage gating process is so important. We'll look at the key causes of project failure, and I'll finish with my 7 tips for giving your project and even-money chance of success. So let's get into it.

We often hear people claim that their project was delivered 'on time, and on budget', and in fact, in the proximity of a LinkedIn profile, no project has ever failed. Sometimes this is just selective representation of the facts, but other times it is people believing their own bullshit. Now, here's what doesn't usually get mentioned or queried about projects. On time and on budget, right? So, according to which version of the plan? Was it the one in the original investment proposal, or was it revision number 11 after many changes to the plan based on circumstances beyond our control, as they're sometimes called. Or, on time, on budget - but did you have to use any accounting trickery to hit budget? For example, did you borrow resources from business-as-usual teams and choose not to cost them to the project because they weren't an incremental cost to the overall organisation.

On time and on budget, but how much of the original scope wasn't delivered? When faced with either project delays or cost overruns, quite often decisions will be made to reduce the original scope. So being able to say 'on time and on budget' doesn't really matter if you only delivered 60% of the value that was originally intended. On time and on budget, but what was the quality like? It's always easy to push problems into the post-implementation phase. We delivered on time, and then the organisation had to scramble, investing untold resources to make it fit for purpose or to circumvent obvious problems. I was actually once the sponsor for a critical project like this where we implemented an ambitious replacement of all core operational systems with a bespoke redevelopment, but it took months after the implementation to get the reporting right to provide accurate data from the operations. And in the meantime, there are several weeks where the business was actually flying blind.

On time and on budget, but what was the right amount of money that we should have spent? Over-capitalising assets is a classic sin of large projects. So we spent 20% more than we needed to to get the same result because we built in a bunch of bells and whistles that made no appreciable difference to the value case. This can make it costly to compete with competitive firms with cheaper assets, and it's largely a victimless crime. And over the years I've found this to be a massive problem with big infrastructure projects in water, rail, electricity and so forth.

Now an example of all these sins working in perfect harmony is Australia's National Broadband Network, or NBN. Now, I know there are many dedicated and capable people working in the NBN company, so please don't get me wrong here. We've got many podcasts listeners in the NBN, and one of our favourite Leadership Beyond the Theory alumni, Sean. There's been huge amounts of political interference as this government project passed between multiple governments of different flavours, with more twists and turns than a caged snake.

For the figures I'm about to quote too, just be aware that some of them came from the most reliable website in the world, Wikipedia. Now in 2007 there was this original proposal. We're going to replace Australia's ageing copper telco network with an optic fibre backbone. But we're going to use the existing copper connection from the exchanges to the household. Now, this was called fibre to the node. The originally anticipated cost was $15 billion, of which the government was going to pay around $4 billion and it was going to be completed in June of 2021. In 2009 the first real plan was released. Now since 2007 a few things have changed, not least of which was the fact the government realised the technology proposed would be woefully inadequate with the speed of change and telecommunications. So they then changed the proposal to cater for full fibre optic connection to every single household, which was called fibre to the premises.

And this promised download speeds of up to 100 megabits per second. Now, the cost of this was $37 billion of which the government was going to pay around $30 billion. So in those couple of years, the taxpayers ended up on the hook for an additional $26 billion in the blink of an eye. The return on investment predicted was 7.1% which I think is to be filed under "F" for fiction. Today as we stand here, the project's almost finished. It's due to be completed in June of this year. The total project costs has turned out to be $51 billion. Or maybe they got the numbers transposed from the original $15 billion bid, who knows? But the ultimate result is more comparable to the original $15 billion bid because we're back to predominantly the old plan of fibre to the node, and in fact there are many households that won't even be able to get 25 megabits per second download speed.

Many households are going to experience the dual insult of slower download speeds from their previous cable services, with increased cost to try to absorb the gargantuan overspend - and that doesn't include the value destruction in market capitalization experienced by the big telco retailers, who've all gone in sharp reverse against the trend of a rising market over the last several years. That's sort of easy to pick on big infrastructure projects: they're super complex, and notoriously difficult to manage, particularly with these subcontractor providers, so it's unsurprising that they don't often land on the same budget timeline planet that was originally anticipated.

Let's talk about levers. On any project, there are four key levers you can pull to change the outcome. And those four are cost, time, scope and quality. If you want to keep any particular element on track, you need to make compromises in one or more of the other three. That's why project steering committees are in place. Their job is to decide what's most important based on the ultimate value delivery of a project and more often than not, they are more intent on looking good than getting a high value result. In the race of life, as they say, you can always back self-interest to win by two links. They go for what's most visible: cost and time. Scope and quality end up being poor cousins in these decision making processes, so too often value is destroyed by making necessary compromises in functional scope and quality, in order to meet a deadline or stay within a budget envelope. When it comes to projects, a derivation of the famous John F. Kennedy quote is particularly relevant. "Success has many fathers, but failure is an orphan."

Let's talk about the stage gate process. "Stage gates" are review points in projects - especially ones which require significant investment. And what the stage gates do is that they enable you to look at a proposed project investment and to make decisions based on better information, derived from more detailed analysis as time progresses. They're generally supported by a written business case which summarises the outcomes of the phase just completed, and seeks approval to proceed to the next phase. This case is then examined by a steering or an investment committee which is supposed to provide a level of governance and oversight with a level of supposed independence, and not getting bogged down in the day-to-day detail. We'll get to more on this later. But what it does, it helps you spread the investment by drip feeding project funding, so that it's not all committed upfront when the information is at its lowest. It's supposed to operate a bit like the way a board and a management team of a company work together. And at each gate it's really important that we have a go or a no go decision to make.

Typical phases are, and I'm going to use the infrastructure project terminology rather than the software development terminology. Phase one is concept, so this is where you have a high degree of uncertainty, it's really just a proof of an idea. Phase two is pre-feasibility. That's where you have high level design and options analysis and selection of a given option. And this is the point at which you can get the most difference in value engineering a project. Phase three is feasibility, which corresponds to detailed design, and this is where specific plans are created to deliver a chosen option. Phase four is execution and that's the actual build out of a project, and phase five is implementation, so this is the go live and it's the tracking of benefits recovery post-project implementation. If you have a stage gate process in place, the most important thing is to make sure that these things are not just a formality so that you're not just rolling from one phase to another. At each point you have to critically assess what's been done and reevaluate the investment required to actually deliver a project. These are the points at which good governance should be able to temper the exuberance of the project team.

If we want to understand why some projects fail, we really need to dig down into the root causes of those failures. So I'm going to go through 10 of them that are very, very common that you see all the time on projects. Number one is poor planning. And poor planning comes in a variety of different manifestations. So the first and very common one is planners being overly optimistic about what they're going to achieve, but there's also not understanding the risks sufficiently. There's also inadequate resourcing, or not understanding resource dependencies. And there's making assumptions about what other people, teams or organisations will do without calibrating this properly. The second common cause is lack of clear ownership. Who's cooking the chook? Sponsorship is absolutely critical, and every project has to be owned by the executive who's going to realise the value not by some amorphous corporate area that thinks it might be a good idea to embark upon a project because it's fun.

Common root cause number three, is lack of independent scrutiny. When we spoke about the stage gates, at the pre-feasibility point, it's critical to have some sort of external oversight or independent peer review. This is to test not just the technical modelling but also the commercial modelling to see if it actually stacks up and makes sense. And this should include some scenario analysis and potentially testing of the risk boundaries. And this is done through net present value analysis. Root cause number four, is failure to consider the human interface. So what happens after implementation? What are we relying on our people to do once the project has been delivered? How do we train and induct them in new procedures and work methods?

Root cause number five, lack of focus on the business benefits, and too much focus on the tech. Too often the project becomes the ends rather than the means. If you think of this properly, a project is simply a means to create value and if that value isn't created, the project per se is not valuable and you shouldn't be doing it. Root cause number six, lack of clear accountabilities. Now, particularly when you have external companies involved, so systems integrators in software projects, external engineers and labour forces in infrastructure projects, and suppliers of key products and services. Any individual or organisation that you contract for purposes of the project has to have a really clear understanding of who's doing what and who's accountable for delivering which pieces. Root cause number seven is poor communication. Now, communicating cost and timeline milestones is fine, but how about communicating expectations, priorities, and value? This gets really difficult when everyone gets absorbed with delivering their own little piece and integration issues are bound when communication is poor.

Root cause number eight, inadequate contracts. Now we've just spoken about external providers that come in and help us with our projects, but quite often when we set up the contracts that govern who's doing what, they're often not explicit enough about the sharing of risk and reward and the expectations and it's pretty rare to see one of these contracts where the compulsion mechanisms aren't completely toothless. We'll talk a bit more about this later on. Root cause number nine is a lack of understanding of the concept of sunk cost. Regardless of where we are on a project timeline, there is always a tendency to put good money after bad. We've already invested $10 million, we can't stop now, we've got to keep pushing forward. But the whole point is, once the money's gone, it's gone and you can only look forward not backwards when trying to work out what the value delivery of a project is going to be. Finally, number ten - and I saved the best for last - is lack of courage. Project managers don't want to bring bad news, so they often cover up overruns and they remain overly optimistic where there's absolutely no justifiable reason for doing so. Steering committees too, they don't drill deep enough, and when they find something going wrong, they just hope that something's going to change. Guess what? It never does. Everyone seems to have a vested interest in the project continuing, which is a very poor backdrop for individual courage.

Let's wrap this up with my seven tips for giving your project and even-money chance of success. Number one, find the project owner and make them own it. So number one in my book for project failure is the lack of clear ownership. You've got to have a project owner or a sponsor. It's absolutely critical. And they have to actually drive it, this is not an honorific post. So even though it might seem like a really good idea to have the chief executive sponsoring your project, how much attention can they actually give it? Sometimes it's just not a good idea to go for the most senior person. The sponsor has to have a key role in making critical decisions.

Tip number two, make accountabilities within the project team super clear. And there are three areas in particular that you need to make sure there's clarity on because they are interfaces that can rub, this is where gaps and overlaps occur. Firstly for IT projects, there's the interface between the IT delivery arm and the actual business owners. For so many projects, the tail wags the dog, so we give the project to the CIO because they own the "delivery resources", but then we find that decisions aren't being made by the people who are in the best position to do so. And those are the business owners who eventually have to drive the benefits recovery. Secondly, for infrastructure projects, you've got the gaps between the project team and the business-as-usual teams, and there's got to be some alignment there. And finally the accountabilities have to be really clear between any external organisations and the internal delivery teams. And you've got to back this up with contractual clarity. Make sure your contracts actually have teeth. Most contracts I've seen have liquidated damages for late delivery, but they're totally inadequate, and they certainly don't assist in driving the behaviour of the contracted party.

Tip number three, respect the stage gates. You've gotta be prepared to kill a project at any time the question is asked, so don't fall in love with a project. Just know that people on the project team have a vested interest in the project continuing. It's a really rare project manager who will recommend killing their own project. I've actually done it a few times during my career, but only because I'd rather be known as the guy who killed a project than the guy who delivered a shitty outcome. Tip number four, track the right things during execution. The only true measure of a project is a measure called earned value. If you're on a project steering committee or investment review board, you'll hear things like, well, we're on track because we're under budget or, we successfully got to this milestone. Well, that's fine, but have we actually completed as much of the scope delivery as we'd expected to by that point? Is there anything we shifted off to a later phase and said, we'll do that later on.

If you look at earned value, it says, where is my progress, compared to how much money I've spent and how much time I've absorbed. And this is going to allow you to capture scope slippages early. Now it's much harder for project managers to hide under a proper earned value analysis. Tip number five, be project literate. You've got to understand the rules of thumb for projects. If your project slips at a certain point, you'll often hear a project manager say, we've slipped here, but don't worry, we'll get it back in this later phase. Now, any project manager that tells you that is full of shit or they don't know what they're doing. You can't ever get time back without a compromise in one of the other levers, so costs, scope or quality. And the rule of thumb is that at 15% into the project timeline, you know exactly where it's going to end up.

If you're behind after 15% has been burned, you're going to end up behind at the end. If you're ahead, you'll end up ahead. But if you're overseeing the project team, watch their feet and not their lips. Tip number six, never lose sight of the ultimate purpose of the project. This is about delivering benefits to the organisation, so don't give up project scope too easily and if you do, make sure you go back and modify the benefit statement accordingly to adjust the net present value. Quite often the very last time a net present value statement is examined is in the stage gate meeting prior to execution phase, but it should be the focal point of every discussion. Are we still on track to deliver the value we promised? And finally, tip number seven, put individuals on the hook for value delivery, not just project delivery. A lot of people just put the glasses down when the project is implemented and that's when the potential for delivering value has been completed.

That gets you to the starting line. Then the work of capturing the value begins. Don't get this wrong. If you're in a senior executive position, this is all you should really care about. So let's try to answer the original question. Are all projects doomed? Well, I guess it depends on how you view success. It's never black and white and there are also degrees of success and failure. Sometimes the most successful project is the one that got cancelled in the pre-feasibility investment review, because the economics or the risk-reward equation didn't stack up. Sometimes, the least successful project is the one that nominally comes in on time and under budget, because so many concessions were required in reducing scope that the opportunity to capture the originally anticipated value was completely lost. Rather than saying all projects are doomed, I'd like to think that if you can check off the majority of the preconditions for success that we just went through, you've got a really good chance of turning your projects into value.

But I was also say, in my experience, almost no projects deliver the value that they originally anticipated in the way it was supposed to be done. There are way too many human factors standing between the plan and successful execution. And I think the best you can hope for is to recover a good percentage of the value you initially set out to achieve. Alright, so that brings us to the end of Episode #89. Thanks so much for joining us, and remember, at Your CEO Mentor our purpose is to improve the quality of leaders globally. So please take a few moments to share this podcast with your network, that's how we reach even more leaders. I'm really looking forward to next week's episode, because I've asked my two daughters to join me to talk about what life's been like for them having an executive as a father. Until then, I know you'll take every opportunity you can to be a No Bullsh!t Leader.

RESOURCES AND RELATED TOPICS:

• Explore other podcast episodes - Here

• Take our FREE Level Up Leadership Masterclass - Start now

• Leadership Beyond the Theory- Learn More

YOUR SUPPORT MATTERS

Here’s how you can make a difference:

• Subscribe to the No Bullsh!t Leadership podcast

• Leave us a review on Apple Podcasts

• Repost this episode to your social media

• Share your favourite episodes with your leadership network

• Tag us in your next post and use the hashtag #nobsleadership