The decision to keep your software development project in-house often comes with a sense of greater control, and hence less anxiety about the prospect of runaway costs. Relying on your own IT people means you don’t have to let big projects fall into the black box of an outside company’s development process. Agile methodologies like Scrum, which emphasize iterative product delivery and evaluation, were created in part to mitigate the fear of handing over the reins of your project. But does Scrum really address the concerns businesses have about hiring outside software firms?
Ballooning costs can result from any number of mishaps, or they can result from shenanigans on the part of the outside company. An article in CIO about the most important questions to ask when you’re evaluating software vendors, for instance, quotes Jon Lincoln, a developer at the document imaging company etfile, on the topic of what happens to your data in the event of project failure: “Some vendors try shady tactics by holding your data hostage (as if they own it!) or charge an exorbitant amount to sway you from leaving.” Lincoln recommends asking the vendor beforehand what becomes of the data if you call off the project. But taking data hostage is just one example of how developers can take you for a ride, whether it’s intentional or not.
Cost and Value
It’s been a few years now since the Aberdeen Group reported that 76% of companies say vendor management efforts and costs for outsourced projects ended up greatly exceeding their expectations. Of course, that number would need to be placed alongside the one for in-house projects to be meaningful. But many commenters nonetheless take it as evidence against the advisability of hiring third-party developers. In a widely discussed article for ZDNet, Peter Vaihansky, an executive from First Line Software, cites the 76% figure in support of the idea that in most cases outsourcing is a bad idea—even when you’re getting much better hourly rates from overseas developers. Rate arbitrage, he insists, is completely overrated.
Vaihansky writes: “Yes, that overseas firm only charges you $20/hr for a developer. But how much value are you getting in that hour? How competent is that developer? Are you getting strong people on your team, or mostly recent grads with questionable skill levels? What experience do they have? One experienced $100/hr in-house developer may well produce more value for you than five or even more junior $20/hr people overseas.”
But K. Piskorski of PGS Software has an interesting rebuttal to Vaihansky’s point: “I’ve seen this argument used against outsourcing time and time again. But in reality, this works in favor of outsourcing! After all, it actually increases your chance to find the key productive talent, as you’re not limited to your location or even your country. And if you’re dissatisfied, it’s usually much easier to hop on to a completely new team.”
In other words, keeping the project in-house merely shifts the task from one of finding a quality development firm to one of recruiting quality developers. But why do so many projects end up costing more than expected? Piskorski cites poor communication, hidden charges, and “intangible” savings as key factors behind cost overruns. Those difficult-to-measure savings are another instance of overlooking the need to compare the outcomes of in-house projects to outsourced ones instead of favoring the internal ones as the default response to every failing of software vendors. Poor communication between IT staff and business users, for instance, is a huge problem for in-house development projects too.
How is Scrum supposed to help?
The traditional waterfall methodology relies on extensive requirements-gathering and then has the team moving through subsequent stages in a single direction. Basically, you spend a lot of time upfront figuring out what the application will need to do so the developers can create an exhaustive requirements document, and then they go off for a long time to complete the work. At the end of the process, they show up with the completed software and maybe help with some training. This approach tends to work just fine when the application is really simple. Failure rates for large and complex projects, on the other hand, are worryingly high.
The trouble larger waterfall projects run into is similar to what you run into with any large project, whether it’s building a house or writing a book. No matter how thoroughly you try to plan, you’re going to face unforeseen decisions at multiple points along the way. Each one of those decisions adds to the potential that you’ll be moving far afield of your original vision. Plus, it’s simply an inescapable reality that it’s nearly impossible to envision big projects all the way down to the nitty-gritty details beforehand—you seldom know precisely what you’re building until you’re well on your way actually building it.
The Scrum methodology breaks down large projects into smaller, more workable subprojects called sprints. The overall application is divided into its functional components, and each one is tackled in order of highest priority. The delivery timeline is also broken down, so that (ideally) at the end of every sprint the developers hand over a component for hands-on testing and evaluation. If the software isn’t what the client wants, the plan gets adjusted. Over multiple iterations, the project is completed a piece at a time. One of the biggest benefits of this approach is that problematic components don’t get baked into the software, making it necessary to go back and redo significant portions of the project to make the necessary changes after it’s completed.
In other words, small adjustments are made along the way to avoid the need for huge changes at the end. And that’s one of the main ways runaway costs are avoided. Instead of developers gathering copious requirements and running off to their coding lair, you have a system that’s much more collaborative, that doesn’t waste resources on components that won’t work, and that lets you keep up with the project as it progresses. In exchange for more engagement on your end, you get to maintain a little bit more control, even when you’re working with another company.
Is that how it actually works though?
The truth is that Scrum will not necessarily increase the likelihood of your project costing close to what you were expecting. That’s because it was designed rather to increase the likelihood that what you end up with at the project’s completion is working software that has real business value. But it’s also true that keeping the project in-house won’t necessarily increase your chances of avoiding runaway costs or project failures either. Does Scrum at least work to address some of the issues associated with hiring an outside IT company?
Vaihansky insists that the only time you should consider outsourcing your development is when the company uses Scrum. But Piskorski is slightly less sanguine: “Of course, Scrum helps a lot in many ways, and it usually helps with communication—to a point. You’re going to get a workable prototype much faster, and you will get one on every major step of the way. Still, if the developer is poor, it’s a bit like a difference between getting a bad sandwich at your local deli, or an inedible meal after waiting an hour in an expensive restaurant.”
This brings us right back to the questions of trust and value we began with—though it’s still better to leave hungry after only paying for a sandwich as opposed to a whole meal. What Piskorkski recommends amounts to the same type of due diligence in researching development firms as the article in CIO lays out.
We don’t need to go into the importance of referring to past clients and looking at past work here. But there is one more thing to take into consideration when choosing a software company. Sure, just because they claim to use the Scrum methodology that doesn’t mean the project won’t go off the rails. But what will your options be if that happens? What can you do if the deliverable at the end of a sprint is a bad sandwich? Some companies will make you sign a contract that extends to the completion of the overall application. Some have you sign on again for each subsequent sprint, which means if the work is terrible or the costs are running away you can call the project to a halt while you look for another partner.
It’s probably a good idea to ask what type of contract each candidate vendor uses.
Some other popular posts like this: