The stats don’t lie—software intiative often fail.
According to The Standish Group’s annual Chaos Report, about 1 in 5 software initiatives fail. The bigger the project, the more likely this failure is.
And that’s not all. More than half of software initiatives are challenged, which means they don’t come in on time or on budget.
If you’re planning a software initiative for your business, you need to pay attention to what these stats are telling you.
1) Software initiatives are not simple
2) It will be really easy for your software initiative to go off the rails
3) Yes, we mean your software initiative
But it’s not really helpful for us to tell you that software initiatives go off the rails. You want to know why and how, so you can avoid it.
That’s where we can help, by sharing some of the common reasons that software initiatives go wrong (or nearly do).
That way, you can avoid the traps that so many other businesses have fallen into, and join the rare group of companies that successfully launch a software initiative.
TROUBLE SPOTS BEFORE THE PROJECT
The simple truth about software initiatives is that you can set your business up to fail before the first line of code is written. Here are some of the ways that it frequently happens.
1. Poor technology selection
When you’re starting a software project, one of the first tasks is choosing the right technology. This is vital whether you’re talking about an off-the-shelf product that will become your ERP or CRM or whether you’re choosing the right e-commerce option for your business.
This also applies to custom software builds, where you may pick between Python or Ruby or .NET or some other programming language.
Every piece of technology and every programming language comes with pluses and minuses. You need to do research so you are keenly aware of how those positive and negatives affect your particular business need. If you don’t do this before the project begins, you’re bound to face obstacles during the projects. It’s far better to move these roadblocks out of the way early with wise technology choices.
2. Incomplete documentation
For your project to be successful, you need to make sure everyone—project managers, developers, executive stakeholders—knows what the goal of the project is and what it must do to fit into your business’ existing tech stack. The second area is what requirements documentation does. This process spells out the details of integrations, compliance, hosting, and security clearly, so that every other decision can be made with those in mind.
This is especially important when it comes to APIs. We have worked on projects where the API wasn’t finalized before the project started, and this always creates a problem later on. We have been able to navigate these difficulties with our clients, but even in the best case scenario API questions will lead to delays.
So even if you’re a C-level executive who doesn’t know how to read an API, you at least need to know that the necessary APIs are in place before pushing go on a software initiative.
3. Misunderstanding of user needs
This problem is all too common, and it usually happens for this reason: project leaders assume they know what end users (whether customers or employees) want, but never actually ask.
As a result, a project is filled with features and functionality that aren’t really necessary, and it’s missing key things that would make life easier on users. The result is higher costs (from building extraneous features) and delays (from having to go back and address user needs).
The good news is that some work on the front end can help you avoid this trap. This work could look like:
* User interviews by role
* Shadowing users as they work
* Customer surveys
* Or one of countless other options
4. Unrealistic timetables
A software project with a hyper-aggressive deadline that was picked out of the sky is doomed from the start. These kinds of arbitrary deadlines tend to lead to incomplete requirements, untested code, and bug-filled releases.
Deadlines aren’t a bad thing, but they need to be grounded in two things:
1) Real-world business needs
2) Amount of work that can be done in a given amount of time
It’s fine to be aggressive with deadlines, but the people controlling the calendar need to check the deadline they desire with developers to make sure it’s realistic. Once you’ve passed the realistic test, then you can write the deadline down in ink and get to work.
TROUBLE SPOTS DURING THE PROJECT
Even if you get everything right in preparation for a software initiative, you will still face challenges or even failure if you aren’t disciplined about the process of software development. Here are mistakes to avoid while you’re working toward launch.
1. Shifting requirements
Once the project begins, the business stakeholders should do whatever they can to keep the requirements the same. This isn’t always possible, of course—businesses change, and so software initiatives sometimes need to pivot. But as much as your business can, it should keep these changes to a minimum.
This is especially important when the leadership of a business unit changes, or when executives from other parts of the organization check in on a project. Often, these executives will have ideas or preferences that will cause projects to change. This creates a difficulty because these suggestions (or edicts) come without a full understanding of the software’s goals and requirements.
A good project manager will take these suggestions, understand the goals behind them, and then either integrate them or push back on them. This will limit requirement shifts to what will truly make the software end product better.
2. Scope creep delays
Often, the team leading a software initiative is on the same page about the software architecture and the requirements, but once they start to see and test real, working software, they start to get ideas for:
* More features
* More polish
* More user groups
These ideas aren’t bad in themselves, but you can’t include very many of them before you start to see the launch date move farther and farther away. This is scope creep.
Scope creep isn’t bad in an of itself, because adding features to software can make it better. But scope creep consumes time and money in a way that makes it nearly impossible to launch a project. So you will need to be disciplined in identifying scope creep and keeping the overall initiative on course in spite of scope creep.
3. Poor communication
The two points we’ve just discussed show the importance of communication during a project. This includes communication within an internal stakeholder team, with C-level executives, and with the developers who are actually writing the code.
This communication should be clear, and it should be fully aware of the goals and requirements of the software initiative. This will allow everyone to come to consensus on needed changes while otherwise keeping the project rolling along on schedule and on budget.
4. Poorly written code
Your project communication and scope management could be on point, but if the code of your software is not written well, it will eventually come back to bite you. This often happens in the form of bugs, or in the form of difficulties when you need to make changes or upgrades in the future.
Software developers should follow best practices when writing code—DRY (don’t repeat yourself) is one example. But non-developers can help in this area too, by ensuring that these things are in place:
* Code reviews
* Unit testing
* User experience testing for each workflow
This testing can identify problems before they cause pain—which will make launch and the life of the software much more successful.
5. Finishing the last 5%
Even if a software project has gone swimmingly, finishing the last bit before launch will be difficult. The last 5% takes a disproportionate amount of time virtually every time.
So when you run into frustrations or difficulties at this stage, don’t be surprised. Keep to the principles that served you well over the bulk of the project, and you’ll be able to work through the last bit fine. But if you lose focus at this late point, you will sense the project spinning out of control, no matter how well it has gone up to this point.
It’s hard to get a software initiative done on time and on budget. But it is possible. Avoiding these nine trouble spots will help your business keep its software project on the rails.
So take a close look at your planning and your processes, and become one of the rare businesses that can brag about how well your software project went and how successful the launch was.