Saturday, February 11, 2012

Status Reporting Is Not an Activity - It Is a Byproduct of Doing the Work

Whether CIO, VP or Director, the senior-most accountable manager in a mid-size to large organization presides over a large portfolio of activities - scores of projects and initiatives, hundreds of systems and people. Knowing what's really going inside the portfolio is a major responsibility that is hard to shirk as an IT leader.

The tendency in larger organizations is for each of the many distinct activities to locally optimize and run as they best see fit. Due to the shear scale of disparate activities and inability to roll it up consistently, the view from the top looks more like chaos than order. This state of "not knowing" puts the IT leader between a rock and a hard place and she must address it.

In IT, the time-honored prescriptions are to add extra reporting burden, force-fit heavy methodology,  add "pmo/oversight/governance" groups, or all of the above. An organization that has applied this salve (caustic) is easy to spot by the "data calls," Friday reporting scramble, scads of meetings, roaming hoards of people not actually accountable to deliver anything, burdensome process, nasty tools, and grand status meetings of the kind Tom Demarco calls "ceremonies."

This is a classic example of doing exactly the wrong thing if you really want visibility to salient facts. These actions make it harder not easier to know what's really going on, because teams are forced to develop a split-personality to deal with these added burdens and yet still attempt to meet their delivery obligations. Internally, they try to preserve their local habits - whether bad or good - because this is what will allow them to deliver (they believe). But then, they add an outer shell whose sole purpose is to tell the inquisitors what they want to hear in order to keep them out. These pesky project managers sound evil, but they rationalize this (correctly, I might add) as protecting the team from management stupidity.

As result, what's really going on in any given project or activity is encapsulated by a defense mechanism that didn't exist before and radiates a fiction. Over time, these defense mechanisms get really good at masquerading reality. Usually, this also has the consequence of increasing risk within the organization, because not all teams are really good at delivery. And this begets a death spiral -  a counter-productive positive feedback loop - excessive burden hides risk, which leads to  failures, which causes more burden, which causes yet more failures, ...

There is a better way. The real question to ask is:
How can I tweak existing practice, in a minimally disruptive way, and in a manner true to the craft of doing the real work work, such that the work naturally disgorges raw data, that when rolled up, gives the needed insight?
There are many analogs outside of IT - in fact, IT makes many of them possible! For example, when buying groceries at the supermarket, scanning a food item captures data to make the payment and accounting possible, but it also captures data useful to other parts of the business. The scan also records the time, the location, and data about the buyer by encouraging use of a loyalty card. Later, some background processing crunches up all this data into useful nuggets useful to purchasing, marketing, inventory, etc.

Notice what doesn't happen. The cashier doesn't fill out a form for every purchase; there isn't an army of trolls watching to make sure it's done correctly, and there isn't another army of data collectors mashing all these reports together. Isn't this easier on the team? No extra, error-prone data collection. Isn't this easier on the org as a whole? No parallel organization to stick probes into the half of the organizaiton doing real work, or worse, creating cockamamie processes in the name of gathering information to the detriment of delivery.

Of course such an approach doesn't come for free, it does require making tradeoffs, and it does require patience. The working teams have to change the way they work, ideally in a way that is as efficient as the way they were working. Moreover, all teams have to change in the same way. And, the proscription for how to do this work must be extremely bare - essence only - and allow for local variation and extension.

Why does this not happen more in IT? Probably because it requires deep knowledge of the activity being monitored, creativity in planning and implementing a solution, patience to see results (ironically, results actually come faster this way), and a desire by top management for real information not just plausible deniability.