Back in Advertising 101, I learned that leading with a negative is not a great way to open. Considering the success rate of projects in this industry, I feel it’s best to break the bad news first: custom software projects have a dismal success rate. According to the data detailed below, the success rate is as low as 35%. I say it’s even lower; closer to 0% by the metrics below. But read on – this story has a happy ending.
So, Why Does This Happen, Over and Over?
The success rate for custom software initiatives is depressingly low. Even for systems that are rolled out successfully, there is often a lack of acceptance once they’re online. Why is it so difficult to develop a custom software solution?
The Standish Group is a research company in Boston that studies the management and success of corporate software projects. Since 1994, Standish has released a new report every two years. According to the Standish Group, only 35% of custom software projects may be deemed a “Success.” (Chart at right.) Here are the three types of projects Standish identified:
- Project Successful. The project is completed on-time and on-budget, with all features and functions ?as initially specified.
- Project Challenged. The project is completed and operational but over-budget, over the time estimate, and offers fewer features and functions than originally specified.
- Project Failed. The project is canceled.
Wow. That’s grim.
Is “Success” really Successful?
Now, here’s the interesting part: at Streamline Studio, we would argue that the projects considered a “success” by Standish (on time, on budget and on spec) could quite possibly be failures as well. Why? Because if all you got was what you wrote in the original requirements specification – perhaps two years before your system rolled out – then your needs have almost certainly evolved during that time. Nothing stands still in this modern world.
This is not to say we don’t believe in requirements gathering and careful discovery of your needs. But we know that you can’t think of everything you need up-front. And beyond the things you just won’t think of until you’re pretty far along in development. If you have ever remodeled your home, you know what I’m talking about. No matter how good the plan, there are always things that change along the way. Should this be considered failure, or creative, on-the-fly adaptation and problem solving?
Back to our story. There are many factors that can shift the mission or derail the process:
- Management turnover. New executives bring in new initiatives, new priorities, new politics.
- Market Forces and technological advances. Technology evolves faster than we can react to it. There is no way to accurately predict the impact of things like Twitter, the iPad or the collapse of print journalism – not to mention the innovations still just over the horizon.
- Testers who don’t really test. Some of your users won’t even really think about your project until it’s rolled out, at which point you finally get their feedback… even if they claimed to have tested the prototype and signed off on it.
- Lack of IT Enthusiasm. While it’s not universal, we often encounter resistance from a client’s IT staff. This is a purely human reaction – who wants outsiders coming in and telling you what’s what?
- Divided attention. Everyone working on this project has other projects. No one can give this project their undivided attention. It’s true! Who has but one project to work on? The biggest impact this has on a project is time – this slows people down. Getting the team together for a meeting takes longer.
I could go on, but you get the idea. Anyway, I promised you a happy ending, so here it is….
Finding Success Where Others See Failure
At Streamline Studio, we develop web applications with three things in mind: design, development and testing are iterative. Instead of expecting a requirements document to stand the test of time, we embrace change. We build it in.
But that runs up the bill, right? Not really. Unexpected change is honestly not profitable. It disrupts your project – and usually the other projects we’re working on. We build in change. Develop, test, evaluate. Repeat until the project is done. Treat change as inevitable, and part of the success of your project… not as a failure.
Train wreck photo by born1945 
