A few days ago I wrote about how outsourcing goes wrong. Now I will explain more in detail a real case.
A couple of weeks ago I was in the US and visited a state government. They had outsourced the development of their new Enterprise Software to a US based international software house here called Smarty for the nice sum of several hundred million dollars.
- Smarty would develop the enterprise software in three years, then install it, and maintain it for 18 months. Smarty is responsible for process, architecture, language, tools, and whatever they do will be taken over by the State.
- Fixed price from the beginning, but changes after signed off specification would be extra.
- Smarty would deliver a specification during the project and agree with the State on this before moving on.
- Deliveries were phase based: requirement specification, higher level design, lower level design, code and unit test.
- All difficult tests (integration test, performance test, stress test, system test) would be done by the State.
This is a dream contract for Smarty. It just cannot go wrong. The State is locked in early to a fixed price.
The State has agreed to review and subsequently sign off the requirements once they are thrown over the wall from Smarty. This sounds OK, but it is horribly wrong. It is beyond human ability to sign off the requirements for a single product even, yet alone totally impossible for an enterprise system. No one knows the detailed requirements or can fully understand just papers. The business people, the users and all other stakeholders have some more or less clear ideas of what they want to get done, but we all know that their detailed requirements always change as soon as they get something to use. Moreover, one of the most important requirements for the client is to get a system that can be maintained and extended for as long as the business will stay…and that must be thought of as forever. However, Smarty is protected.
To deliver a specification to be signed off, to deliver drawings, and code is the simple part of the project, since you just deliver paper-ware. You really don’t need to be delayed in delivering paper-ware, you just write a little less <grin>. And, being a bit ironic, the good thing from Smarty’s point of view is that paper-ware cannot be validated or tested, so nothing can go wrong. Thus everything will go very well until integration test and acceptance test. However, in our case this was moved to the State. Here hell will break loose.
First, of course, it will be very hard to get the software to work as specified and this is where projects are delayed. However, most important, it will be extremely hard if not impossible to validate that the software does what the business and its users want it to do. With this approach, the State won’t know what s/he will get until after the whole huge project is at its expected end. However, Smarty is protected: “we did what we said we would do”. Moreover, the requirements on maintainability and extensibility will not be tested, because they can’t be tested. The State won’t know until the software is taken over and it needs to be improved, but then Smarty is long since gone.
The case I have just described is not unique. Many companies which have moved into outsourcing feel cheated. They have trusted that the vendor knows how to make its customers successful, and the vendor believes they can achieve that. Once the deal is underway, there is not much more to do. The client has restructured the company to have hundreds or more people working for her/him in the way the vendor has specified. The client has made a bad deal and doesn’t want to make this public. And, since everyone is doing the same thing, the client is in good company and can say: We just need to make it better next time.
However, this would never have had to happen if the deal had been structured smart.