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
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.
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