Why is it that that so many IT projects fail? According to IBM only 40% of IT projects meet schedule, budget, and quality goals. Asking ourselves, ‘why do projects fail?’ is an important one because if we can learn from past project failures we can avoid making the same mistakes twice. And it’s always better to learn from someone else’s mistakes rather than your own! So why not learn from five of my biggest project failures?
Seven years ago, when I first became a project manager, I seemed to learn everything about project management failures the hard way: misjudging estimates, forgetting to ask a client key questions in kickoff meetings, being hesitant to say no, answering questions reactively before checking with my team. I made all of the typical rookie mistakes, leading to those cringe-worthy moments of realization that I had done something very, very wrong.
I’m happy to only have distant memories of the project management failure and more obvious mistakes now but there’s still so much to be learned with every project—and not everything is as black and white when it fails now. While I’ve been a practicing project manager for many years at this point, I’ve still had projects fail spectacularly (with not so spectacular results) for all sorts of reasons. Luckily, I can almost always find a lesson within those in order to do better (or be more aware) next time.
Why Do Projects Fail?
So why do projects fail? Here are five of my biggest project management failures and the important lessons learned:
#1. Not Communicating When Things Got Difficult
I’ve talked about this being a problem with developers and designers on remote teams before, but I’ve been guilty of it plenty of times myself. It’s a basic human instinct to not want to call attention to yourself if something’s gone wrong and no one’s noticed. It’s counterintuitive to the very nature of project management, but poor communication is so often why projects fail.
I’ll admit, the combination of a very difficult client and a budget or timeline about to be blown has made me hesitate just a bit too long in notifying a client of the status of their project. This is especially true when it’s been quiet and all-clear for the last few days or weeks on a project. That’s also the most vulnerable time in your project timeline—it’s so important to retain and foster the trust a client has in their project manager on a web project, and that trust is so easy to blow. I’ve learned this lesson the hard way a few too many times to admit.
Lesson learned:
Lesson learned:
Every time I’m about to pause before delivering difficult news to a client I think to myself: is it better to set their expectations now, or do I want to deal with this after it’s too late? The answer is ALWAYS do it now, and be proactive. You’ll thank yourself later.
#2. Going For “Nice To Have” Instead Of “Need To Have” On A Whim
On a particularly detailed project last winter, a teammate working closely with me suggested we try a new slider plugin for a portfolio section we were working on for a client’s site. It used a framework we typically didn’t work with, but the slider looked and functioned more elegantly than the one we normally used. I was hesitant at first because of the tight timeline and particularly detailed design direction of the project, but I was swayed by the promise of better function for the client AND our dev team. It wasn’t something we had discussed upgrading in our typical toolset in the past, but the timing seemed right and it was a good opportunity to see the new plugin in action.
Of course, you probably know how this ends: it was one of the most costly decisions of the project, in man hours and budget. The slider didn’t end up supporting a key feature we needed once it was installed, and what’s worse, it did not easily support responsive sizing or particular browsers. This would have been so easy to catch at the outset, but it didn’t go through the usual vetting process with tech leads and other developers as a planned update. Instead, we had forged ahead and integrated it into the project.
By the time my teammate got to testing the slider, he realized none of it worked—and instead of going back to integrate (and customize) our usual solution, tried to hack together the pieces that were there to do what we needed. Needless to say, it was an incredibly simple mistake that ended up costing both of us a lot of stress, embarrassment, and wasted resources. Unecessarily ‘gold plating’ scope is another typical reason for why IT projects fail.
Lesson learned:
If your team has a standard and a process, stick with it and don’t update things on a whim. Should your team really need or benefit from a change in tools or tech mid-project, it’s worth going through all of the motions to vet before implementation.
#3. Becoming Too Friendly With Your Team And Clients
I am a friendly person by nature, and I will never repress that. But there’s a definite divide between professional relationships and casual friendships, and I’ve learned to keep those separated through careful practice. That’s not to say you can’t be friends with your teammates or clients—just be aware of when you turn the professionalism on or off in your interactions.
Years ago, I worked at a company full of people just out of college, all with similar interests and living close by each other in our city. Naturally, we hung out after work and on weekends together, forming strong friendships. I became very close with a few designers on my team and even lived down the hall from one of them in my apartment building. The three of us would joke around at work, eat lunch together, and make inside jokes all day.
One day I had to ask for a quick turnaround on a project that no one really liked—it wasn’t pretty, fun, or something that was seen or appreciated by most people. The technology and design were old. It was a keystone account with the company, but wasn’t one of the “cool” ones. My friend—the designer on the project—blew through the deadline, working on a larger, more modern site design he had been given recently to prove himself—but it wasn’t due for weeks. I confronted him about it and he asked me why I was being hard on him when he thought we were friends.
That’s when I realized that I no longer had a line between professional and fun relationships in the office—while we were both young and less experienced at the time that this happened, it can still happen in a more senior situation. A blurring of the lines between personal and professional is sometimes the reason for why projects fail as it can impact accountability.
Act always professionally in your projects, even with your friends.
Lesson learned:
Be friendly but stay professional in order to continue holding people accountable to their actions on a project. It’s much easier to feel we get a “pass” with our friends on things, and that can be a dangerous (and awkward) situation to get into when it’s being mixed with professional obligations.
#4. Panicking Before You Have A Chance To Process Things
Maybe it’s just me, but I find it easy to react to certain red flags or keywords on projects. Things like all caps emails, the words “new deadline” or “site down”, or more innocuous warning signs like lack of communication at a key point of a project, a new stakeholder being brought into a project just before launch, or weird glitches on a site just before client demos.
There is also nothing that makes me feel more flustered than immediately turning to a manager, developer, or client to ask for clarification on something that would have been obvious (or doable myself) if I had taken a moment to breathe, process, and think about my next step.
There have been so many instances where I thought a major bug was present on a site (when it was just an issue with my own or the client’s cache), misinterpreted a request for a feature that seemed much larger than what’s really needed, or a client thought their site/server was down when they really weren’t connected to the internet (yes, that happens a lot). While this point isn’t one large project failure on its own, it contributes to poor communication and can incite panic when panic is not needed.
Calm down and take a breath. Do not panic when panic is not needed.
Lesson learned:
Never be afraid to look away from a reactive email or message, pause, and take a moment to investigate for myself before asking for more help.
#5. Not Using A Process Because Something Seems Small Enough Not To Matter
Ah, yes: the “this item can skip our typical dev/design/review/QA process because it’s just a small change” fallacy. This is so often why projects fail.
So many times I’ve seen this happen on projects all around. I’ve made this mistake with seemingly “easy” maintenance updates, small feature requests on larger projects, and scope changes across the board. Something like updating a form field option might be simple on the surface, but become spaghetti code and a full-system update once a developer dives into it.
Likewise, a client asking for a small visual change on a project might upend the design process and rethink part of the whole site flow as a result.
Lesson learned:
Always trust in the process and go through the discovery, estimation, and QA processes accordingly: I’ve learned that there’s never a small enough change to NOT disrupt something else along the way. Be protective of your process and become a champion for doing things the right way—even if it means just a little bit more effort.
Project management failures can be daunting but there is almost always a useful lesson to be learned from them. While these are just five of the lessons I’ve learned from years of figuring it out the hard way, there’s always more out there for us to gain insight and learn by doing.
What Do You Think?
If you ever hit a moment like this on a project yourself, I hope this helps you think about how you might learn from or prevent project management failures in the future. Let us know about your own sticky situations that have taught you a thing or two in the past! Why have your projects failed? What did you learn from the project failure?
4 Comments