Why Projects Fail
Most projects fail. If the definition of a project’s success is completing a reasonable product within the planned time and within the contemplated budget, then most projects fail. Even though this observation is meant for construction projects, it is equally as applicable to defense, oil and gas, and other sectors.
To be sure, there are degrees of failure. Most small project failures are mild to moderate. Larger projects are prone to more severe failures, with extremes such as the Boston Central Artery/Tunnel Project (The Big Dig), Kemper IGCC power plant and the San Francisco Bay Bridge which epitomize severe failures of the product quality and/or suitability, the time they took to complete, and the enormous cost overruns.
There is a common root cause of projects failure, large and small. In order to understand that common root cause, let us examine our current project universe of structure, elements, processes, and work flows.
With acknowledged variances, the typical project stakeholders are the investor/Funder, owner, designer, construction manager, contractor, operator, and end-user. The typical project elements are design, quantities, labor, equipment, material, fabrication, cost, revenue, plan, time, safety, quality, geography, environment, timing, and profit. The entailed metrics affect, and are affected by risk, issues, and changes. The catalyst is personalities and human nature. The final interacting elements with each project universe are the portfolio contexts for each of the players.
As a society, we’ve completely bought into the concept of collaboration. We’ve convinced ourselves that collaboration is good. We believe it results in good communication, therefor we’ll reduce or eliminate miscommunication by collaborating. However, as a society, we are averse to accountability, and at least businesses are averse to transparency.
Collaboration, while it may or may not have started this way, is nothing more than the label given to selective metered directional information flow. We silo each and every element in the project universe and we may permit each silo a limited pipe of information between some but not all, and such information flow is not even necessarily bi-directional; and that’s for the silos within a single stakeholder’s organization. The information pipes between silos diminish and become more restricted when they cross a stakeholder’s organization.
As counter-intuitive as this may sound, collaboration as such does not take down silos; it fortifies them.
Sophisticated contractors analyze quantities and labor hours, but seldom in the context of equipment utilized, safety and quality profiles. Issues are evaluated primarily in the context of contract structure, which causes detrimental issue resolution deferrals. Project and program management planning is rarely dynamically calibrated in the context of the various stakeholders’ portfolios. It is almost always the case that project risk analysis is token, defective, ignored, or severely undervalued. We often see projects going to construction with the full knowledge that the design is nowhere near stable enough to support construction, just so that the project catches some funding deadline.
The tools we utilize are also a reflection of the collective “collaborative” mindset. If you are a software maker that releases a collaborative software that does not provide a high degree of user access segmentation and hierarchy, your software would not be well received and would be deemed to have a serious flaw. Each stakeholder wants to control the type and level of information each of the other stakeholders receives.
Furthermore, the current software model, at least for the construction industry, promotes elemental isolation. On a typical average or large size project today, you are likely to see one or more estimating application, ERPs/Job Costing, many external add-ons to the ERPs/Job Costing, and many spreadsheets tracking detail quantities, pay estimates, look-ahead schedules, forecasting and more. You’ll also likely see scheduling software, schedule analysis software, workflow/document management software (usually presented as the collaboration component), Risk Analysis, CAD, BIM, and office productivity suite. While there are some attempts at limited integration, each of the listed components remains largely a stand-alone application with marginal ability to export useful data to, and lesser yet ability to import usable data from others. The software model fortifies the silos even more.
If you inspect the various contractual models, the numerous standards and best practices, and the prevailing execution models, you’ll find that most promote adversarial and armored silos approach.
Is the root cause for projects failure elemental isolation (the silos)? The answer is no. While the silo-effect is a primary cause, it is not the root cause.
The root cause of projects failure is the very project model. Simply put, it is defective and I am not even certain that there is an easy way to fix that model, if at all.
I do not have a detailed solution. I do not believe that one person does or can. To solve this conceptually however, all elements must be tightly integrated within the project universe itself, with mechanisms for full transparency and accountability. All external elements interacting with the project universe still need to be sincerely and accurately evaluated and coordinated. Technology providers need to create better tools that promote a tightly integrated project model. The devil will, indeed, be in the details.
I believe that the industry, from all sides, has a lot of intelligent and genuinely caring professionals that can provide enough will and brain power to replace the current project model with an integrated model that works.
Copyright © Farid Saddik, 2015. All rights reserved.
No portion of this article may be reproduced in any form, or by any means, without prior written permission from Farid Saddik