Tech projects are hard. If you work in the tech industry, or have worked on a tech project in some capacity, you already know this. They are hard to get right, hard to get done, and hard to even get started. 68% of tech projects fail in some way. Only 2% of companies regularly achieve software project success.
Now that all that gloom-and-doom is out of the way, let’s take a look at why they fail, and how you can minimize your risks.
Our People Matter
Companies are made of people. Even programmers are people, albeit strange ones at times. And people are all different. Put the right ones in key positions; play to their strengths, their ambitions, even to their egos. But the wrong person in the wrong role can disrupt everyone else.
Look in the Mirror
Once you know your people, know yourself. Take an honest moment of reflection. The biggest marker of an organization’s software success is its business analysis capabilities. Do you and your team have the chops? It’s ok to say no. That’s why there are consultants; you can “rent” their insight and competence to help you through a project. Remember, paying for success is much cheaper than paying for failure.
We Didn’t Define the Problem
Technology is only valuable if it does something better than the old way. Rewriting a 17-step manual process from MS-DOS so it’s a 17-step manual process on an Ipad isn’t solving the problem. Now it’s a problem that employees can experience on the go!
Some problems show themselves pretty plainly; things that cost money (and shouldn’t) or upset employees, things that turn off potential customers, or things you want to do but just can’t. Problems can also be identified by turning them into opportunities. Sentences like: “Our company could save X hours per year in productivity automating this,” or “A rewrite of the site would allow us to implement an in-bound marketing strategy to drive leads and sales.” Framing things as an opportunity help you describe what success looks like.
Planning Time? Let’s Just Gather Requirements In-Flight
Modern Agile and Iterative project management methodologies give a lot of flexibility to software teams, but they don’t eliminate the need for a good plan. You can throw a lot of resources at a project, but with no clear path to success, you probably won’t use them wisely.
You Never Told Me to Communicate
I was recently on a project where the client compartmentalized pieces of the project between different teams. It was only after a casual conversation with a programmer from another team that I realized he had a largely similar set of requirements. We cut down the size of the project by nearly a third by sharing code between functional units. Without that chance encounter, the timeline and budget for both would have been greater.
I’m not saying that you need more meetings, but don’t assume everyone knows what you know. Implement a formal communication mechanism; whether it’s a wiki or team-leader huddles, let your team do what they’re good at.
The Demo isn’t Till Tomorrow, So Just Sneak This In
Writing software is a lot like running a race: the Agile methodology even calls period of work “sprints.” Olympic runners don’t dash towards a moving finish line, so don’t expect your tech team to respond gracefully when expectations change. You might have to spend more planning time up front but everyone will be happier when the runners cross the finish line.
The Competition Has this Feature, We Need it Too
Don’t let your competition drive your project. They might have a different problem to solve, so chasing after them may not serve you at all.
While we’re at it, and don’t fall in love with the latest cutting edge technology unless it solves your problem. You might feel like the cool kid on the block by being cutting edge, but it might incur significant cost because it’s not in your team’s core strengths. In fact, the very nature of cutting edge tech is that it’s not in anyone’s core strengths- even Google’s.
There’s an old saying that the only finished software is dead software. The rest of it, the stuff that people use, is still subject to change. With that in mind, understand that your new software project will not be perfect. Not by the third demo, and not by the final demo. So don’t obsess about minor details; keep your focus on solving the problem. Even if it isn’t solved perfectly. The software will continue to grow and change over time, especially if it solves a problem.
There are many ways a software project can go wrong, but only a few ways it can go right. Stephen Covey’s famous statement, “Begin with the end in mind” is an important lesson to getting it right. “The End” is working software that is worth the cost of building it.