Guild of Project Controls: Compendium | Roles | Assessment | Certifications | Membership

Tips on using this forum..

(1) Explain your problem, don't simply post "This isn't working". What were you doing when you faced the problem? What have you tried to resolve - did you look for a solution using "Search" ? Has it happened just once or several times?

(2) It's also good to get feedback when a solution is found, return to the original post to explain how it was resolved so that more people can also use the results.

Causes of failures in projects

13 replies [Last post]
Ives Van Meenen
User offline. Last seen 21 years 24 weeks ago. Offline
Joined: 31 Oct 2002
Posts: 6
Groups: None
Hi all

I am writing a thesis about the causes of failures in Projects.

If you have any information or hints about this subject, could you please send them to me? If you are doing some research in the same field or if you want to have information about this thesis, please contact me. My emailadres: ivesvanmeenen@hotmail.com

Thanks much.

Ives Van Meenen (from Belgium, student in Sweden)

Replies

Mehdi Rashidi Ala...
User offline. Last seen 5 years 40 weeks ago. Offline
Dear Ives,
Which industry( software development , ... ) covers with your thesis?

Regards



Forum Guest
User offline. Last seen 2 years 31 weeks ago. Offline
Joined: 28 Jan 2009
Posts: 1
Groups: None
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 steve.madkins@volteurope.com

Many thanks
Steve
Tomas Rivera
User offline. Last seen 5 years 7 weeks ago. Offline
Joined: 2 May 2001
Posts: 139
Groups: None
Hal:

Please do. You can quote me on "schedules as models for decision making".
It would be an honor.

Tomas Rivera
Hal Macomber
User offline. Last seen 20 years 11 weeks ago. Offline
Joined: 15 Jan 2003
Posts: 9
Groups: None
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.
David Bordoli
User offline. Last seen 8 years 3 weeks ago. Offline
Joined: 8 Apr 2002
Posts: 416
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
dbordoli@burofour.co.uk

(Visit Buro Fours NEW website).
Hal Macomber
User offline. Last seen 20 years 11 weeks ago. Offline
Joined: 15 Jan 2003
Posts: 9
Groups: None
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.
Tomas Rivera
User offline. Last seen 5 years 7 weeks ago. Offline
Joined: 2 May 2001
Posts: 139
Groups: None
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
Hal Macomber
User offline. Last seen 20 years 11 weeks ago. Offline
Joined: 15 Jan 2003
Posts: 9
Groups: None
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.
Oliver Sawtell
User offline. Last seen 21 years 18 weeks ago. Offline
Joined: 14 Jan 2003
Posts: 3
Groups: None
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!

Bernard Ertl
User offline. Last seen 9 years 22 weeks ago. Offline
Joined: 20 Nov 2002
Posts: 757
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.
Bryce Phillips
User offline. Last seen 9 years 31 weeks ago. Offline
Joined: 24 Apr 2001
Posts: 15
Groups: None

David Bordoli
User offline. Last seen 8 years 3 weeks ago. Offline
Joined: 8 Apr 2002
Posts: 416
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
dbordoli@burofour.co.uk
Buro Four Project Services
Tomas Rivera
User offline. Last seen 5 years 7 weeks ago. Offline
Joined: 2 May 2001
Posts: 139
Groups: None
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