The number one reason people why companies don’t want to outsource their web development is that they prefer the developer to sit in the same office as them. This is a real, and valid, argument. It improves communication, obviously, and creates trust: you’re directly supervising and observing an employee. You’ve also recruited that person yourself, creating more trust.
Reason one: communication
If you can walk up to the developers desk, obviously that’s about as good as it gets in terms of communication! The reason this is important is because if the product design team (the ones with the whiteboard and the screen sketches) can talk directly to the developers, they can get early feedback on how much time it takes to develop a certain feature, and adjust their designs and priorities based on that. We call this the interactivity loop.
Reason two: trust
If you have recruited that developer yourself, or your CTO has, you know him. You have lunch with him. You see him sigh deeply when he stares at his screen. You see him pull up books, confer with the other developers, have techie meetings. You know he’s working hard. Even if the results are not always what was agreed to, you know that it wasn’t for a lack of trying. That, in short, is the trust between a manager and his employee.
Outsourced web development – a different set of rules?
When you outsource, you lose that direct connection: it’s someone you didn’t hire, who you don’t manage, and who doesn’t sit in your office. For that reason, fixed price is the model of choice when purchasing outsourced development.
Fixed price –a ‘transfer of risk’
Fixed price eliminates several risks. The first one is, what if the supplier’s developer is bad, slow, or not well managed? If you pay on a per-day basis, you’d pay the price for the bad decisions your supplier made. Second, you don’t have the interaction with the developer directly – there’s usually a management layer in between. Best to protect yourself and ask for a fixed price proposal.
The second risk you’re getting rid of is a very different one: your project is now on a garantueed budget! This is something an internal team can never deliver, no matter how much they promise. There’s always a risk that your project is not delivered in time, driving up the internal cost. With a fixed price outsourced project, you don’t have that risk anymore.
I call fixed price a ‘transfer of risk’. My client no longer has the project’s risk of being out-of-budget. I’ve now taken full responsibility for the budget of the project – I have to deliver at that price. If it was handled by my client’s internal team, he’d still take the risk – more than 50% of internal software development projects are delivered late, after all. When you do fixed price with a supplier, you just transferred that risk away! Yay!
Give me your spec
Suppliers respond to that by trying to reduce the risk. How? By insisting that every aspect of the project is documented in the fullest detail. I routinely insist on finalized screen designs, complete with the Photoshop originals, plus detailed written specs. Clients are exhausted by the amount of detail I insist on, and rightly so. I effectively try to reduce my risk by making you spell out everything beforehand. Didn’t write down one thing you needed in your spec? Too bad, not included in the price, won’t be included in the delivery! Since I am taking my client’s project, and make it my own internal project, I have to be confident that I can deliver on time and on budget. My core competence is beating that 50% risk. I do that by knowing in advance what I am building.
Friction between the interests of the supplier and the client
As you can see, the interests of my client and myself are misaligned: they want to start building asap while knowing the entire budget, while I want to know more details, before committing to a budget. This can (and has) lead to lots of frustration on both sides. What I often propose, is to just break up the project in multiple parts, and only spec, budget, and commit on a fixed price on that first part, start building, while then focusing on the rest of the project. I have several goals when I do that: one, of course, I want to start making money and start delivering NOW, and not in another four weeks. This, my clients will agree on – they are usually eager to start building. My second goal is to start creating trust: if they see me build and deliver on time, perhaps this will make them more confident that I will give them a fair deal on the rest of the project.
Comparison to internal development teams
How does this process work when you have internal developers, that are employees?
A bit different. Since there doesn’t have to a ‘hard’ fixed price in place, the insistence on a detailed spec is much lower from the developers. The developer will agree that any missing details from the spec can be detailed out during development (Not all developers will agree to this, by the way: some of the more rigid souls will resist this on puritanical arguments). Then, the team sets out to work. It may or may not end up being in time. As I said before, odds are about 50% that anything gets delivered on time. Which is usually OK. There can also be a give-and-take between the product team and the development team allowing them to drop some mini-feature to accommodate the deadline – those are very positive and healthy interactions between those two teams. It’s the interactivity loop.
What makes this possible, are the two points: communication, and trust.
I try to build those two with my clients as well. When that works, that same positive interactivity loop starts building up.
As I showed before, in the fixed price model, I take on the risk of my client. How do I protect myself? In two ways: I insist on all the details beforehand, and I add a margin of error to the budget.
By insisting on all the details beforehand, we destroy the interactivity loop between the product design and development teams. The product design team now has to do all their work in one go, hand it over, and then the development team will work on that fixed set of features for a period of time.
As a business manager, fixed price puts risk on my table. I reduce that by simply creating a buffer in the budget. In short, I add extra days for unforeseen work. The client pays for those regardless of whether they are used. When they are not, they are a welcome little bonus for us.
Are these things in the interest of my client? No, not at all! In effect, they would’ve been so much better off not asking for a fixed price. They do it for their own good reasons (communication, trust), but end up working against their own interests (too much spec needed, you pay the extra margin). If only they could trust their supplier like their own employees, then the virtuous circle of the interactivity loop could work the same way.
