Free to think

The thing to remember when you're outsourcing product development is that you're hiring an extension to your team. If they're a good outfit, trust them to be creative and give them the rope to be. If they're not, don't hire them. Good product development outfits are good problem solvers, its a cultural thing (company culture, nothing ethnic). That said, its amazing how often business arrangements come in the way of a healthy relationship.

An Anecdote
I have to wind back a few years -- we were consulting for a large engineering company that built complex electronics, automating their product configuration processes. Each job was custom configured - and they had painstakingly documented all their business rules in a massive spreadsheet. Enter all relevant data about a job into the spreadsheet, and it would spit out the right set of parts and labor. The problem was, by the time we went in there, the spreadsheet had grown to 4 MB of data and formulas, and they were adding tons of new information by the day.

Now here's where we came in. They had approached the leading light in the configuration software space, and they had come back with (a) 6 months of 2 analysts to extract and document the rules (b) 6 months of a 4-person team to implement a rule editing program. These guys couldn't wait that long, and wanted to know if there was a better way. Well, here's what we did (we got the spreadsheet mid-week)..

1. One of our guys spent the first day writing a simple VBA program that spit out all the data and formulas into an XML structure. The folks at the engineering company had been meticulous -- nearly every formula had been named! We filled in the few remaining gaps.
2. We wanted to understand the "meaning" of each formula, so the next step was to write a parser and substitute the names in the formulas -- so I built a test harness that would validate my parser.  
3. The next step was to find a good parsing engine - we settled on ANTLR -- its a great tool, but we realized we needed more than a few days to really figure it out. I took a chance and emailed Terence Parr, the creator of ANTLR, explained the situation to him, and asked if he could recommend someone. He promptly wrote back "this sounds interesting, and I have a couple of hours this weekend, send it to me".

On Monday morning we had all rules extracted and documented.  From then on it took a 2-person team a couple of months to build an editing interface, and they had a working extensible application.

Lessons for outsourcing product development? 

1. A professional services company simply doesn't have the incentive to be good problem solvers. It cuts into their billing time.
2. The best business arrangement is an extended team structure - a pre-defined monthly consolidated payment for the team, tied to deliverables. Your only decision should be continue or not with the team. The models that don't work are
   • Fixed bids - during the bidding process, the better vendors are at a disadvantage. Their bids come out higher because of the need to be conservative, and the lower bids presuppose some degree of cutting corners. Its a lot better if you, the customer, choose if and where to cut corners rather than the vendor. After a bidder is selected, you, the customer are at a disadvantage - because none of the benefits of creative problem solving accrue to you.
   • $/hr based on years of experience - provides all the wrong incentives to stuff resumes rather than smart, capable engineers.
3. Be prepared to work closely with the team, rather than throw expectations over the wall.