This morning, I caught myself looking back at the last week of meetings, e-mails, and conference calls, and I experienced a minor epiphany. If I published a detailed diary of the ebb & flow of proposals, debates, and commitments from the past few days, I could successfully deflate the management aspirations of 80-90% of the technical folks I know. Contrary to what many might think, there’s not much IT in IT Management.
Ok, that’s a bit of an overstatement; I couldn’t do this job effectively without a solid grounding in the technology under discussion. However, I expect anyone with a similar role (intermediary / facilitator between business and IT) would agree that it goes well beyond compilers, load balancers, and user interfaces. We talk about fundamental business process, not just specific IT projects. When presented with new ideas/approaches, we question some previous decisions while reaffirming others. We use the simple calculus of cost-benefit to make the call between multiple options; the magic is in defining the problem clearly, identifying the costs accurately, and enumerating the benefits fairly & impassionately. (Revenues will increase or costs will decrease, and you’ll see it on the bottom line by the end of Month X).
For every organization I’ve worked with, those conversations are never black-and-white, always shades of gray. Here’s a scattered sampling from the week …
- Where are the resource constraints?: For Project Stepstone, we used to think IT was the constraining factor, but now that we have a reasonably detailed plan, it’s clear that (operations / finance / sales [pick one]) is overcommitted. How can we line up the top five projects and force rank them? Alternatively – do you have similar Level of Effort (LOE) estimates for these other projects and functional areas? Or are you estimating conservatively / being too pessimistic?
- What’s this really worth?: Are you going to justify Project Bedlam on hard benefits or soft benefits? And when I say hard benefits I mean you will see a material impact to your bottom line, in the current fiscal year. Can’t think of any? Let’s work through some examples …
- Agile vs. Waterfall: You want to talk about the “home run” Project Aaron, but I think your best bet is a flurry of singles and doubles. Let’s be practical – we need to deliver Project Carew, Project Ripken, and Project Gwynn just to manufacture some time in your day, so you can effectively work on The Big Bam.
- How will we know when we’re done? What does success look like?: Sometimes it’s a struggle to drill past the one-liner, “worthy goal” statements and get to specifics. Integrating our processes is like motherhood and apple pie, but give me a target like increase revenue with key customers by 5%, slash time-to-market for new products by 30%, or drive down inventories with increased forecast accuracy: these are concrete deliverables we can use to drive a tactical plan.
- When can we start?: Project Criswell has a detailed plan with tasks, resource assignments, & effort estimates. We have a full cost picture, including capital and expense. We have walked through the change management issues (ie. who specifically will be impacted by this project). We’ve dotted the I’s and crossed the T’s – what will it take to get a “go”?
There has been little or no “classic IT” in any of these conversations. No mention of program requirements, data flows, system throughput, database tuning, etc. There is strong business focus, but just as much effort is expended simply in making sure estamos en la misma jugada – we’re all on the same page.
This is a consistent modus operandi in all of the companies I’ve worked with; I don’t think it’s unique to any company in the more traditional industries, although I would assume high-tech or consulting firms might approach things differently. And, I’m fairly confident that this is why many died-in-the-wool technical folks have little interest in upper management. It’s all about semantics, gray areas, and wading through varying levels of understanding to find those nuggets of truth that everyone can line up behind. Its not about winning arguments – it’s all about bringing groups of people to the same place as quickly as possible, but doing it without forced acquiescence. Compromise and collaboration will do wonders for commitment when the project hits a rough patch.
This process drives most people in IT nuts – and its not just those with aspirations to upper management. There are plenty of IT groups in corporate America, just chomping at the bit to get something accomplished, to get under way and start delivering real benefits. All of this debating and restating and reformatting appears as an overdeveloped sense of conservatism and an unwillingness to make change. Just make the decision and get out of my way – I’d be done already if you’d just pull the trigger …
As far as I’m concerned, however, this is where the real fun of IT is. Understanding – really understanding – the problem and the path to the solution is great; helping other people come to that same understanding is really a kick. Catching that glint in their eye when they’ve taken ownership – they know they’re driving a project that delivers big-time benefits – I dig it. It’s like the toughest programming problems – the brilliant architecture hinges on one critical hack, and I’m the one who discovers the solution.
It beats working for a living!