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…]
Why status reports really do matter
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.
Financial metrics for IT: the holy grail of ROI, and how it misses the point: Part 1
Let’s talk some more about one of my favorite topics, project portfolio management (PPM). A lot of literature on PPM tends to focus on evaluating risks and returns. An excellent article on IT governance last week in The Wall Street Journal had the following sage advice:
“Create an IT portfolio by evaluating risks and returns. Just as an investor balances risk and returns in constructing a portfolio of investments, management should analyze the costs, benefits and risks of all IT projects to determine how to get the most benefit from the dollars invested in technology.”
I can’t argue with that. But I also like to talk about another major part of IT portfolio management, which focuses on juggling which projects can actually be resourced. It’s unfortunately easy to come up with ten distinct projects with positive return on investment (ROI), for example, in a situation where it’s really only feasible to do one or two of these a year. In some companies, the pressure to do any positive-ROI project becomes enormous, even if it means the company is biting off too much at once. So what to do?
The flip side of common myths: how some are perpetuated by IT
As promised, I’m going to follow up on my last post (“Optimism, resilience, stamina: the make-up of the CTO/CIO“), covering the myths IT deals with on a regular basis, by talking about its flip side: the ways that IT itself can unfortunately perpetuate or contribute to some of the myths I’ve been discussing.
Here’s a point-by-point discussion of some of the things I talked about last time, the discouraging statements you frequently hear from stakeholders.
Optimism, resilience, stamina: the make-up of the CTO/CIO
Here’s a disquieting little secret that few of us ever really acknowledge, maybe because it’s rather painful and also an unavoidable part of the fabric of our existence in IT. I don’t know how to say it more eloquently (or less bluntly), so here goes: being in information technology is hard. In our day-to-day dealings with stakeholders, with end users, with management, even within our own ranks, it’s common to hear some pretty discouraging and recurring things, voiced either explicitly or implicitly. For example,
- “what have you (IT) done for us lately?”;
- “what do you (IT as a whole) do all day?”;
- “we’ve been asking for that system for years now and not gotten it”;
- “how can that be so hard? Why can’t you just …”;
- “at my last company we did that in just [names an absurdly short amount of time] and it worked really well.”
