A statistic that’s been floating around for the past 5 years or so suggests that 75% of IT projects result in failure. A Standish Group survey from 2010 breaks this figure down to show what it actually means: 24% of projects were never even completed because they’d gone so far off track, while 44% went over budget, past deadline, or failed to deliver some of the required features. These are sobering figures. When the Gartner Research Institute looked into the causes of project failure for a 2012 report, they determined that larger and more complex projects had much poorer chances of success.
These findings really raise the stakes for any company embarking on a custom software development project. And they highlight just how much pressure anyone looking for help from a development firm is under. So how do you choose the best partner, especially in the situations where you end up with a range of cost estimates wide enough to drive a truck through? (Hint: the two guys who gave you the lowest quote work out of their mom’s basement.)
Enter the RFP
Obviously, the end-goal is to get working software that meets all your business challenges, but at the lowest price possible. Toward this end, the conventional practice is to write up an RFP and broadcast it to multiple firms. An RFP is basically a list of the requirements the software will need to meet. Based on this list, development companies figure out what building the application will entail, create an estimate of what it’ll cost, and bid on the project. Since the companies that respond are all working from the same list of requirements, the reasoning goes, the one that offers the lowest bid promises to deliver the best value.
“That’s a recipe for a million change orders,” Aptera’s Software Development Practice Leader Matt Noggle says. “I don’t think anybody actually makes a decision that simply. Most people know you have to look at other things besides the price. But not many people appreciate how little estimates based on RFPs actually mean. Upfront cost estimates are reflections of how well the company understands the problem they’re being called in to solve. A higher estimate could be because one company has a higher markup than the others. But it could also be that the company with the higher estimate understands what the project will involve a lot better than the others.”
The problem with the process surrounding RFPs is highlighted by the Gartner survey’s finding that larger, more complex projects are more likely to go over budget, past deadline, or never be completed. It can be difficult to generate a truly comprehensive list of requirements before beginning even relatively simple projects. What happens more often than not is that once the project is underway, several factors you failed to consider present themselves. What this means is that at least some of the higher bids your company receives are likely based on the developers accounting for more of the factors that go unforeseen by the others.
Scrum and the Death of RFPs
Developers have an answer for the problem of evolving project requirements. It’s sometimes called the agile methodology, but more often it’s referred to as Scrum (there are other agile methodologies besides Scrum, but for our purposes here they’re basically synonymous). In brief, Scrum works by breaking large, complex projects down into smaller, more manageable units. Instead of trying to create an all-encompassing list of requirements before beginning, the developers get together with people from your business to create use cases or user stories. They then go on to build the functional components of the application incrementally, starting with the most important.
When they’re finished with these smaller subprojects, they deliver what is hopefully a working piece of software for you to evaluate. Based on your feedback, they either revise the user stories or they proceed to working on the next component. The process—plan, build, evaluate—repeats over multiple iterations until the overall application with all its features and functionality are complete.
What makes Scrum effective is that it accounts for the near impossibility of envisioning down to the last detail what a complex development project will consist of. Most of the time, you don’t know exactly what you need until you have something that’s almost, but not quite, what you need right in front of you. But Scrum demands quite a bit of time and attention on the user side. You and the developers end up essentially collaborating on the project—though of course they still do most of the heavy lifting.
With Scrum, you also don’t have a solid list of requirements, which means you can’t send out an RFP, which means the traditional method for choosing a development company is obsolete (though a disconcertingly large number of businesses still don’t seem to realize this).
So how do you decide who to hire for the project?
The New Process for Choosing a Software Partner
Many businesses are starting to look at choosing a software company less like holding a bidding war and more like hiring a new employee. A successful project is less about getting all of the initially imagined requirements met in the short term and more about getting the most return on your investment in the long run. When you’re looking to hire an employee, you bring in several candidates to discuss the role you see them occupying in the company. You ask them questions about their qualifications and experience, and you try to get a sense of whether they’d be a good cultural fit with the rest of your workers.
“One thing I would ask them to do,” Noggle says, “is tell me about a time when one of their projects failed. It’s just like asking someone in a job interview to tell you about a big mistake they made in one of their earlier jobs. If they blame it on the client, like by saying the requirements kept changing, that’s a bad sign. Because the problem wasn’t with the requirements—it was with your discovery process. Or it was because your approach wasn’t agile. You want a company that’s going to take responsibility and learn from mistakes.”
Choosing a job candidate entails negotiating wages and benefits, which for you boils down to the question of whether he or she brings enough value to the company to warrant the investment. Likewise, in choosing a software partner, you have to cover all the issues with how each candidate company determines final costs, and you’ll want to get information about their discovery process, partner resources, approach to project management, quality assurance, and product delivery process (click on the link below for an in-depth look at the questions you should ask in your interviews with prospective partners). But by treating the process of choosing a partner like a recruitment initiative, and by trying to get the most return on your investment in this new “employee,” you’ll be avoiding a lot of the most common pitfalls underlying those scary statistics about how few IT projects succeed.
Other popular posts like this: