Once upon a time, there was a $5-billion pharmaceutical company called FoxMeyer Drugs. In 1995, the company decided that it was time to move into the technology age, and invested in a new Enterprise Resource Planning (ERP) software. They carefully chose a company to work with and set aside a budget of $100 million for the project.
But when it came time to unveil the new software, the unthinkable happened. When the new ERP was first released, order processing decreased from 420,000 to 10,000 per night, simply because the new software couldn’t keep up with needed volume. Things went from bad to worse, and within four years, the company was filing for bankruptcy and the company’s trustee was knee-deep in a lawsuit with the software company.
Now that’s bad software.
No one in the industry likes to talk about it. Frankly, it makes us all look bad. And even though the numbers are getting better instead of worse, they are still far from ideal.
According to a recent study by the Project Management Institute, a full 15% of IT projects were deemed failures in 2017.
Failures. Not partially successful. Not on time, but over budget. Complete and utter failures.
Custom software isn’t cheap, and it’s depressing to know that you can invest $100,000 or more and still have a 15% chance of failure.
There’s no doubt that this is an industry-wide problem, growing from the sudden intense need for custom software in so many industries. For the past decade, software companies have fought to keep up with demand.
If you’re thinking about paying for custom software, take a careful look at the company you choose. If you want one that is serious about completing successful projects, here are three things to look for:
3 Ways the Best Companies Keep Software Projects from Failing
They Put Money into Process
We’ve heard it again and again: “I was all ready to have you write my custom software, but then my neighbor told me he has a cousin that can do it for a tenth of the cost. So I feel like I should go that route.”
Of course you do. If I could buy a candy bar for $1 or $10, it’s no secret which one I’m choosing. But we aren’t comparing candy bars to candy bars here.
You might think there are several obvious reasons why the price is that much cheaper: no office space, no overhead, a one-person shop, etc. That’s why you’re getting a good deal.
Some of that is true. But there’s another huge factor.
Even assuming that the nephew’s programming skills are up to snuff (which is definitely something to look into—every kid with a laptop thinks they can program these days), there’s one HUGE difference between George working out of his bedroom and what you get at EduSource: Process.
Here’s an enlightening finding from a study completed by IBM: the best software companies are 10 times more successful than the worst organizations. Ten times! What separates them? Process.
Process is what makes sure that you get the same results after doing something over and over and over again.
Writing software is an incredibly complex process. And if you are just sitting at your computer with a vague idea of where you’re going, you’re simply never going to get there. There are so many pieces to a good software process. Our software-writing process is long and complex (and will be a whole blog post at some point), but here are some of the steps:
- Story analysis: Breaking features into User Stories, and making sure each one is sized appropriately and has client-approved acceptance criteria (to make sure the programmer and the client are aiming at the same thing).
- Code Review: Making sure code is written to high standards, which ensures that other developers will be able to pick it up and improve on it, even years down the road, and that the logic is sound. (At EduSource, each piece of functionality goes through seven reviews by other developers, each looking for specific issues.)
- Architectural oversight: There are an infinite number of solutions to a good software project. How do you know if your solution makes the most sense? Presenting potential solutions to a forum that includes software architects ensures that the logic works (and you won’t have another company telling you later, “Yeah, I think we’re just going to start from scratch on this”).
- Internal testing: Quality assurance testing is something you’ll find in any custom software shop. But you won’t find it with cousin George in his bedroom. For testing to work at all, someone who is not the developer has to complete it.
There’s so much more to our process, but those are some of the high points. If you are having custom software written, ask about the company’s process. If it’s not well developed, keep looking. Strong process is the only way you know the company will be able to repeat past successes.
They Put in Time Before They Ever Touch the Keyboard
One easy way to have a project fail: don’t have a defined goal you’re aiming for.
Here’s the problem: you know that you need custom software. You know the problem that needs to be solved. You even think you know HOW it should be solved. But when the software is complete, it really doesn’t fix the pain. It doesn’t solve the right problem in the right way.
How do you fix this? Lots of time up front, for both the client and the software company.
That’s why we require a Discovery Session for any company that hasn’t already gone through one with someone else. Here’s what it is:
We spend 2-3 days meeting with your team. Our team spends plenty of time observing how your team does work and taking relevant notes. Then we spend time brainstorming with your team, narrowing the ideas down to find your specific pain and identifying the best solution. Then our team goes to work, creating user experience (UX) mockups, architecture overviews, a budget estimation, and a list of User Stories to get your project started. Finally, we spend time with your team again, presenting our plan. We want to make darn sure that the money you’re investing will solve your problem.
At the end of this process, we feel really confident that we are building software that will change how you do business.
If someone offers to build you software without spending a significant amount of time with your company, know that the chances of success aren’t good.
They Have a Method for Staying on Track
Before you commit to a software company, ask how they keep on track with timelines and budgets. There are many good ways to stay on top of these things. At EduSource, we use a method we call Daily Layered Accountability (DLA).
In addition to being able to make a computer sing, software engineers are also pretty good at math and statistics.
We’ve put those skills to good use with our sophisticated DLA metrics. Let’s see if we can explain this in a way that’s easy to understand…
First, we use something called Agile Kanban as a software methodology. We track the Kanban progress of our User Stories using Jira, a project management software. Using Jira and Kylo (a data lake management software), we are able to automatically figure metrics for each of our projects each morning. (If you’re really curious about how all of this works, give us a call. You can come in and observe our morning meetings. We’ll tell you all about it.)
When our teams get in each morning, they are looking at how well they are doing on:
- Delivery (we take the earned value of what we’ve created and divide by the planned value of where we should be, which gives us a ratio showing us if we’re on target or not)
- Efficiency (how many User Stories are on track to be overdue based on how many days are left until they are due and how complex they are)
- Cost (we take the earned value of what we’ve created and divide by the actual cost we’ve spent to get a ratio that tells us if we’re on budget)
- Quality (how many Kanban columns have more than a max number of User Stories in them)
Each and every day, these metrics are calculated automatically. In morning meetings, teams look at these metrics so that they know early in the process if we are running tight on cost or if we are trending later than we should be for our delivery date. If there’s a problem, it gets escalated to company directors.
The really neat thing about these metrics? Several of them are predictive, meaning that even though a User Story isn’t late yet, we can predict that it’s likely going to be late by how much work has been done on it so far. Sometimes a team can work late one evening and get back on track before they’re ever really late.
This level of attention to detail is extremely unusual in our field. In fact, we’ve never talked to another software company that uses something similar.
Paired with our Discovery Session, DLA metrics ensure that we actually get things finished when we say we will for the price our clients expect.
What You Can Do to Keep Your Software Project from Failing
Finding a software company that is set up to succeed is only half the battle. Here are a few things you can do to keep your software from failing:
- Budget some time. Your needs and processes are all inside your head, so no software company can create something to meet your needs without plenty of time and access from you. Plan to spend a day or more up front and a few hours each week to get software that will really meet your needs.
- Be patient. Just like when you’re having a house built, there are times when there will be much to see (framing! walls!) and times when it looks like absolutely nothing is being done (endless wiring). Feel free to voice concerns, but know that sometimes an especially tough problem will come up, and it may take a few days just to work through it.
- Ask questions. If it seems like something may be slightly wrong, ask the question. Software companies would always rather know early that they’re missing the mark than when they think they’re finished! Never feel bad asking if something seems different than you expected.
- Try to stay the course. Some pricing structures will let you change your mind or add functionality during development. But adding or changing features will add to your timeline and to your project costs. To keep to your intended budget, stay the course when possible, and make use of time up front to change colors or fonts, rather than development time.