how to sabotage innovative projects
the journal of Michael Werneburg
twenty-seven years and one million words
One of my favorite books on internal control; sorry, the only good book I've ever encountered on internal control is "Intelligent Internal Control and Risk Management" by Matthew Leitch. The author is someone who reliably - for reasons known only to him - continues to try to move the needle against overwhelming odds. He seems hell bent on bringing sanity to the field of risk management.
A big part - perhaps the largest part - of risk management is the cycle of understanding risks, identifying the poor habits or tools or structures that cause them, and changing those for something better. This requires innovation, and innovation is a bitch. Nothing humans do is more susceptible to various forms of accidental and willful sabotage, something Leitch highlights with scathingly wry British humor.
"In your ambition is to make sure an innovative project is a failure then here is what you should do. The following techniques are so easy that even people who want successful projects occasionally do them, not understanding the damage they do.
First, insist on consensus as to exactly what the project will deliver, when, and with what resources. Do not under any circumstances accept any uncertainty in this and do not allow any work to proceed until firm commitment and unanimous agreement have been achieved. If agreement is ever achieved then make it as hard as possible to change anything and frown on opportunism. In the unlikely event that this fails to kill the project develop a formal project plan with large phases of work that make sure nothing is actually delivered until the very end. Set out the project with logical sounding headings like 'analysis' and 'solutions development'. Anything will do as long as it doesn't involve trying something out in practice.
If, like a hard weed, the project struggles on then your problem might be that there are some strong innovators on the team. If so you must do everything you can to drive them away or prevent them from contributing. Now is the time to set up some brainstorming meetings. Flip charts, sticky notes, breaking the team into groups, feeding back 'conclusions' - you know the kind of thing. Make sure everyone is treated the same, no matter how obvious the differences in relevant design skill. Make sure nobody has time to thin knew ideas through properly and that anybody who does have well-thought-through proposals sees them put onto the flip chart along with others, misinterpreted, mixed, and mangled into useless oblivion.
If, despite all your precautions, someone actually does come up with a promising idea do not worry. They are playing into your hands. Simply welcome the idea, praise it, and focus all resources and thinking on it and it alone. Sooner or later the idea will hit problems and when it does that narrow focus will mean it is stuck. Tackling the problem from several directions at once, or searching for even easier ways in, would give a much better chance of success so make sure people don't get up to those tricks.
The key to effective sabotage is to present what you are doing as sensible, good management. Make it sound "logical". Stay calm, take notes, say supportive things, and you can be sure of getting away with it.
On the other hand, if you want success then make sure none of those sabotage tactics are used, even with good intentions."
The book is a treasure. The chapter this was taken from is a goldmine of recognizing and dealing with the problems common to implementing risk controls.