Today my attention has been captured by what I would define a trivial article, which claims to teach the five main causes of delays in projects and, above all, to provide also some lousy solutions.
I do not like to discredit the work of others, but I am convinced that when writing something, one must have solid arguments.
Now I'll discuss these 5 proposed causes and in our final chapter about our point of view we will introduce how the TOC Critical Chain Method is the only practical approach that deals in depth with the objective of making project delivering on time.
Here a link to the full article for who wants to read it. https://www.projectpractical.com/5-main-causes-of-project-delay-in-it-industry-and-how-to-avoid-them/
Cause 1. Unexpected Risk
Saying that unforeseen risks are the main cause of project delays is a triviality; it‘s like blaming an external factor. It's not risk itself the cause of delay: the art of project management, among many others, includes how to manage risks correctly and how to manage complex network of interdependent events.
In reality, in the majority of the cases in fact projects have lot of safety in their estimates.
We can classify these safety factors into:
Safety added by the task and estimation owner: usually owner estimates tasks based on his worst experience. Usually those who provide an estimate, try to stay in a comfort zone between 80% and 90% to deliver on time. Given the probability distribution shown in the graphic (which is not a normal distribution in the case of projects), if the actual estimate has a 50% probability to come true, to have an 80 - 90% probability the estimate provided has to be about 150% - 200% the average.
Safety added by the resource owner: if a project has 2 tasks in parallel, and we assume that their estimate (already protected by safety) is 5 days each for a total of 10 days, then the department owner will add an additional contingency - say 3 days - to protect himself about blaming. So 10 days that already included a contingency of about 150% to 200%, plus at the top the contingency of the department owner 5+5 = 13. The more the resource managers who review the estimates, the more security is added at the top.
Safety added to protect from budget cuts: normally an additional security is added to compensate for the typical estimation cuts of the people who will sell the project.
In short: normally a lot of safety is added to every task, and all this safety must protect against unexpected risks (Murphy and statistical deviations). The problem is not the risk itself, and not the lack of safety, but the way safety is added and managed.
The goal is to become more effective in managing safety and buffers. See our conclusion for some Tips.
Cause 2. Inaccurate Estimates For Project Requirements
"According to a report by the Project Management Institute (PMI), 39% of projects fail due to inaccurate estimates when it comes to project requirements. When you do not have all the important requirements recognized and documented, it is impossible to achieve the goals and objectives of the project."
This point is true, but the problem is again trivially solved. Each project, in its initial stages, has a perimeter and requirements that are still unclear. At this stage estimates and budgets can be of a qualitative nature.
It is the purpose of an initial phase, which we call Discovery & Define, to define in detail the objectives of the project and therefore the requirements to achieve these objectives.
Estimating the executive project chart before completing this phase is pure guessing. And it is also responsibility of a good project manager to make it clear that any budgeted estimates provided before the requirements are defined in detail is a non-executive budgeted estimate.
If a project has not been completely estimated, it is almost useless to talk about delays: delays will have to be measured with reference to the real executive plan and project charter that will have to be formed after a careful definition of the requirements.
In short: it is the goal of a well structured project to define the requirements. If they are not clear at the beginning, then the good project manager has to carefully plan the initial Discovery and Define phase to consolidate the requirements. If the Project Sponsor wants to move ahead to implementation even with a portion of specs undefined, then it is sufficient to split the project: one stream aiming to complete the specs definition and the other stream to start implementing the initial specs consolidated. It adds risk but manageable. Let’s move on.
Cause 3. Unengaged Project Sponsors And Stakeholders
Although it is a problem, identifying it among the main ones means not having analyzed effect-cause-effect implications carefully. Lack of Project Sponsor attention is not an ultimate cause of delay. The need to have continuous contact with project sponsors to defend project goals is the necessary effect of another cause, which are the cultural constraints induced by a mentality rooted in the cost world.
In the "Cost World", every function and every department is exclusively focused on maximizing its own performance. So if a function does not get particular benefits from the project, the function head will tend to contribute little, not to say hinder it. In this case then yes, a strong involvement of the project sponsor is required to smooth the angles and manage internal frictions.
If an organization were to be permeated into the "Throughput World", this type of need and necessity would be greatly mitigated. Business functions are no longer evaluated around their local objectives, but around global results, and therefore the level of friction to be resolved for the project sponsor would be drastically reduced.
In short the real problem is the lack of right policies and culture that makes the needs to escalate to the project sponsor so necessary and frequent. The ultimate cause is the culture of the company rooted in the Cost World, with organizations structured in silos to maximize local efficiency. A project is by definition cross-functional. This is the reason of friction with the functional/hierarchical organizations.
Cause 4. Inadequate Resources
The problem of resources is a real problem, but the solution offered is far from being adequate.
"The only way to ensure that inadequate resources are not the cause of any delay in the project is to draw a good estimation of resources in comparison with timeframe, scope, and budget. When all of these aspects are relatively measured, they can be brought in conformation with each other. Especially, the resources must be by the timeframe, scope, and budget of the project."
The point is not just having an estimate of how many resources are needed, but it is necessary to know at least:
Their capacity: a resource can produce 80 units of an activity in the time period, a more skilled resource can produce 150 units in the same period
Resource contention: it is necessary to know if resources are shared with other projects, in order to set proper resource buffers
It is necessary to know if there is any active capacity constraint, and in that case create a finite scheduling around the constraint and place a buffer in front of it
In short: it is not sufficient to drive just an estimation of the resources needed by time period. It is necessary to schedule each activity/resource on the Critical Path in order to identify the real Critical Chain of the Project.
5. Dependency Delays
Dependency is an intimate part, is in the nature of project, so of course unmanaged dependencies are main cause also of project delay..... It is like saying: project characteristics are cause of the delay of projects. Of course projects have to deal with dependency between tasks. Dependency is the nature of any process that implies the execution of activity (may them be sequential or in parallel) whose start depends on completion of another activity. So saying that projects go south because there is dependency between tasks is really not adding any real value. It is obvious.
"According to PMI, 23% of projects fail due to dependency delays."
I do not understand: 23% of project fails due to dependency delay. Does this mean that remaining 77% of projects do not have delay but are failing for something else? Or that in the remaining 77% the delay in the dependency is absorbed by some buffer se the project doesn't fails? It's not clear at all, but it doesn't matter. it is more interesting looking at the proposed solution
The most efficient way to make sure that the project is not delayed due to interdependencies is to come up with a flexible schedule that includes enough time and space to incorporate such delays. It can be done by setting up more than one deadlines for the project tasks. Then, the schedule must be developed in a way that the tasks are completed before the last deadline.
Such proposed solution shows that there is no real clue how to manage a project and that the real causes, that are inherent in human behavior, are not understood at all: what is the advantage of setting 2 or 3 deadlines for the task? It is extremely pointless:
If I have a taks that says:
if you can, deliver it in 5 days (best estimate)
but it's okay if it can be done in 8 days.
but the mandatory deadline is 10 days
Of course anyone will be mentally fixed to the last 10 days option, as the only quote to be respected, the other 2 will not even be taken into account.
Or maybe it is more subtle: i tell my resource i need it within 5 days, but in reality "i hide a buffer of 5 days"....
The real point dealing with dependencies and uncertainty is not providing several dates or keeping the plan flexible: if a PM replan constantly to keep a plan flexible, then the only result he achieves is to create a chaos and to lose focus.
The real point in managing uncertainty and dependencies is how to manage safety buffer correctly in a project.
Our point of view: using TOC Critical Chain to manage the Real Causes of Project Delay
Of course we strongly disagree with most of the presented considerations. We try to explain the key causes of project delays from our point of view that is based on TOC Critical Chain.
Let's define a project first
A project is a set of interdependent activity that:
Has an objective and requirements to accomplish
Has a budget: the desired, or expected or estimated cost to implement it.
Has a desired, or estimated planned duration
So first of all, it is important to divide the project into two major phases. Leaving apart the more detailed phases of PMBOK methodology: Discovery & Define (the phases aiming to define the SOW and Project Charter) and Delivery (from Detailed Design to implementation, testing and acceptance to Project Closure).
The Discovery and Define phase shall start from a draft articulation of the project goal, and shall end up with a well defined project objective, against which a detailed requirement list and a detailed project charter and SOW shall be defined and approved.
A well defined project objectives shall define the improvement results that are expected form the project. "We want to implement a new ERP with the objective to achieve those minimum result: x% reduction in inventory; x% improvement in lead times; reduce x% the time from the moment we identify the need to place an order to a vendor and the time the order is placed; etc."
The project shall have an indication of the expected duration: "when do i need to have the project completed in order to not jeopardize or lose too many of the expected benefits?"
Then the project shall have a desired budget cap: "how maximum the project should cost to achieve the minimum desired financial improvements?"
Some TIPS to conduct this phase:
Define carefully the project goal and its expected contribution against the organization goal. A project is tactic against a strategic goal, so its result cannot be evaluated if it is not expressed in terms of contribution against the organization overall goal.
Define and prioritize requirements relatively to their contribution to achieve the project goal: "how much the functional requirements allows to meet the project objective of reducing the inventory of x%?"
Do not factor project decisions only on the "project cost" (its price): consider the cost ramifications of longer lead times.
The TOC Thinking Processes are the best tool to organize and conduct such kind of activity, how to analyze requirements, their contribution to the project goal (Future Reality Tree, Strategy and Tactic Tree) and how to implement them (Prerequisite Tree and Transition Tree).
Only conducting this kind of analysis applying TOC Thinking Process it is possible to come out with a clear map of requirements and their relative importance to the project objectives and the overall organization‘a goal.
With this map done, is then possible to estimate the efforts and thus confirm duration and budget of the Delivery Phase.
If it came out that in order to achieve the goal it is needed a longer duration or a greater budget, then the organization can evaluate if it is acceptable a longer duration and a higher spending or if it is acceptable reducing the objective (so the requirements and so the cost) of the project.
At this stage it is possible to compete the final Statement of Work (SoW) and the project charter and estimate against well defined requirements.
Any project that try to enter the implementation phase before doing that, is its own risk.
So let's assume we have done our exercise well in the Define and Discovery Phase, that we have all the elements to estimate our Delivery Phase. Is now the project safe? Not at all. There are plenty of causes that can still make the project go south and delay.
Here the real main causes:
Murphy: although with low probability, a catastrophic event may happen. To protect against Murphy it is necessary to add a contingency protection for risk
Statistical fluctuation: if the time needed to execute an activity in average is X, then there is 50% of probability that the activity completes on time or before its average. It is necessary then also to add safety to protect against the other 50% of probability an activity takes longer than estimated.
Parkinson Law: the estimation tends to be self-realizing. People tends to use all the time they have and, if they finish early they are reluctant to communicate the saving). Because of that saving are wasted,while delay accumulates. Savings and delays rarely compensate each other.
Adding protection and safety to each task. These lead to two other major causes of delay. The fact that protection in each task is wasted, because it is sufficient that one task go south that the benefit of completing a parallel task in advance is wasted; and the Student's Syndrome: as people knows they have safety and contingency, they tend to start tasks at the last minute. This way they burn all the protection they have
Multitasking: it is the main killer of lead times. Excessive multitasking is a major cause of delay in projects as it extend and duplicate activity lead times, increasing the risk of resource contention and so on
Resource contention: the critical path of a project is almost always defined without accounting that maybe the same resource has to take care of more tasks and, even worst, that resources are shared with other projects. This is a real major cause of delay
Is there anything we can do to control and mitigate so many factors of delay? Of course, there's a lot we can do.
The TOC Critical Chain Method for Project Management (CCPM) provides the Project Manager with tools to address all these topics:
How to manage properly safety and buffers to avoid to waste them and to protect effectively from variation and risks Instead of placing safety to each task, TOC suggest adding three types of buffers to protect the times: the project buffer, that protects the critical chain from fluctuation and risks, the feeding buffers that protects the critical chain from other project ramifications (the non critical path) when they meet with the critical chain, and resource buffers to be sure to have the resources in place when needed. Plus a capital buffer to protect from cost and financial risks (cost of resources, cost o labor, etc)
A different approach to manage estimation of tasks removing safety from each task and thus minimizing the Student's Syndrome and Parkinson's Law effects.
A different way to manage resource contention issues around the Critical Chain, a concept that goes beyond the Critical Path.
A different way to measure project progress, that avoid losing focus from the critical chain and what is really important
An approach - derived from the Five Focusing Steps of TOC to manage the Resource constraints
In conclusion TOC Critical Chain for Project Management is the most innovative Body of Knowledge to manage the problems of dependability and timeliness in project environment since the definition of PERT and PMBOK.
Agile and Scrum have tried to make some progress, trying to crop complex projects in mini independent releases (in other words to cut dependencies in chops of mini projects) but have not provided nothing to the hearth of managing variations and delays. In other words: I can chop a complex project in 20 mini releases (sprint) each one of 2 weeks. As they are small maybe the delay for each become five days each, but then multiply by 20...
CCPM is the only method that deals with variability and human behavior from a complete perspective and the only method providing solution to mitigate them.
To discover more about the TOC Critical Chain Management, have a look to our TOC Starter Kit Program.
Comments