Frank WintersPhotographer and ConservationistSandwich, Ma, United States
In your experience, what are the primary causes of project failure? I have my personal top ten list, what's yours? In particular, what can be done to improve the abysmal success rate of IT projects? If we solve this conundrum, let's move on to world peace! Saving Changes...
Tim ArthurRetired| SelfPalm City, Nc, United States
Projects fail because project managers do. That's a little vaugue. I see two reasons, and only two.
We've beat around the proverbial bush, but not directly stated it. The number one reason is "lack of honesty". Despite what our guts tell us, our voice often does not keep pace. We know, all too often, if a project is in trouble and destined for ?failure?. As Neal Whitten says, project mgr?s greatest deficiency is courage. Having the courage to talk with under performing team members, or customers that generate excessive change or unrealistic expectations. We can be honest with our management team and discuss scope changes or another exit strategy that is more palatable than real project failure. Also, consider Jeannette Cabanis-Brewin's classic article at http://www.myplanview.com/expert7.asp
Reason number two is less concrete, and for lack of better terms I will call it ?the phantom variable?. If you?re lucky, you will survive just one or two phantoms. If you?re inexperienced and rushing things through, you should expect tons of them. Phantom variables are things that we fail to give the proper attention to. If the project runs over budget, it?s because we didn?t pay close enough attention for instance to upfront budget planning, cost tracking, etc. The core concept of Project management is simple, yet it is also very complex. As project managers we are asked to keep track of tens or hundreds of thousands of variables. While broad level methods such as risk management are useful, things do slip between the cracks. Recall the number of communication paths for a mid to large size team, for example. As PMs, we have to admit to ourselves, our customers, and our teams, that we will never be perfect and know which of the phantom variables might eventually bite us. I consider myself seasoned with PM but recognize that each project has hidden gotchas. We work to minimize those through the many great tools that the project mgt science provides. Given the reality that the phantoms occur, we can basically mitigate by insurance. Some of the best insurance that our ?money? can buy is a) developing trust and a great rapport with the customers and team members so that our forgiveness factor is high when (not if) we will need to use it, and guess what? back to honesty again. When we?re honest about what we?re seeing and sensing, we reduce our chance of failure.
There are many good contributions in this discussion and I don?t mean to simplify them away, but I do believe that at the end of the day the PM community at large would do well to focus on these two attributes.
Further, I'm not saying that if you've had a failed project, you're a liar. Any experienced project manager has had failures. Each one should teach us more about being open and candid not only with ourselves, but our stakeholders.
I would add that projects fail when the project sponsor didn't clearly understand the cultural impacts of the project and didn't talk about them with the project steering committee. A good project manager, when included in this type of discussion, could beef up the "communications" section of the plan to address stakeholders. Saving Changes...
Anonymous
Culture of communicaion. 1. The business leaders will do everytihng in their power to avoid confronting the need to talk , listen and respect the IT groups needs in planning projects properly. 2 Often IT organisations are not equipped to translate their needs and build effective relationships with the 'money men/women' to manage their expectations effectively. Saving Changes...
Why do Projects Fail is a question which cannot have a definative answer. The discussions should focus on the point where a project manager can save a project to fail by adopting tactics and strategies in different stages of the project which are in his control. Could be: 1. Defining Goals and communicating them 2. Requirements Defination 3. Project Planning and Tracking.....etc
But all of this seems too bookish. In the practical ground the reality is that projects fail due to lack of "HARMONY".
Its like an orchestra, where all the different instruments produce a single harmonious music. If a one of the instrument player is not doing his job correctly, then the result will be a chaos.
The same applies with the projects. A project manager is a director who holds together all the pieces of this orchestra to deliver results.
All the stake holders have equal responsibility for a success of the project. The project manager is the adhesive which holds them together in Harmony.
Saving Changes...
Mike Cooper PMPPrincipal Project Manager (retired, sort of)| New England Project ServicesWestford, Ma, United States
Regarding Frank's latest article on this topic, estimating, people sometimes struggle to even attempt to give an estimate for a project where it is anticipated that there will be a high degree of change.
Sometimes it helps to consider the triple constraint triangle - you know, the triangle with the three sides of cost, scope, time. Change one and at least one of the other sides changes. Well, when considering a project where scope cannot be clearly defined early on (perhaps a new type of application is being built in an iterative manner), the scope side of the triangle is subject to change. Perhaps we can constrain one of the other sides.
Consider time. Perhaps we can define a project life cycle whereby we will do the following:
Step 1 - develop high level project scope, identifying the main objectives
Step 2 - develop an overall technical architecture
Step 3- develop a release, consisting of the following substeps:
Step 3A - spend one week developing a prioritized list of requirements with the users
Step 3B - spend two weeks developing the release. Stop work after two weeks. You may not have implemented all the requirements, but you knew what priority order to implement them in
Step 3C - spend one week stabilizing the release, testing it.
Step 3D - spend one week training users and deploying the release.
Now go back to Step 3A. In effect, decide how many times to go over the Step 3 loop.
We can now predict how long this project will be. If we do three iterations, our project will be 15 weeks plus whatever Steps 1 and 2 take. So we are in a reasonable position to make an estimate - if we can constrain the resources on the project, say we provide one full time business analyst, two developers, one tester / documentor, and a parttime project manager, we can now easily create a reliable estimate.
Of course, we still don't know exactly what we are producing, and we may find out that we need a fourth, or even a fifth, iteration. But these can be handled via our change control process (you do have one, don't you?!?). After each iteration you should re-examine the business case for proceeding. Of course the above is only an example, you may need longer, or shorter, loops. But this approach can be used to obtain a budget and a timeline for what at first might seem to be an impossible to estimate project.
I first go here. very glad to see so much good ideas. Saving Changes...
Frank WintersPhotographer and ConservationistSandwich, Ma, United States
A question about failure due a system that can't handle the load it needs to was just posted. The question was "how can the PM recover?" from this failure.
There are two ways to answer this -- first of all if the perception of failure is unfair -- say the load could not have been anticipated -- then the PM needs to make the facts clear to the powers that be. Do this for the sake of the team and the truth.
But if in fact the load should have been understood and not enough was done to determine what it would be, then the PM must admit mistakes and take a hard lesson away from the project.
Failure is compounded when we fail to learn from our mistakes. Saving Changes...
G'Day Frank: Good you have resurrected this valuable topic. Quite often we run the trap of measuring project success in simple metric terms of schedule or budget conformance. Even when we apply simplistic definitions of quality (i.e. compliance with specs), we can still incorrectly assess the performance of a project.
KPI's are the best guide, and project KPI's must be expressed in outcome or business terms, not simple project metrics.
To cite a non-IT example where KPI's would have proven a project success. Brisbane City Council is a very large entity ($2B p.a. budget). Just recently Brisbane Council opened a 750m section of high tech floating walkway as part of their ongoing commitment to community access to the Brisbane River.
The project was totally canned by the feral press - all on the basis of a 20% budget overrun.
I recently spoke with the Mayor at a civic breakfast and said to him: "Mayor Tim; How come Council did not raise the fact with the press that the project was eminently successful in at least six major KPI's. As a piece of public infrastructure it is visibly successful - the public takeup is outstanding". "And Mayor Tim, Why was the press allowed to criticise budget anyway, when there was no qualification as to whether they were discussing the variation from the concept budget, the business case budget, the detailed design budget, or the latest approved baseline". Of course none of these concepts are of value to a Feral Journalist.
But a project management entity should be able to successfully present these metrics for stakeholder scrutiny.
By the way Frank: If you cite me as a critic of the Feral Press; All I can say is: "Yes, Sir! Guilty as Charged!"
David Hudson, Australia. Saving Changes...
I see the same problems over and over again. Apparently the need to learn or prevent the project failure is not really there.
It seems to me that there is a lack of understanding that project/program management is actually a part of the deliverable. Then suddenly the quality aspect applies also to the PM and the management supporting the PM (roles & responsibilities, escalation and signoff structure).
From experience I consider basic project management very simple, deliver on time on budget. But as project/program management needs to change with the business delivering on time and on budget is just another part of quality and process management.
Delivering a project means delivering a business outcome, not a pure technical solution, the business doesn’t care what technology is on the background, it just needs to work and deliver what’s expected. Off course there are technical issues and solutions, but by focusing too much on these and a lack of translation towards the business results in risky implementations, ie a technical state of the art solution the business is not going to use.
Often a very difficult technical issue can be easily resolved by changing the underlying business processes. This is what I encounter very often, a serious lack of business understanding and even a fear of educating the business, customer AND vendor.
I encounter too much PM’s who have just one schedule and no alternatives, my opinion is that there should be at least 3 separate schedules/ Project Management Plans, 1) the contractual agreed schedule/PMP, 2) point 1 which also shows the build in slack and risk mitigations, 3) a schedule/PMP which has actual options and alternatives.
These should be expanded in a technical aspect and a business aspect.
Regards,
Michael Feddema
TUSC Technical Manager Saving Changes...
Frank WintersPhotographer and ConservationistSandwich, Ma, United States
Michael thanks for posting your thoughtful reply. I agree that projects are multi-dimensional and that a multi-dimensional plan is needed.
As to why we keep seeing the same problems over and over -- I think its because commercial business organizations do not know they are playing with fire: the kind of fire that can burn through money and ruin companies pretty fast. Senior management seems to think that there is no way to control project costs and results, so in some cases they don't try.
The other thing I see -- I recently saw this at a very high profile company -- people without the basic training and experience are appointed to positions with responsibility over how projects are managed and controlled. They are clueless regarding what to do and yet are left to fend for themselves for years while the projects under them drift into failure. While PMI has a long way to go, this issue does call for a generally accepted body of knowledge and training that is routinely taught in business schools. This is not the solution but is a necessary building block for establising project management where it belongs in our corporate cultures. Maybe my great grandchildren will see this become a reality.
Saving Changes...
