I’ve been on a bit of an Argyris reading jag after putting together materials for an upcoming collaboration presentation. Last night, I was reading his book about how to assess the quality of management consulting advice, and a couple things clicked for me.
For those of you not familiar with Chris Argyris, he was a pioneer in the area of learning organizations. As such, a lot of his work was done on internal defensive mechanisms, or obstacles to learning. The basic premise is that when confronted, individuals tend to fall back on positional arguments, and ignore internal discrepancies in logic between espoused goals and demonstrable behavior.
What does that mean in my world? One of the classic reasons to implement Project Server is to address the IT resource issue, i.e. the business keeps asking IT to do more and more, IT keeps underperforming and raising costs, and everyone gets sucked into a downward value spiral.
The argument tends to retreat to positions (paraphrased from the book):
IT says “We don’t have the resources.”
The business says, “You’re not delivering fast enough.”
….and IT rejoins with “You guys don’t even know what you want.”
These become positions. They become divisions between “us” and “them.” We retreat into a shell that states “They just don’t get it.”
These positions are what Argyris describes as untested assertions, and therefore subject to review and analysis. This is when the EPM consultant comes into the picture. One of the IT managers calls up their local consultant and within 3-6 months, they have a tool in place that captures the resource capacity and demand – and rolls it all up in a bunch of shiny, sexy reports.
So far so good. We are moving from the world of positions and untested assertions to real data. The question is what we do with this data. Do we take the data into a confrontational meeting with the business and throw it on the table with an emphatic “See, I told you we don’t have the resources!” Do that, and the business will naturally fall into their own defensive mechanisms and question the data validity, ignore the data wholesale, or pull the old “Well, if I can’t get what I want from you, I’ll build my own IT department.”
Again, these are positions. The solution is to avoid positions and work to develop a common problem space. Each group has its own problems and there are any number of individual solutions to these problems. The trick is to identify a common set of these problems, and then to prioritize them as a group. The data should inform this discussion. The data creates this shared problem space by illuminating to all parties which statements are untested assertions and which statements are driven by actual data.
Does this change the data or the reports that get generated? Probably not. Really, this is an attitude adjustment. The question the manager should be asking is not “how do I walk into that meeting and establish our shared goals?” (hint: supporting the value chain), but how do we use the data to develop a consensus as to what problem we’re actually trying to solve? The shared goals discussion should have happened before the reports were even developed – as the reports illustrate the obstacles to achieving those goals.
Take that thought process a bit farther, and don’t wait till you have the shiny reports to show the business and frame that conversation. Get them involved as early as possible. Have them engage in the discussion as to what reports they would like to see to assess whether or not their behavior is driving the delivery issues. Do that, and you’ll be much farther along in defining the shared problem space than if you wait till the very end of an engagement. Do that, and the reports almost become superfluous as we’ve already developed consensus around what the problem actually is.
Once you’ve agreed on the problem, the solution is easy.