Causes of failures in projects

Dear Ives,

Which industry( software development , ... ) covers with your thesis?



Regards

You could always implement a Volt Europe product called e-PSO. It will control your processes and ensure projects are delivered on time and within budget. Dont believe me ? Check out www.e-pso.co.uk for further information or e-mail me on [email protected]



Many thanks

Steve

Hal:



Please do. You can quote me on "schedules as models for decision making".

It would be an honor.



Tomas Rivera

David,



Funny you should mention Glenn. I am a member of the Lean Construction Institute. Glenn and I work together off and on throughout the year. Greg Howell, the cofounder of LCI, is my business partner. Greg and I help firms implement a lean approach on their projects in construction, engineering, software, and production.



No need to subscribe to Reforming Project Management. The article The Top Ten Reasons Projects Fail was written by Frank Winters.

Hal...



I like your Should - Can - Will title... makes me think of Beverly Knights Shoulda Woulda Coulda (Beverly Knight), anyway I digress!



Glen Ballard at the Lean Construction Institute devloped a system called Last Planner which is very similar to your S-C-W system (take a look here).



An ychance Hal that you could publish your 10 reasons paper on here, save us having to subscribe to the site.



Best regards



David

[email protected]



(Visit Buro Fours NEW website).

Tomas,



Schedules as models...I like it. May I quote you? Seriously. At one time (that moment that the schedule was developed) the plan looked like a good idea. Later, as reality hit us, the (original) schedule was no longer possible, but...the thinking that went into it serves as preparation for the new decision in front of us.



Planning is great preparation for the inevitability of plans that cant be followed...particularly when we include performers in the planning. (Lets not separate planning from execution, in spite of the position of PMI.) When the performers are involved in planningthey too are prepared and ready to participate in the inevitable replanning.

Hal:



I often listen to or read comments about projects not occurring as planned, leading this to some kind of frustration. We should go beyond and overcome this state of frustration. Schedules should not be viewed as something that must be done that way, no matter what. If a schedule is not met exactly as planned should not be viewed as a problem.



I think we should have a different perspective. Schedules should be viewed as models for decision making. Models that helps us monitor our path and gives us the ability to make decisions along the way to meet our objective. If some things are not done and others are, our model should tell us what the consequences are. The evaluation of these consequences will lead us to decisions that in turn will take us toward our goal. If there is a delay of the project finish date, we will see what activities are causing this delay. We should find out why this happened, what we are going to do to avoid future occurrences, and what we are going to do to get back on track. The better our model the better the information produced, and therefore the better our decisions.



Tomas Rivera

Project failures in construction, defense (engineer-to-order), and software all have the same principal source. Planned work is not in a ready condition for starting and finishing. Do you want project performance to soar? Try should-can-will planning.



Planning often ignores the practical issues of dependence and variability. We all understand projects are networks of tasks. In our planning we cant know that tasks will occur exactly as we plan. A better way to say this is we do know that the future is uncertain therefore tasks wont occur just as planned. Consequently, shortly after the plan is prepared performance is falling short of expectations. We add to the uncertainty and variability by beginning work that isnt ready and by working out-of-sequence. Working out of sequence is a principal cause of project failure, yet a symptom of something we can address.



We can choose to only do work that should be done (on the plan), that is in a condition to be done (all conditions are present for starting and finishing), and that will be done (performers have promised to do so). This is called should-can-will planning. Try it.



BTW, read this posting for stories from gantthead.com and builder.com on project failures.

The most common cause of project failure in my field (IT), and in the industry sector I work in (Spacecraft Manufacture). Is usually internal politics. This usually manifests itself in a site/countries self interest overriding business need.



As a result, projects (small or large) can result in projects having high numbers of stakeholders all who have to agree on the way forward (and rarely do). I usually spend my time in negotiation with our own people, just to overcome objections.



Sadly Prince 2, has not yet been accepted as a legitimate PM tool, and this is due much to "Not-invented-here" syndrome from our colleagues located external to the IT departments in the UK!

It might help to clarify what is defined as a failure.



Turnarounds (maintenance projects for oil refineries, petrochemical plants, etc.) are much more intensive than construction projects and often will incur unavoidable delays due to force majure (bad weather, critical equipment breakdown, plant emergency outside the project scope, etc.). Depending upon the circumstances, managing these challenges effectively can still yield a "success" even if the project overruns time or budget goals.



Off the top of my head, I can think of many factors that could cause time or budget overruns that I would classify as a project failure (bad planning or management):



- Critical material shortages or delivery delays

- Critical tool shortages

- Critical resource shortages (labor or equipment)

- Inadequate field supervision

- Inadequate communication between field and planning prior to and/or during project execution

- Poorly defined bid packages when soliciting contractors

- Schedule updates performed too infrequently (problems compound before they are identified)

- Schedule updates performed too late (information is obsolete by the time management sees it)

- Planning and scheduling at the same time (usually results in estimates tailored to fit expectations)

- Scheduling to fit managements expectations versus reality

- Planning at a summary level of detail (yields too much uncertainty in the reporting cycle)



Bernard Ertl

InterPlan Systems Inc.

Ives…



My last forays into academia related to delays in construction projects, which I reckon are a pretty good indicator of failure. One of my references related to the caused of delay, this is the gist of it, the reference follows:



“A recent survey found that almost 60% of all claims in construction projects were a result of just three factors; post-contract changes by the client, different site conditions from what is stated in the tender document and unfulfilled duties by the engineer/architect.” [Onyango, D. Reduction of conflicts in construction. MSc report, Loughborough University of Technology. (1993)].



Let me know if you’d like the full breakdown of the figures or the relevant text verbatim, I am sure I have the report somewhere.



On related topic this to me seems to show that those who anecdotally criticise contractors for causing most delays to construction projects are wrong!



Regards



David

[email protected]

Buro Four Project Services

Ives:



In general, the one cause of project failures is inadequate application of proper Project Management.

In my experience, the one knowledge area that needs more improvement and which, at the same time, will benefit projects the most, is Time Management. Schedules rarely reflect the true changing behavior that occurs everyday in a construction site. Therefore, they do not serve as a desicion making tool for those desicions that must be made everyday. If you do not have a tool that guides you through your everyday desicions, then your schedule is not going to be used for these desicions. Instead, your schedule will be used only for more general, mid term, strategic type desicions.

Then, the questions are: Are my everyday desicions taking me through the path envisioned by the project schedule? How do I match these tactic desicions with strategic requirements? Will I be doing this using a formal procedure or will it be done by the seat of the pants?

This is just a thought (and discussion) provoking concept.



Tomas Rivera