21 October 2014
Top 3 Reasons Why Software Projects Fail
by Doug Alcorn
I was recently asked by a new employee for a list of all the reasons a software project can fail. At first I thought it would be a huge list, but as we discussed it I realized nearly all the reasons boil down to three key things, and not a single one of them is directly related to technology.
Why? A high functioning team can almost always overcome technological problems. But people and communication issues tend to be much trickier. Here’s a look at the three most common reasons why teams break down and development projects fail:
1. You don’t understand the value of the project
Building custom software is risky, so it’s crucial that everyone on the team — from the client to designers and developers — understand why they’re building the project. What’s the real value to the company? What is the real problem you’re trying to solve?
Our most successful projects are ones where the client brings us a problem. We then dive into the problem as a collaborative team. Who’s problem is it? What are they really trying to accomplish? How will they know when the problem is solved? What will solving this problem mean to the clients’ bottom line?
The opposite also holds true: Our least successful projects are when clients bring us a solution they want built. During the sales process or early discovery, they’ve told us they know what they want, and they just want us to build it.
What’s the problem here? The team doesn’t really understand the context of the system they are building, so they’re not equipped to make all the little decisions along the way that affect the Big Picture.
How did we mess up the big picture? One small ignored detail at a time.
— Torbjörn Gyllebring (@drunkcod) October 15, 2014Or the client hasn’t dug deep enough into the problem, and we end up building a vision that turns out not be valuable to the business or organization. It’s important that the whole team understand the value of the project. A well built solution only emerges when the whole team is aligned to the same purpose. Everyone needs to be involved in the discovery process. Keep asking “Why?” until the value of the project and its solution becomes clear.
2. Your team isn’t really functioning as a team
It is incredibly difficult to predict the future, particularly when it comes to software projects. All we really have is an accurate picture of the now. This requires the whole team to be transparent with each other to keep the project on track. Fear is the road block that keeps us from telling the whole truth. The client fears that if we knew everything about their business we’d take advantage. There’s a false perception that clients need to play their cards close to prevent over billing. And sometimes there’s a political situation within the company they don’t want the development team to know about. The client might be afraid the team would lose confidence or respect.
As developers and designers, we have fears, too. When we get stuck on a problem, we’re afraid of looking bad and don’t want to raise the red flag. So instead we stay stuck for too long then get embarrassed about how long we’ve been stuck. It leads us to clam up and hide as we think, “Just one more day and I can fix this.” Or maybe we’re afraid of losing the deal, so we hold back when we know something we think the client won’t like.
All these fears ultimately hinder the project and slow it down. We’re robbing ourselves of the chance to adjust course and solve problems together.
3. You’re just not paying close enough attention
There’s a continuum. On one side you might drop of your requirements and a check to the dev team then come back in six months and hope for the best. That’s not paying attention at all, and it’s unlikely you’ll end up with the software you really need.
On the other hand, teams can have constant interaction. My best case scenario is when a client works full-time in our office and sits with our team. All those micro-decisions we make all day, every day are made with the whole team present.
If the client isn’t available, one of two things can happen: The team can wait to get the answer, or they can make the decision themselves. When the team is waiting on the client, it puts everyone in a bad position. The team could just press on, but there’s a good chance they’ll do something wrong. They could shelve it and start something new but that just increases risk of getting it wrong. Or the dev team could do nothing and wait.
All these options build up frustration for the team and client. If the client doesn’t have enough time, it could lead to rubber stamping whatever the team is doing. That’s blindness to the true state of things and leads to frustration down the line. All these tiny missed opportunities add up over time until the project is off track.
And Solutions!
Even with clear, continuous communication, it’s possible to get stuck in the weeds and lose sight of the big picture. Paying attention means always asking, “Where are we and are we on the right track?” Try following these four rules.
- Always focus on the real problem being solved and the value being provided.
- Strive for tight integration among the whole team: client, developers and designers.
- Always be clear and truthful about the current state of the system.
- Engage as fully as is possible.
Here at Gaslight we’ve been working hard to create an environment where it’s easy to engage at this level. We still mess up, and it’s likely we’ll never get it 100 percent right. Our hope is to continually improve. This often means improvements in our technical mastery. More often, though, it means improving our interpersonal skills and client relationships.
