Comments on: Bridging the knowing doing gap

By: David Wood

David Wood — Thu, 29 Oct 2009 17:46:24 +0000

Excellent points Antony!

These definitely fit into the bigger picture of why companies fail to implement what they know they ought to be doing.

By: David Wood

David Wood — Thu, 29 Oct 2009 17:44:26 +0000

There can be good reasons for a manager to engage a consultant with the hope that the consultant will write a report that backs up what the manager already knows. The consultant can bring more gravitas (and additional evidence) to the conclusion, allowing the manager to persuade higher management of the need to act in such-and-such a way. I’ve seen this done successfully in the past.

However, the dysfunctional case is when a manager engages a consultant because that will take the heat away from a perceived issue. “We’ve got a problem here. But well done to Manager X for engaging consultants who will look into solutions”. Manager X gets the credit, and then the management team forgets about the issue, forgets about having engaged the consultants, and lets their report gather dust. There’s no follow through. The issue was important, but because the urgency level has dissipated, the management team stop caring about it. Oops.

By: Phil

Phil — Thu, 29 Oct 2009 15:59:01 +0000

‘The consultants eventually found that previous consultants had already been engaged and produced reports that matched what they themselves were going to recommend.’

This is an interesting point, which might imply that the act of commissioning consultants to produce a report might be seen as an end in itself?

By: Antony

Antony — Thu, 29 Oct 2009 12:14:33 +0000

I definitely agree with the five characteristics you list above; but would add one more. Most people (and companies) can identify problems/opportunities and create plans faster than they can execute plans. When I look at very productive companies they have an honest understanding of their execution capacity and strong prioritisation.

An interesting side-note is that both of these characteristics are built-in to scrum; you measure your velocity and are not allowed to say that you’ll magically improve output by 30% next sprint, and sprint planning is exactly prioritisation.