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.

Comments

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.

Cheers

Neeraj- Project Manager
neeraji2it@gmail.com

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…

Scaling Scrum: SAFe, DAD, or LeSS?

Participants in last week's Scrum MasterClass wanted to evaluate approaches to scaling Scrum and Agile for their large enterprise. So I set out to review the available frameworks. Which one is best for your situation?

Recently a number of approaches have started gaining attention, including the Scaled Agile Framework ("SAFe") by Dean Leffingwell, Disciplined Agile Development (DAD), by Scott Ambler, and Large Scale Scrum (LeSS), by Craig Larman and Bas Vodde. (Follow the links for white papers or overviews of each approach).

How to compare these approaches? My starting point is Scrum in the team. Scrum has proven very effective at helping teams perform, even though it does not directly address the issues surrounding larger organizations and teams. An approach to scaling Scrum should not be inconsistent with Scrum itself.

Scrum implements a small number of principles and constraints: Inspect and Adapt. An interdisciplinary Team solves the problem. Deliver something of va…

Five Simple Questions To Determine If You Have the Agile Mindset

My company has started a top-down transition to Scrum and Kanban. Will that make us an Agile company? About 2 years ago, I attended a conference hosted by the Swiss Association for Quality on the topic of Agility. As a warm-up exercise, the participants were given the 4 values of the Agile Manifesto, then asked to arrange themselves in space. How Agile is your company? How Agile do you think it should be? Very Agile on left, very traditional on the right. There was a cluster of people standing well to the right of center. “Why are you standing on the right?” It turns out that they were all from the railway. “Our job is to run the trains on time.” They were uncertain whether this agility thing was really aligned with their purpose.
Is Agility limited to software? Steve Denning has collected the evidence and laid out the case that Agile is not limited to software, nor is it merely a process, nor is it something you can do with part of your time, nor is it something you can have your …