Sometimes you have to step outside application development to gain insights into how best to manage your projects.
A recent article in the New Yorker provided a spark for me on the subject of outsourcing.
The article, "Water Music" by John Seabrook, was about the new Revson Fountain at Lincoln Center. In it, Seabrook talks to Mark Fuller, co-founder of Wet Design, the fountain designers. (Wet also created the fountains at the Bellagio in Las Vegas.)
The new Revson Fountain was constructed entirely on site at Wet, as are all the company’s fountains, with precision German steel-cutting tools operated by Wet employees. "Outsourcing wouldn’t make sense for us," Fuller said, "because with this kind of work there are so many small changes to make along the way."
Wow -- "Outsourcing wouldn’t make sense for us because with this kind of work there are so many small changes to make along the way."
That seems totally obvious now that I've seen it written down, but it's just the rule of thumb I've been seeking. I already have another rule down pat from my own experience: If the fastest way to specify a project is to build it, then outsourcing doesn't make sense.
So how should we rephrase Fuller's offhand comment for software development? My current best formulation: If a project needs to evolve significantly over time, then outsourcing doesn't make sense.
I've also tried to phrase this in terms of waterfall and spiral models, but I think leaving those out makes the rule more useful.
What do you think? Do you have a better formulation? Do you have your own rules of thumb about when you should and should not outsource?