Project Management

The three best lessons I learned from a failed project

Project failures aren't a total waste of time -- those experiences will help teach what not to do to make your next project a success.

I'm sure your resume highlights your project successes, but all experienced project managers have been part of a failed or troubled project at least once in their careers. The 2009 Chaos Report indicated 66% of projects were either challenged or failed to obtain business goals


Project failures may have been marketed as successes, yet the project goals were impacted by reduced scope, a strategic "change in direction" resulting in a cancelled release, or just a large cash investment that failed to provide any real business value. Sound familiar? Go ahead and raise your hand -- I know you're out there. I'll even raise my hand.

When you're part of a failed project, it seems stressful and downright painful, but you have the opportunity to learn a lot of lessons that will help lead you to project successes. Below are my top three lessons from a failed project.

1: The project schedule is your friend

A leading cause of project failures and missed dates is the lack of a detailed project schedule. The project manager may create milestone charts and pretty Gantt charts for executive management; however, if the project manager isn't tracking the schedule that justified the charts, there is no early warning indicator of project delivery problems.

I worked as a business analyst on a year-long Human Resources recruiting project, which involved implementing multiple web applications that supported resume collection and online candidate assessment. The team had dozens of consultants, internal IT staff, and a revolving door of project managers. They had high-level milestones and a fixed launch date for the fall recruiting season.

No one, not even the project managers, had developed an integrated project schedule to keep track of dates, the critical path, or any slipped tasks. During the 10th month of the project, when all the team members were stressed because the majority of the code wasn't ready or working, we had a meeting to lay out the critical tasks to meet the launch date.

I took the meeting notes back to my office and started playing with Microsoft Project. The project executive stopped by my desk, and I showed him the revised project timeline. He asked, "Where was this 10 months ago?" as if he found the one tool to unify all the teams. I had wondered the same thing, and I was just an analyst.

The project schedule is your friend. Sure, it's a pain to put together and continually update, but it's a critical tool for project success.

Key takeaway: Build and manage to a project schedule.

2: You can't escape the project triangle even if you're an executive

In project management courses, we learn about the triple constraint of time, cost, and scope. We all passed the test that validates you can't hold all three sides of the project triangle fixed. In fact, you can't change one side of the triangle without impacting one of the other sides.

Despite these truths, the same executive on the Human Resources recruiting project I described earlier thought he could add more scope without impacting cost or time. We were two weeks away from launching the website when the executive wanted to change the recruiting website's look and feel to include an iPod-like device so candidates could apply to multiple jobs.

The team was in the middle of conducting user acceptance testing when the scope changed. No one questioned the impact to the project -- the executive just wanted it done. The end result was the team exceeded the expected budget, worked a lot of overtime, and wasted a lot of energy that added little business value. 

Despite the executive's mandate for these new changes, the desired functionality couldn't be fully implemented in time. As a result, only a portion of the website was able to launch.

Key takeaway: Adopt a change management process early in the program that all stakeholders will follow.

3: Project heroics only lead to project failure

Heroes only look good in the movies. Trying to apply project heroics to rush a feature into production or thinking that one individual will successfully deliver a project can only lead to failure.

In that same troubled project, the team had hired an external consultant as the lead developer. The developer had a lot of control over the project executive since he was producing the actual product for the project. The executive had confidence in the developer, yet the lead developer spent all day in meetings gathering requirements and little time developing during the day. He would spend another eight hours working until 2 a.m. writing code and repeated this cycle day after day. He wouldn't share the code base with the internal IT staff. During our daily checkpoints, he insisted his code would be ready by the launch date if people would "just leave him alone so he could work." No working code was ever delivered.

Conversely, the internal IT team who was responsible for a portion of the project did deliver on-time because they worked as a team. The team pulled late nights to fix defects and support end user testing.  No one was trying to be a project hero -- the project was simply too big for one person to deliver.

Key takeaway: Build and trust an effective team.


Projects have successes and failures at different points in the project lifecycle,which is why we follow an issue and risk management process. The key to successful projects is to learn from past project failures and to put those lessons learned into action. 

Also read on TechRepublic


Dr. Andrew Makar is an IT program manager and is the author of How To Use Microsoft Project and Project Management Interview Questions Made Easy. For more project management advice visit


Great article, Andrew! The worst mistake someone can make from a failed project is to learn nothing from what happened. With that mentality, they are bound to make the same mistakes again. Your lessons are great insight for anyone undertaking a new project. 

We did some business myth-busting at my company recently, and agreed that project failures don't have to be fatal, as long as you learn from them. Experts say that when you fail, you should call the reason for it by name in order to effectively avoid a repeat offense. If you're interested, here's the link to all PM myths that we debunked:

Andrew -

Good to point out these areas where projects are often challenged. Let me add a couple of thoughts:

1. A schedule is not a plan

An arbitrary schedule, no matter how detailed, is not a substitute for realistic planning. There are at least a dozen tools available to help develop realistic models of how a project needs to be executed, yet the most common approach is the hastily prepared "Key Event Schedule". If you do not adequately plan, based on the size and complexity of the project or program, you have less than even odds the result will be on time, on budget or meet the expected objectives.

2. Scope creep/control and the project triangle

Scope creep is often cited as one of the key contributors to project failures. But to rephrase what blarman said, the root cause is not scope creep, it is lack of proper requirements or understanding of what is to be delivered before the project begins. Given vague or non-existent requirements it is impossible to plan, and scope (or the points of the triangle) will naturally be affected when those defining activities are performed mid-way through the schedule.

3. Heroics

Again, lack of proper planning puts stress on the project resulting in what are often unreasonable demands on people's time. The suggestion of building and trusting an effective team, while important, is useless without proper planning and requirements. There is nothing more demoralizing than having a high performance team whose contributions are squandered due to inadequate planning stemming from poor leadership. It ok to have heroes, but not ok to expect that the success of the project rests entirely on their efforts.

- Casey

Diana Mark Hayes
Diana Mark Hayes

Rushing to get it done, often means you have to rework it or repair it.

Myrna Taylor
Myrna Taylor

You can't win 'em all. Brush the dust off and move on.

Morgan La Femina
Morgan La Femina

that managers never blame themselves only their employees


Biggest one is #2.  Scope creep is the ultimate killer.  You will ALWAYS have scope changes because you are creating something new and until you know what it looks like and how it acts for real, you can't match that very well against what it needs to be able to handle.  But you CAN make sure that everyone - ESPECIALLY - the executives know that after X date, no scope changes will be accepted.  And get them to sign off IN WRITING.  They will ignore it anyway, but at least this way they will know EXACTLY who is responsible for delays.


A very interesting article. I almost hate admitting that I've been there, and learned the same lessons.

Editor's Picks