The Practical CIO: Difficulties in project prioritization & selection, part 1

How does your company pick which projects to undertake?  Demand outstrips available resources: nearly always, there are far more “good ideas” for things to do than can actually be done in a given time period.  So how do you decide which ones you take on?

If you research this general topic, you’ll find a lot of rather intricate, idealistic screeds that detail how to model an admixture of financials, market potential, risk factors, etc., and promise that this will get you “the” answer.  I don’t dismiss the importance and general validity of such approaches, but let me be frank: that’s actually not what usually happens at most companies. Not even close. Here are some real-life (albeit generally unsuccessful) approaches to project selection that I’ve seen in real companies. In no particular order:

1) Do ’em all: everything proposed by anyone goes on a list, and people just work like crazy and do the best they can to accomplish whatever;
2) Let a single executive (CEO, CIO, CTO, whoever) decide. That’s what executives are there for, right?
3) Insist that all proposed projects be evaluated for ROI, and do the ones that produce the biggest ROI number.
[Read more…]

A rational CapEx purchase and tracking process for IT

How often does someone in your company (often the CIO, or the CTO, or the head of infrastructure) end up running through the halls, waving a purchase order that “has” to be signed off that very day, or else key systems will allegedly go dark? Maybe you’re in the fortunate situation of being in a company where this frenzy doesn’t happen, but in my experience, that’s unusual.

I’ve written before on the importance of technology carefully shepherding its fiduciary responsibilities. Nothing contributes to the IT stereotype/stigma as much as a loud demand for a major purchase, at the last minute, justified solely by dire predictions of doom, and topped (often) with acronym-laden technobabble. Amazingly, it’s not that hard to avoid this situation, if you exercise a little forethought and planning.  The benefits of doing so are indirect as well as direct: you can change perceptions of IT into being viewed as a partner of business concerns, rather than as a troublesome, risk-fraught, and confusing cost center.

It all goes back to Management 101: plan the work, then work the plan. Surprises are a bad thing. Not only do you need a solid plan, but then you want to diligently track actuals against that plan. None of this is exactly a radical idea, yet I’ve served as an executive now in at least three different companies where none of it was happening before I arrived, with respect to capital expenditures.  To the extent there was a capital expenditure plan for the year at all (as opposed to just one big CapEx number!), it had been thrown out the window by February. Sure, this can and does happen in fast-paced Internet companies in particular, but the rankling thing was that no one really was tracking the changes against plan, or could envision how funds were shaping up for the year. Even if a plan has undergone radical changes, there still needs to be a current plan. Walking in, any executive (not to mention any auditor!) should be able to see one or two core documents that detail that current plan, as well as the progress against it.  If that’s not there, then the technology area (and by extension the whole company) is just operating by the seat of its collective pants, and that’s not acceptable.

Here are the minimum elements of responsible CapEx stewardship, in my view:
[Read more…]

Mantra for IT: “Participate in the process rather than confront results”

Let’s sail into a stretch of a metaphor this time. You probably know by now how much I embrace metaphors as a way to impart, often via a concrete example, ideas and concepts that are hard to grasp. So let’s go way back and talk about a metaphorical influence from long ago.

When I was in early high school, we would occasionally spend English class watching and then discussing a variety of short subject films, many of them from the fertile minds at the National Film Board of Canada.  Some of these films, described by the NFB as “socially engaged documentary”, bordered on (or transcended) the bizarre; they thus spurred all sorts of avid arguments among teenagers, easily as much as Ethan Frome or Wang Lung, the more literary staples of the curriculum that I can remember from that year.  There was one such film in particular, in fact, that has stuck with me for decades.  After some digging, I’ve finally been able to identify it by name and origin.  The researchers at the NFB have now kindly confirmed for me that the film is titled “I.B.M.”, and that it was directed by Jacques Languirand. When I reflect on it, the film’s staying power with me makes sense, since it not only features IT elements, but also serves admirably and in multiple ways as a metaphor for IT issues.

As I recall the five-minute film, it features an unchanging close-up view of an automated keypunch machine, punching out a series of IBM computer punchcards with a mysterious and incomplete common message. The film shows the cards sliding into place and getting punched, one at a time, then rolling off into the output hopper. Only parts of the full message can be read at first, since some of the letters of each word are omitted or obscured. Little by little, though, over the course of the film’s duration, each successive card that is punched contains more and more of the message, until it becomes clear at the end of the film that the text reads, “Participate in the process rather than confront results.”

Think about the wisdom and depth of that line: “Participate in the process rather than confront results.” Three ways come to mind of relating this metaphor to IT, to its role across the enterprise, and even to effective IT management of staff. They share a common aspect: the duty (and the reward) of emphasizing participation over passive observation.
[Read more…]

Getting an IT assessment: pitfalls to watch for

One key ongoing goal of mine is that I constantly strive to pay attention. In this case, specifically, through web logging reports, I can see the Google searches that drive people to this blog every day.  One of the most common of these, it turns out, is people searching on the phrase “how to improve IT department”. Another is “IT assessment”.  I somehow picture bleary-eyed CEOs and COOs, late at night, pondering how they can get more throughput or better results from IT, and turning to Google in their frustration.

Since it’s in essence a frequently requested topic, let’s talk about it.  I’ve been on both ends of such assessments, multiple times.  I’ve done them, and I’ve had them done for me.  Before entering into such an assessment, it’s worth considering some of the surrounding issues and common pitfalls.

[Read more…]

Start simple: a corporate desktop/laptop refresh model

Here’s a topic that frankly shouldn’t even merit a post — it’s that much of a no-brainer if you think about it.

Yet, in the real world, I’ve found that it’s anything but a no-brainer, at both small and large companies.  What I’m referring to is the need for organizations to track their laptops and desktops.

Shockingly, many/most organizations don’t do even close to a satisfactory job at this.  The U.S. State Department recently made the news for losing track of as many as 10,000 laptops.

OK, chalk that up to government, perhaps.  But admittedly, in any bustling, active enterprise, keeping tabs on machines, and who’s using what, isn’t a cakewalk. Even Microsoft has its issues in this arena, and turns to “rolling its own” applications as a stopgap.

Astonishingly, most organizations I’ve observed:

  • Don’t know how many machines they actually have
  • Don’t know their current penetration of laptops vs. desktops
  • Tend to budget by the seat of their pants for replacements for the coming year
  • Can’t tell you precisely where a specific purchased asset has been deployed
  • Don’t know the “aging profile” of their population of desktops and laptops (e.g., how many are more than a year old)
  • Don’t relate the actual handling of the asset (e.g., replacement after three years) to the financial handling (e.g., spreading the capital expense over three years from an accounting perspective). Replacement tends to be demand-driven, meaning (usually) crisis-driven.
  • Don’t have a solid process, or any process, for decommissioning a machine that is past its useful life.
  • Don’t have the ability to tell a given employee when his or her machine will be replaced.

[Read more…]

Executive questions, IT answers, pizza parlors, and speed chess

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.

[Read more…]

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…]

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.

[Read more…]

Mastodon