Let's have another example:
- IT business says XML is great, and it is (at least when the circumstances are right)
- HTTP services are popping up everywhere and proves to be great
- Some introduce SOAP, which is a technology that combines XML and HTTP
- IBM markets SOAP and SOA as the solution for enterprises
- An organization gets convinced that SOAP and SOA is the solution to their planning of a new system. Based on logical analysis, it makes a lot of sense, numbers are right, and other organizations implemented it well.
- 20 people start working on it in the organization. A contract is written.
- Finally, implementation starts. This is still early in the project, not much money has been spent, yet. One implementation guy looks at it, and says: But this doesn't make sense. Our organization isn't like other organizations, and the SOA will make our life more complicated. He complains to his boss about what is going to happen. The boss doesn't really understand the problem fully, and definitely doesn't want to promote the complaints to a group of managers who already signed contracts, based on something that he doesn't understand.
- The implementation guy's manager tells the guy, that the implications of using SOAP has already been included in the calculations, and it's a good idea.
- The implementation guy accepts this explanation, knowing that he will probably get more colleagues in the future in order to cope with the increasing workload.
- The project grows big, more expensive than estimated, and the organization suddenly finds itself locked into mechanisms it didn't want to be locked into. The benefits weren't achieved, and the organization actually ended in an undesirable position.
- The managers are surprised by this development, and start to look for scapegoats, looking at contracts, designs etc.
- The implementation guy gets surprised when he learns that the managers are surprised.
Other information cascades include:
- Economic bubbles (My neighbor bought a house and made money, so this must be the right thing to do)
- USA's deficits (We need more growth, let us make consumers spend more money)
- We can save money on outsourcing, everybody else saves money (I once heard about a contract to outsource IT, which would have destroyed all IT in the R&D if it would be implemented as signed - the necessary modifications to the contract totally destroyed all benefits and made it a disaster, but it was implemented anyway in order to prevent firing of various managers)
- Let's make huge office rooms with many employees and desks. More people per square foot means more earnings. (an expensive office building near me for phone-calling journalists was built this way!)
- Let's replicate our success in our home market in our neigbor country (a small company with 30 employees, that I knew, spent enough money to go bankrupt on such an attempt, and didn't succeed to get ANY measurable turnover in that other country)
All these examples include people who advice against it, but fail to stop the cascade, because the people who lose by participating, do not realize that it is a cascade.
It's always difficult to argue, where is the "real technical expertise". The more complex it gets, the more you need to include the technician's points of view. One very simple trick to avoid making stupid decisions, is to be really sure that you understand the full impact of all the doubts, that the technicians have. The technicians are often good at spotting weak points, but bad at estimating their importance. Unfortunately, they're often also bad at explaining why they have doubts. I've seen several managers who think they understood the technician's doubts, dismissed it as a non-problem, and then had to deal with it later in the exact way that the technician had it visualized in his mind.
If you don't understand the doubts, and there's an cheap thing to do that removes the technicians doubts, seriously consider to do it.
Cascades are a bit like bubbles. They can be hard to detect, but there are measures to identify and fight them. |
