Built On Vision



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

For other articles please visit Saddik & Associates

Diego Sanmiquel
Scheduling Best Practice - Monitor and Remedy Dangling Activities

While it is generally considered a best practice to insure that a project CPM schedule has only one start activity (an activity with no predecessors) and one end activity (an activity with no successors) with no other open activities, project schedules are often not evaluated for dangling activities.

 Dangling activities plague many schedules, and their presence in an active schedule causes inaccuracies which potentially result in wrong critical paths and incorrect milestone and completion dates.

 An activity with dangling start is an activity with at least one predecessor, but none of its predecessor relationships are of the type Finish-to-Start or Start-to-Start. In the example below ....

Please continue reading the rest of the article at:



For more articles from Farid Saddik, please visit SaddikAndAssociates.com

Diego Sanmiquel
Schedule Analysis, The Case For Edge Activities

For a variety of reasons, it is often the case that only a subset of the schedule activities is analyzed. Sometimes a specific operation is under scrutiny, other times a specific subcontractor’s tasks are examined, or a fragnet of a specific collection of activities is analyzed. Additionally, schedules with several thousand activities, or even several tens of thousands of activities are becoming increasingly common. Such jumbo or mega schedules are inherently difficult, if not impossible, to analyze at a meaningful level of detail without breaking them down first.

Analyzing a subset layer of activities introduces a new set of assumptions and challenges. To name only a couple of such assumptions and consequent challenges, the dates of the first activities of the various subset paths are assumed to be accurate and fixed. Exclusion of activities which are not a part of the subset but are in the middle of a path may cause an artificial path discontinuity.

The concept of Edge Activities is to introduce a necessary companion subset of activities that are connected as predecessors, successors, or both to one or more of the primary selected subset of activities being examined. An Edge Activity, as such, is defined as an activity which is not part of, but is directly connected to one or more of, the activities in the selected subset.

Please continue reading the rest of the article at:


Diego Sanmiquel
Plotted Planned & Actual Duration Sum As Powerful Forensics Indicators

The entire set of activities in a project schedule is presumed to capture the entire contract work scope. The duration sum is an aggregated metric of the total number of work-days required to complete the entire contract scope of work. I cannot emphasize enough that each of the numbers from a single schedule by itself is not meaningful. It is not to be confused with contract duration, critical path, or longest path. But when you plot a collection of snapshots representing a baseline and periodic updates of the baseline, you see a powerful indicator. When you contrast the plotted Planned (Original) Duration Sum (PDS) line against the plotted Actual Duration Sum (ADS) line, you may be able to identify likely schedule analysis paths and more.

You can continue reading the rest of the article at:


Diego Sanmiquel
Proactive Project Controls Paradigm

The Systems Engineering discipline teaches the concept of a feedback loop to monitor any process with the intent of taking corrective actions, as necessary.

There are many expressed variants of the concept that are being applied to design, construction, manufacturing, software, banking, and just about any discipline or industry that requires processes.

The concept when fully understood and applied, carries several implicit sub-concepts and nuances. Unfortunately the reduction of such into a single simple graphic has invariably yielded the loss of some significant portions of the concept.


The root concept is Design-Implement-Feedback and loop back. The implied sub-concepts are:

  1. The concept is fractal. Design, for example, does not normally occur in a vacuum. Some need is identified, analyzed, then a design is planned and implemented, with feedback that will help “tweak” the design.
  2. Identification and analysis are implied in most representations of the concept.
  3. Feedback aggregates tracking and controlling.
  4. The process is assumed to have completed before it loops back.
  5. The model assumes perfect communication.

You can continue reading the rest of the article at:


Diego Sanmiquel
Relationship Types and Out-of-Sequence Change Trending

Scheduling Forensics Series

Pick a medium to large size completed construction project at random. Assemble the project schedule and all of its updates. Compile the out-of-sequence (OoS) and relationship type metrics. If you analyze the metrics, you’ll almost always find two things: a) activities that were performed out of sequence, and   b) a strong correlation between out-of-sequence change increasing over time, Start-to-Start and/or Finish-to-Finish relationship types trending up over time, and project cost overruns.

An activity OoS condition occurs when a successor activity’s actual start and/or finish date violates any of the restrictions imposed upon it by relationships, or physical date/resource constraints. In a simple example if activity B has a Finish-to-Start Predecessor A with zero lag (FS=0) and activity B was progressed with an actual start date that occurred before activity A’s actual finish date, then activity B is an Out-of-Sequence activity.

The reason an OoS condition occurs may be one or more of the following:

  1. Bad or unrealistic planning which causes activities not to be performed according to plan.
  2. Changed execution without being pre-modeled in the schedule, which in turn may be indicative of:
    1. Project team’s inability to follow plan,
    2. Too many disruptions that are too frequent to plan around and reflect in a workable schedule, or
    3. Too many outstanding issues that create too much uncertainty to plan remainder of the work.
  3. Schedule activities’ scopes are vague or too general. When a schedule activity scope is vague, its actual start and finish dates are often hard to pin-point. When a schedule activity is too general, modeling its relationships is tricky and sloppy at best.

