Let’s talk about where we’ve been, historically, as an industry, when it comes to outsourced software development and offshore software development. In 1980’s and early 1990’s, in the US and in Europe, you had large consulting companies such as Andersen (remember them? I guess they were glad to have ditched the Andersen name in favor of Accenture) who would give you a multi-million dollar bid on your project. You would hand them an RFP that defined your system requirements as you best understood them (or they would help you define the requirements by letting you use their systems analysts) and based on these requirements, the consultants would estimate the work effort involved, price it, and develop your system for you. I don’t think people used the word “outsourcing” to describe this, but that’s what it was. Back in the 1980’s, and into the 1990’s, Andersen Consulting was famous for putting all of their young consultants—programmers–into “boot camp” and teaching them their methodology for doing software development (if you were around in the 1990’s you’ll get a smile from this article, talking about Andersen circa 1992). As I understand it, Andersen’s methodology (called Method-1) was essentially a waterfall-based process.
Andersen and their contemporaries weren’t doing the work overseas, though. They’d do it onshore with high-priced programmers, systems analysts, and project managers. Later on, in the mid and late-1990’s, we saw some offshore-based firms, largely based in India, who were able to start bidding on these kinds of projects. Maybe not the top-end projects, but some of the routine ones. This really took off prior to the year 2000, when there was a lot of routine work to be done to get systems ready for Y2K. These firms used a lot of offshore resources. The onshore consulting firms responded by getting their own offshore resources so they could compete better on cost. And the Indian firms got some consulting resources in the US so they could work with their clients, hands-on. In doing so, they were able to gradually move up the food chain and work on higher-value projects. These firms all grew, largely engaged in project-oriented software development and consulting work—bidding on client projects and executing them with waterfall-based development processes. But there were a number of nagging problems with this project-based approach.
For one thing, project-based outsourced offshore development tended to assume that all (or most) of the requirements could be determined up-front (i.e., a waterfall development process). This would allow the outsourced service provider to provide a reasonably accurate bid, allowing them to deliver the project and make a fair profit. Actually, that’s not entirely true. In fact, a dirty little secret that everyone knew about, was that nobody could entirely figure out all of the project requirements ahead of time, so the service providers would bid on the project, attempt to win it, and then as the system requirements changed, the service provider would issue all kinds of change orders defining how much extra they’d charge to meet the new requirements that arose during the course of the project, and the customer would need to agree to these extra costs before those new requirements could be added to the project. So the project cost and timeline would balloon, and everybody involved—the customer, the service provider—knew this was probably going to happen. Although that didn’t stop everyone from getting worked up and upset about things when it did happen! (Maybe someday I’ll do a whole blog post about famous software development project disasters. The common themes in each of these disasters is that nobody has a complete, common understanding of the projects’ requirements ahead of time, so the project spins out of control, costs balloon, people get pissed off, and in the worst cases, everyone lawyers up and sues each other. So, basically, the waterfall model fails, massively, and you actually read about it in the Wall Street Journal, and the reporter, who probably has little clue about software development, marvels about how anything could possibly get so royally screwed up. But we’ll leave that post for another day.)
The project-based approach to outsourced software development still exists, and it might be appropriate for some situations (e.g., a very focused project where you don’t have the specific skills needed for a project in house, so you hire a consulting firm that does), but for the most part it’s a bit of a dinosaur that doesn’t fit the times we live in. What approach does fit those times? I think it’s the Dedicated Offshore Development Team approach, using an Agile development process. Using this approach, everyone just admits that nobody completely understands the system requirements at the start of the project. But they decide that there’s a long-run need to have an offshore development team work on the requirements, bit-by-bit, release-by-release. And further, the Agile approach provides a framework for how the onshore and offshore teams can work together, in a way that encourages communication and quick issue resolution, which is exactly what we need to make sure the offshore team doesn’t get disconnected from the onshore team and develop the “wrong” thing due to miscommunication and an inability to nail all the requirements up-front (as in the waterfall model). We’ll talk about this in more detail in the blog post – Offshore Software Development – Pitfalls.
CEO, CayugaSoft Technologies LLC