Itâ€™s not always easy to recognize when your project is in trouble. Yes, if your project crashes and burns and completely fails to deliver, itâ€™s failed. But sometimes you donâ€™t realize that youâ€™veÂ or youâ€™ve built the wrong software and are about to make your users very unhappy. Thatâ€™s why Jenny and I put together our Why Projects Fail talk [pdf] a few years ago: to help people recognize when their projects are starting to go off the rails, and learn a few simple techniques for fixing them. If you learn to recognize the signs of project problems, itâ€™s easier to take action quickly and turn your project around:
Software projects are a lot like cheesy horror movies. After youâ€™ve seen a few of them, you know that the first guy to leave the group is going to get an axe in his head. Projects are the same way. People keep making the same mistakes over and over, and it keeps getting their projects killed.
â€“ Why Projects Fail presentation, slide 6
But what happens when your problems are bigger than just one project? What happens when youâ€™ve got a team, a department, or a whole organization that runs into trouble repeatedly on projects?
When Jenny and I were doing research for our first book, Applied Software Project Management (O’Reilly, 2005), we talked to many different people on all kinds of teams. And when we did, we started to notice something funny. We specifically reached out to people who had bad experiences with requirements, project management, Agile developmentâ€”really, any way of trying to do things better. We were surprised that we kept hearing the same things over and over again, and started to suspect that they were symptoms of deep-rooted project management problems… and teams that were resistant to changing them.
Taking the first step
A list of the most common excusesâ€”excuses that weâ€™ve heard dozens or even hundreds of times, over and over again, from many different teamsâ€”is a surprisingly powerful tool. There have been many times when Iâ€™ve been brought in to try to help a team improve the way they build software. I’d be in the middle of an explanation of, say, why Agile has worked well for me in the past, and someone would give me an excuse that’s almost exactly word-for-word right out of our book. Itâ€™s actually pretty uncanny: how were we able to predict exactly what he would say in advance? But there it is, written down and printed in black and white.
That was the inspiration for the chapter in our book calledÂ Understanding Change. In it, we outline the most common excuses for sticking with a poor way of building software and not adopting something better. If youâ€™ve ever tried to help your software team adopt a new tool, technique, or practice, youâ€™ll see some very familiar arguments there.
Here are the top excuses that weâ€™ve heard from teams that canâ€™t admit that they have a problem. Theyâ€™re all straight out of Applied Software Project Management. Treat each of these excuses as a big red flag, and you can use this to your advantage. If youâ€™ve ever watched an episode ofÂ Intervention, you probably know that the first step to fixing a serious issue is admitting that you have a problem.Â Do they sound familiar to you? Have you ever heard any of them before? If so, itâ€™s time to take the first step.
But if you do take the step and admit that you have project problems, thatâ€™s good news! It means that there are plenty of time-tested, tried-and-true ways to help your team. (Of course, if youâ€™re a regular reader of Building Better Software, you already know that!)
Each of the following excuses is excerpted from pages 206 through 213 ofÂ Applied Software Project Management (Stellman A and Greene J, Oâ€™Reilly 2005). You can read a lot more about each one (and what you can do when you hear them from your team) in that chapter.
We Already Build Software Well
Denial is a common response to change. You may have identified a glaring problem, but people around you fail to even recognize it (or simply refuse to acknowledge it). Many professional software engineers and managers have never experienced a project that did not have enormous delays and serious problems; itâ€™s often assumed that this is just part of how software is built. After all, they usually delivered somethingâ€”most projects were eventually completed, and the software they built is now being used. Sure, some projects seem to always be eternally 90% done (with 90% left to go), but most of them seem to get something onto the usersâ€™ desktops (although many patches and bug fixes needed to beÂ rolled out afterward). Isnâ€™t that good enough?
â€œNot Invented Hereâ€ Syndrome
â€œNot Invented Hereâ€ syndrome (NIH syndrome) is a name given to a common type of organizational culture where people intentionally avoid research or innovations that were not developed within the organization. When faced with a problem, the people in the organization will typically reject a solution that is known to have worked elsewhere in the industry, solely on the grounds that it did not originate from inside the organization. They opt instead to build their own solution, often at far greater cost.
Itâ€™s â€œToo Theoreticalâ€
When an idea does not make intuitive sense, many people will dismiss it as a result of â€œacademic research,â€ which could not possibly apply to the world they live in. For example, to someone without a project management or softwareÂ engineering background, it may not be immediately obvious that reviews reduce defects, or that itâ€™s important toÂ write a specification before building software. To him, these procedures are time-consuming, with no obvious benefit. They sound good in a book, but would never work in the organization. In other words, they are â€œtoo theoretical.â€
It Just Adds More Bureaucracy
An especially damaging attitude in some organizations holds that programming is the only important activity in a software project. Project management tools and techniques are seen as distractions that drain energy and effort away from the programmersâ€™ â€œreal jobâ€ of writing code. Any project activity that takes place before the programmers begin writing code simply amounts to â€œspinning our wheels,â€ and the goal of all early project activities should be to get the programmers doing the â€œreal workâ€ as quickly as possible.
You Canâ€™t Give Me More Work!
Most of the changes that a project manager makes will increase the workload of other people. Software engineers, managers, and stakeholders who were not directly involved in building software will suddenly find themselves expected to attend status and review meetings, participate in planning and estimation activities, work with someone creating aÂ vision and scope document or eliciting requirements, or perform other tasks that were never expected of them before. If you are making these changes, then you are the person piling additional work onto someoneâ€™s already overflowing plate. Not surprisingly, there are people who will not be happy with this arrangement.
Itâ€™s Too Risky
The economist John Maynard Keynes once wrote, â€œWorldly wisdom teaches that it is better for the reputation to fail conventionally than to succeed unconventionally.â€œ Legendary investor Warren Buffett put it this way: â€œLemmings as a class may be derided but never does an individual lemming get criticized.â€ In other words, any manager who backs a change puts his reputation on the line; if that manager does nothing, he will not be criticized for maintaining the status quo.