Skip to main content

What makes projects fail?

I need your help: I'm working on a talk about why projects fail and how to prevent failure. One of my favorite exercises from my Scrum training was listing all the ways a project could fail. I'd like to come up with a list top causes. So please write a quick comment with your candidates (or better still, tell the story of a "favorite" failure).

Once I have enough candidates, I'll set up a poll, so we can vote on the biggest causes. All results will of course be published in this space.

Thanks in advance for your help.

P.S. I'll add my own candidates after I have some responses. I don't want to prejudice the results.


Brett said…
1) a project manager browbeating the developer into saying something is xyz% done (eg 93% done) so the msft project document shows progress. What the heck is 93% of a feature? Either its done or its not done.

2) management telling a team member what their velocity *should* be.
Anonymous said…
Unless you are in a mature industry such as banking or insurance, where information is the life-blood of what you do, chances are you will be familiar with at least some of these 10 project management failings put together by Robert Francis Group analyst Mimi Ho.“One, they’re right on the button and two, if you take a look at the large majority of them, it all has to do with project planning and early stages of analysis that companies like to jump over,” said Jeff Monteforte, owner of Exential, an independent project management consultancy in Cleveland, Ohio.

In other words, when IT projects fail it rarely is a result of the technology. At its core, project management is all about people.

“Even in some of our clients, some of them are doing very well … and others are just starting where they don’t even have executive support and they get the executives saying ‘Just start the project I don’t care what you do’,” said Ms. Ho. “And projects fail … and they’re like ‘It’s IT’s fault.’”

The Top 3 problems Monteforte, a 20-year veteran of the project management business, encounters most often are: lack of executive support; changes to project scope and the lack of change management; and failure to establish user expectations which leads all too often to unrealistic deadlines.

The Top 3 project killers he encounters are: lack of executive support; lack of pre-project planning; and insufficient people (not monetary) resources allocated to get the project done.

Ms. Ho also sees the same problems—especially lack of executive support—as Monteforte but adds poorly defined project requirements to his lists.

“You need to speak with stakeholders directly because the bill changes or they visualize the project being a certain way but when it’s communicated the project could be different,” said Ms. Ho.

According to RFG and Ms. Ho, what follows, in no particular order, are the 10 most common pitfalls to successful project completion:

Undefined or poorly defined project requirements. - Project managers should collaborate directly with key project stakeholders to define specific detailed project requirements and deliverables. Defining specific project requirements is necessary to maintain alignment of project tasks to desired business outputs, as well as to ensure that projects have clear and specific project objectives established.

While this step may seem obvious, many companies will skip this stage and go right to solutions to jump start a project. Business and/or IT executives assume the requirements (such as controls, dashboards, data, dependencies, functionality, integration, metrics, outputs, and workflow) are met without performing any confirming analysis.

These projects tend to fail and the companies usually encounter over spending, project restarts, rework, and/or unmet expectations.

Lack of project planning. - Once the requirements are known, then conducting thorough, upfront project scope planning is an essential next step to help project managers and stakeholders accurately and clearly define project scope.

It is important for people to understand that there is more than one way to achieve the requirements and that scope and cost vary by approach. Project scope management is therefore necessary to develop reasonable project estimates, enhance the management of customer and stakeholder expectations, and mitigate project risks such as cost overruns and schedule delays.

Project managers should establish and standardize a scope management process to develop concise project scope statements and credible budget and schedule estimates.

Lack of or poorly developed budget forecast. - Thorough research and preparation is necessary to develop a reasonable budget estimate. Many companies will skip this step or just do a very rudimentary estimate due to the amount of work needed to complete the task.

Some companies that do not maintain internal archives of project costs turn to external consultancies to acquire external spending/budget information on companies that have completed similar projects in a similar market.

Using the estimated budget, project managers should collaborate with stakeholders to help further refine the project scope and final deliverables. Project managers should use their initial budget to base actual spending plans as well as to proactively track spending and respond quickly to potential issues to prevent shortfalls in the budget.