If modeling what actually happened on a project is necessary for the specific type forensic analysis being performed, then it becomes necessary to identify and remedy OoS activities.

Remedying OoS activities after the fact entails one or both of two methods, depending on the OoS condition(s):

  1. Narrowing the scope of the activity in question by splitting it into two or more activities. That also requires adding relationships and changing some of the existing relationships to model actual progress or exact as-built sequence,
  2. Changing types of relationships and their lags. Typically, a finish-to-start relationship with zero lag is replaced with a pair of start-to-start with some lag and a finish-to-finish with some lag.

In order to remedy OoS activities it is necessary to identify every OoS condition that occurred on the project, along with its type.

It is worth noting that the leading scheduling software does not adequately identify and list all OoS activities. P6, for instance, is content with listing only OoS activities that occur around the data date. If an OoS condition occurs in between two schedule updates data dates without either of the OoS-causing relationship activities touching or crossing the two data dates, then P6 calculation logs will not identify OoS conditions that may be associated with such activity.

An advanced forensic analysis software will be required to identify and trend OoS conditions and their types.

Trending OoS activities over the course of the project execution cycle is important for a first look at whether the project was executed substantially per plan, whether it only experienced periods of issues, or whether it was totally executed off-script. Such information allows the analyst to quickly focus on specific periods, or even specific types of operations, depending on the sophistication of the analysis filters.

Trending details of OoS conditions, such as identified specific period, types of operations, and/or types of OoS conditions may be crucial in helping the analyst establish tangible likely causes/effects of disruptions, delays, or concurrency.

The ability to trend relationship type changes is equally as important in completing the picture above. A graph that shows finish-to-start relationships decreasing while start-to-start and/or finish-to-finish relationships increasing is an indication of attempts to remedy OoS conditions as they occur, as the result of contract requirements or attempted best practice. While the attempts typically fail to capture all of the OoS conditions, as discussed above, the resultant relationship type changes tell an equally as compelling a story as not having remedied them. The idea is whether or not the OoS conditions are remedied, their occurrence trends how closely a project was executed according to plan, and if not when and possible how and why.

 This article draft is available in PDF at:


© 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.


Diego Sanmiquel
The Reality of Current Construction Risk Modeling

Most Construction Risk analysis tools available today stress a stochastic approach to modeling risk and offer an alternate deterministic approach that is discretized to Best-case, Worst-case, and Likely. The scant deterministic approach can hardly model real projects risks. The vague stochastic approach, by itself, does not begin to model real projects either.

The lack of proper tools has derailed construction risk analysis. It is not logical to assume that productivity profile risk is similar to weather risk.  While there may be some isolated success stories, and while there are usually other contributing factors, the overwhelming majority of large and complex projects risk analysis fail to identify, model, and analyze risks. The result is almost always delayed projects that cost a lot more than originally contemplated.

Estimating, design, procurement, permits, weather, and latent conditions are among the major factors that are blamed for delays and cost overruns. Can anyone seriously contemplate modeling estimating risks based on random probabilistic model and expect useful results? Modeling weather risks as best-case, worst-case, and likely scenarios would be equally as irrational.

Most productivity-related labor risk is quantitative by its very nature. Organizations typically maintain a good history for the various crew production rates. Such data deserves better modeling than a purely stochastic approach, or a fatally over-simplified deterministic one.

Proper modeling dictates a hybridized approach that enhances the quantitative component while allowing a mixed calculation mode with dials and switches for the risk analyst to manage the process.

I am hoping to prioritize writing a full article detailing the enhanced hybrid quantitative model I proposed.

Diego Sanmiquel
Normalized Productivity - Continued

When we define and understand the various components involved in a task input and output, we develop a real picture of the task performance to-date and we are able to assess means to improve real productivity going forward. If the assessment is for forensics purposes, to evaluate a claim for example, then understanding all the components of input and output is key in assessing the effect of various claim factors on real productivity.

As important as it is to understand and appreciate the current state of the industry deficiency, I'll be publishing a full article soon on Normalized productivity. Stay tuned.

Diego Sanmiquel
Normalized Productivity

The universally-recognized abstract definition of productivity is the ratio of output to input.

Construction and other industries today have adopted a narrow subset of productivity and generalized it as “the” productivity. Construction productivity, as utilized today, is not a useful metric to rely on for monitoring project health, creating reliable cash flow and forecasts, deriving schedule durations, or evaluating claims.

The productivity methods currently utilized fail to consider that true productivity requires a complete set of “inputs” and a complete set of “outputs”, both additive and subtractive, and not just the number of widgets per labor unit. While input and output components vary from task to task, they are almost never as simple as the ratio of a single output to a single input.

More on that later.

Diego Sanmiquel
Chasing Project Productivity

Current techniques and tools utilized for project productivity analysis leave several unconsidered factors. A normalized project productivity technique should be contemplated for proper productivity analysis. Normalized productivity takes into account unit cost, production rate, and production capacity. It is otherwise possible to attain, for instance, productivity that is 25% better at twice the cost and half as slow. More on that later.

Diego Sanmiquel