Factors that cause delay in project (1/3)
Everyone I meet in the construction industry has a theory about why projects fail. Manpower issues, market landscapes, geo-political forces, or the evergreen ‘it is the nature of projects’. All true, in their own way. But I have my own theory.
Let’s define the question. What does failure mean? It means when a project goes over the stipulated schedule and/or over the allocated budget. Leaving quality aside for the moment, these two, time and budget, are the fundamental parameters of project success. And by those parameters most projects today would be marked ‘failed’. So the question becomes, what causes projects to go over time and over budget?
When I started crystallizing my thoughts on this it occurred to me that we’re dealing with a question as old as civilization itself. Man has always been a builder. Did the pyramid builders have this same problem I wonder? Did the ancient greeks – and geeks – also struggle with ‘planned’ vs ‘actual’?
Why does a species that loves to build still battle something as basic as time vs cost? With all the new science and technology at our disposal, what are we missing?
I say we’re missing the big picture. We’re not seeing the forest for the trees. We’re trying to treat something symptomatically that can only be solved holistically.
Think about the human body. Projects are a bit like that – a mass of complex, intricate, and interconnected systems. If, for example, there’s a quality problem, don’t look for the solution in your quality department or your PMBOK manual, look at your engineering team and how they interact with vendors in another country. Look at your email system – are things falling through the cracks because correspondence is simply not getting through in time? Look at the entire project process as a whole, and you’ll solve the specific bottlenecks.
Let’s talk specifics. To start with, Planning.
As the saying goes, for best results, plan twice and do once. But in EPC projects even planning once is a challenge. And the reason for that is the lack of ‘holistic’ thinking. For example: engineering does planning, procurement does planning, construction does it also – but end of the day, all the planning is geared towards construction so instead of planning in silos why not plan with the end in mind? Planning is a means to an end, not the end itself. But the way projects and project organisations are structured, planning all too often does happen in such silos, and does become an end in itself. That is where the trouble starts. If you don’t plan with the final goal in mind, you’re bound to suffer some degree of tunnel vision.
If, on the other hand planning required engineering and procurement teams to think in terms of what is required for construction – what procurement item should be ordered, what utility things are required in terms of scaffolding, what is required for cranes and so on – then everybody works with the same end game in mind. Milestones become just that – milestones. Not deliverables in and of themselves.
And if you plan like this at the desk, then when you finally put the construction crew to work, you’ve already anticipated and solved a bunch of bottlenecks that might have otherwise cropped up and caused, you guessed it, delays. But if you planned with the big picture in mind at every step you won’t end up rushing through things as deadlines loom closer, you won’t make mistakes in haste. And the mistakes you do make (because mistakes are inevitable in a human-driven process) will be easy to catch and correct before they affect the entire schedule.
To sum up: delay is cumulative so the anti-delay steps must be cumulative also. Don’t aim for one change or one set of changes, aim to set up a working culture and environment where constant awareness of the end goal and constant correction to reach that goal becomes a way of life. Do this and you’ll be firmly on the track to effective and successful project delivery, even in fast-track projects.
In part 2 of this series I will address the lack of effective monitoring and how it contributes to project delay.
Leave a comment or a question and I’ll do my best to get back to you.