Lack of stakeholder involvement. - Project managers should ensure that primary project stakeholders are involved with the project from the beginning and throughout the entire project. This is crucial to ensure that visions are properly communicated, defined, and verified.

It is very common for project efforts to be delegated to staff that do not have sufficient knowledge or understanding of the desired effort. As a result, projects are defined incorrectly and the projects delivered do not meet the expectations of key stakeholders.

Lack of executive support. - An IT project can be highly political and may end up involving an excessive number of unnecessary or incorrect participants. IT executives should seek ongoing senior management endorsement and enforcement of the planning process to keep the effort on track and to minimize pushback from line of business (LOB) managers.

Support from senior management and staff involvement are both needed to drive and keep the effort focused and moving. Ownership of the project must be shared to satisfy the demands of user management. IT executives must convey this message to senior management to retain involvement and participation.

Frequent or large changes to project scope. - Scope changes can significantly impact the cost, schedule, risks and quality of the entire effort. Project managers should watch out for early and frequent changes to the project scope.

While scope is defined early in the planning and estimation phases, there are valid reasons for change. For example, a stakeholder may acquire additional insight into a problem during the course of the project or external market conditions and/or government regulations can drive requests that extend beyond the initial project scope. However, changes to project scope can also occur as a result of developing a poor initial scope document.

Project managers must ensure that adequate time is spent on defining and refining the work effort directly with key stakeholders.


Neeraj- Project Manager

Popular posts from this blog

Sample Definition of Done

Why does Scrum have a Definition of Done? Simple, everyone involved in the project needs to know and understand what Done means. Furthermore, Done should be really done, as in, 'there is nothing stopping us from earning value with this function, except maybe the go-ahead from the Product Owner. Consider the alternative:
Project Manager: Is this function done?
Developer: Yes
Project Manager: So we can ship it?
Developer: Well, No. It needs to be tested, and I need to write some documentation, but the code works, really. I tested it... (pause) ...on my machine. What's wrong with this exchange? To the developer and to the project manager, "done" means something rather different. To the developer in this case, done means: "I don't have to work on this piece of code any more (unless the tester tells me something is wrong)." The project leader is looking for a statement that the code is ready to ship.

At its most basic level, a definition of Done creates a sh…

Explaining Story Points to Management

During the February Scrum Breakfast in Zurich, the question arised, "How do I explain Story Points to Management?" A good question, and in all honesty, developers can be an even more critical audience than managers.

Traditional estimates attempt to answer the question, "how long will it take to develop X?" I could ask you a similar question, "How long does it take to get the nearest train station?

The answer, measured in time, depends on two things, the distance and the speed. Depending on whether I plan to go by car, by foot, by bicycle or (my personal favorite for short distances) trottinette, the answer can vary dramatically. So it is with software development. The productivity of a developer can vary dramatically, both as a function of innate ability and whether the task at hand plays to his strong points, so the time to produce a piece of software can vary dramatically. But the complexity of the problem doesn't depend on the person solving it, just …

Money for Nothing, Changes for Free

“Money for Nothing, Changes for Free” encourages both customers and suppliers to focus on value.

A key advantage of Scrum projects is that at least once per sprint you have something that could be shipped and no work in progress. You can change direction every sprint, and you can reevaluate whether the project is a good investment or if your money could be better spent elsewhere. Abrupt cancellation is risky for the supplier.

While the concept of an early-exit penalty is not new, Jeff Sutherland gave it a unique allure with his allusion to the Dire Straits hit.
Desired Benefit Incentivize both customers and suppliers to focus on functionality that provides genuine value.
Structure This works with Agile software projects because there is little or no work in progress. After each Sprint, functionality is either complete or not started. Work is basically on a Time and Materials basis with a cost target, often with the intention that the project should not use up the entire project budge…