Let’s mix some metaphors today, and attempt to relate them all to the world of information technology and project management.
I have a good friend and colleague, one of the top IT consultants I know. He’s able to execute crisply at the detail level while keeping the big picture in mind; he’s especially good at balancing on the fine line separating necessary diplomacy and straight-shooting directness.
For reasons I find simultaneously admirable and unfathomable, this indefatigable person, whom I’ll call Gunner here, is planning on opening a pizza parlor as a sidelight, and is currently embroiled in the process of threading the various bureaucracies and logistics to make his vision happen. We talk about this regularly, since I am a great pizza fan. In a recent conversation, he reported that he had just gotten city approval to use a specific lower-cost piece of equipment, news that greatly increases the chances of the pizza parlor actually becoming a reality. So I, of course, immediately asked when opening day would be.
Executive questions, IT answers, pizza parlors, and speed chess
Why status reports really do matter
Do a poll: many IT folks regard doing status reports as their least favorite task. My point here, though, will be that a lot of people, management and workers alike, don’t fully understand the real purpose of status reports, and that status reports should actually be a “must-have” arrow in your management quiver.
How a person regards status reports is, in my view, a litmus test that tends to reveal one’s basic approach and attitude towards management in general. Let me sketch the two diverging philosophies.
I’m a strong proponent of the first philosophy: the idea that managers and workers collaborate towards achieving common goals, just playing different “positions” in the game plan of how to get there. The opposite view, one that is held by more people than I’d like, is that the manager assigns work, sits back, and judges how well it was done. If you look at the status report through eyes colored by that second view, you might tend to approach doing a status report as drudgery, a checklist chore with little real utility, and with lots of potential downsides when your boss reads it and determines what you haven’t done well. That approach can result in status reports omitting or obscuring any bad news, providing all sorts of detail meant to show that everything is going swimmingly, and in essence attempting to prove that the author is a shining star and a veritable dervish of activity.
[Read more…]
“Astounding IT sayings”: the inaugural post
I haven’t given myself the luxury of telling an IT anecdote or two here recently, so it’s about time: here are two, with moral-of-the-story observations for each. Note: these are true stories. I may have changed some of the facts, lightly, to make them less identifiable. They’re also always at least several years in the past, to provide a healthy amount of distance for everyone.
I’d actually like to make this post the first in a recurring motif, a series that I’ll call “Astounding IT Sayings,” for what I hope are obvious reasons. The saying that I consider to be astounding, in its context, will be highlighted for you below in bold.
Climbing the ladder to CIO/CTO: a biographical sketch from eWeek
Another heads-up to readers: I was recently interviewed by eWeek for my thoughts on the difference between mid-market CIOs and enterprise CIOs. As these things sometimes go, the interview turned into more of a discussion of career path and how you climb to executive ranks in IT. I’ve written about this topic before, but if you want to read some more on this, with a little more detail about my own path, do check out the article here; it appeared this week. The interview also gave me yet another opportunity to make my now-familiar points about some pet subjects, such as IT needing to be a service organization, the importance of being a partner to the business, and so on.
Nuts: the biggest trap of all for IT stakeholders
As I promised last time, there’s one more key way, the biggest way of all, not to get what you want from your IT organization. This is, in fact, the trap I have seen virtually every entity I’ve ever worked for fall into to some degree, some to the point of actually destroying the company.
The trap is perhaps best communicated first via parable (no religious implications here, mind you!), and then I’ll give some concrete examples and some brief advice on how to avoid (or at least mitigate) it.
Few people realize how well many of Aesop’s Fables apply to IT situations: after all, as Apollonius of Tyana noted, Aesop “made use of humble incidents to teach great truths.” One of my favorites along these lines is Aesop’s fable about the boy and the nuts in the jar.
How not to get what you want from IT
As much as any part of your company that supports the key prongs of the corporate mission (deliver product, sell the product, support the product), IT is constantly on the hook to deliver more and more. As I’ve written before, expectations are deservedly high, and getting higher all the time. And when expectations are so high, and the stakes for success equally so, the possibilities for disappointment are numerous.
No one wants to be disappointed, and no one wants to disappoint. Here’s how you, the business stakeholder, can help yourself and the company: don’t fall into the common traps with IT that will likely lead to you not getting what you really want.
Here comes a David Letterman list of these traps, consisting of only three items. There are, of course, a lot more traps than just three, but in my experience, these are the main ones.
3. Push hard on your IT organization to deliver on “trick plays”. Sorry for the sports metaphor, but it’s applicable. With respect to IT, “trick plays” mean mission-critical, high-profile projects like constructing new web sites or instituting major new back office systems such as a data warehouse or a new CRM system.
[Read more…]
Using feedback loops to improve IT department service
As I’ve written here before, I strongly advocate thinking of IT in general as a service organization to the rest of the business.
Any service organization needs one or more forms of “feedback loop” to be able to gauge whether it is successfully accomplishing its mission. However, I’ve observed relatively few IT organizations that actively seek to implement such feedback loops on a regular basis. At best, the IT executive does it informally by consulting with his peers at the executive table. But with any such anecdotal feedback, the information gathered that way tends to be fleeting and unreliable, and it is especially influenced by strong personalities and emotions during crisis situations.
Here’s a better, and simple, suggestion, one that I’ve implemented to varying degrees at several firms with a good amount of success: Survey your constituents regularly and then publish the results.
Sounds daunting? I promise it really isn’t, not in this day and age of easy-to-use web-based surveys. With less than an hour of work, you can design and initiate a survey using a free service like Zoomerang or SurveyMonkey, and easily gather high-quality results (reports and statistics) in just a few days that can help you gauge (and present) how you’re doing. Here’s how.
Financial metrics for IT: the holy grail of ROI and how it misses the point: Part 2
As I promised in my previous post on this, and along the lines of the “intensely practical” goal of this blog, we’ll now take a look at the financial cost analysis for a specific project. This is only an example, with details changed or obscured, but it is based on a real proposal from a few years back, analyzing whether to swap out an existing infrastructure element (a storage array) for a newer and more capable unit.
As I’ve argued before, any proposal like this should really analyze and present several alternatives – e.g., sticking with the status quo, changing to vendor X, or changing to vendor Y. This example covers only one of those analyses, but I think you’ll get the point. Here’s what I see a lot of IT people forget: your goal here is to analyze and communicate and recommend the best choice for the organization, not just to justify what you already want to do in your gut. You need to be your own devil’s advocate in this process. If you can’t clearly understand all the benefits and outline all the costs, you’ll make poorer decisions, no matter what your gut tells you.
So let’s dive into the practical. Here’s the process: if you’ll recall, we want to look at hard benefits and hard costs of the proposal, and look at these over a five-year time horizon to get the big picture. On the benefits side, we talked about how benefits break down into increased revenue and decreased costs. Of course, the notion of actually increasing the company’s revenue based on an infrastructure change is unlikely, so we’ll leave that aside in this case. The whole purpose of this particular example proposal is to decrease costs, both in real terms and in terms of making personnel more productive. So let’s look primarily there for the benefits that will result from the proposal.
