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 Standish Group 2018 Chaos Report indicated 72% 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.
Conclusion
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.