What is the most common mistake that I see when people try to implement management tools or frameworks?
By far the most common is mistaking using the tool for getting the outcome you are looking for.
I have been doing some consulting work recently where we are using the Business Model Canvas to develop a strategy for an engineering group inside a large organisation.
Read my previous post about this for a full description of the project. Today I want to focus on one particular part – the four ideal models that we built, and a tool that we used to conceptualise the models.
There are a couple of dimensions along which these models vary. In a couple of them, the team is responsible for identifying the problems to address, while in two others the they are working to specification as the problems are defined for them. The other source of variation is project management: how much of the solutions development process should the team be responsible for?
Manny and I took these two dimensions and mapped out the four possible roles for their Bespoke Solutions Team (BST). Here is the map:
In each quadrant, there is an indication of the project management responsibilities: I1 = problem identification, I2 = solution development, I3 = solution delivery to customers.
Last week, Manny made a revised version of that map. When he showed it to me, he said:
“I took out the I1, I2 and I3 indicators because they just seemed to confuse people.”
He was apologetic when he said because when we thought of that model, it gave us great insight into the project. But dumping it from the presentation that we give to people inside of the firm was exactly the right choice.
Here’s why.
This is a bed that my Dad made for me and Nancy as a wedding present:
He’s a very skilled woodworker, and the bed is gorgeous. But when he first finished the bed and brought it down to us, he didn’t set a saw on top of it to show us that he used that tool to build it. You can tell a fair bit about what he used just by looking at the final item. And in fact, the bed itself is what matters, not the process he used to put it together.
It’s the same with management tools. When you use tools, the important thing is the outcome, the conclusions that you reach and the actions that you take as a consequence. We don’t need to see the tools to understand that you’ve done good work.
Our I1,I2 & I3 construction was a very useful tool in developing the business models that their BST might adopt. It helped us identify the capabilities that they will need to have in each of the four scenarios we have sketched out.
But the important outcome will be the model that they decide to adopt, and the path they map out to build the skills that they need to execute this model. Even more important will be the business results that they obtain as they execute this model.
Don’t mistake the tool for the desired outcome. That’s mistaking the map for the territory.
Instead, figure out the outcome that you want first. Then think about what people and processes you need to achieve this, and identify the right tools to support your people last.
If you do this, your tools will be invisible. And that’s as it should be.
Sadly, an oft-overlooked proposition, Tim. It’s like selectively adopting Agile, with no two individuals developing a single project, yet lockstepping through the ceremonies. We have to remember WHY we’re doing this in the first place.
Put the tools in the box, tell me what you need, by when, under what constraints, and get out of the way.
Good points Brian. I just bought a copy of Start With Why myself, so I should get to it at some point.