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

Speed vs. bureaucracy: management issues confronted by companies in transition

I was at a relatively young company once where a senior executive suddenly sent out a message to the entire employee base, asking for general input on the cause and treatment of the following concerns:

  • “There is a feeling that the company is not able to move fast enough or nimbly enough — we’re not delivering products fast enough or turning projects around fast enough
  • “People feel that it’s very difficult to get things done
  • “There is a feeling that we’re getting too bureaucratic in everything
  • “People aren’t working collaboratively; there appears to be a ‘contract’ mentality in dealing with people”

Aside from the unfortunately vague, passive-voice constructions in this message (“there is a feeling”: meaning one person? everyone? just senior management?), this message didn’t surprise me much.  In fact, it wasn’t (at all) the first time I’d seen this kind of sentiment arise in a young company.

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

“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.

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

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.

[Read more…]

Hiring and firing: an example of a stellar employee

I plan to make a couple of posts surrounding the very thorny issue of hiring (and firing) IT staff. To start off, here’s a recommendation letter I wrote a couple of years ago, at the request of a former employee. It shows at least one executive’s (i.e., my own) view of what matters in a job candidate most of all, and how certain characteristics can (sometimes, not always) make up for lack of background or experience. I’ll call him Harry. What I sought (and found) in Harry doesn’t necessarily pertain equally to all IT positions, but I offer it for consideration:

I have known Harry for over four years, ever since I hired him into the role of Project Manager at XYZ, where I was the VP of Information Technology.

[Read more…]

Career tips for the CTO/CIO path

One of the most frequent questions I’ve gotten after starting this blog pertains to how one can work up to the CTO or CIO role in IT. This isn’t all that easy to answer, other than with some platitudes. Every career is different; every individual takes a separate path. I can’t exactly recommend to people that they take the path that I took, because there were certainly some odd stutter steps and digressions along my route. That said, I do indeed have some biases and thoughts about how a motivated, talented IT professional can position herself or himself for a top management role in IT.

  • Get broad. Strive to understand ALL of IT: development, quality assurance, operations, project management, architecture, user experience, PC help issues. And, of course, there’s no better way to understand those areas than to do some kind of rotation into each and every one of them, formally or informally. Diversify yourself. Doing so fully may require moving companies. One of my favorite Tom Peters’ quotes is “‘Repot’ yourself every ten years.” With respect to high tech, it needs to be more frequently than that.

[Read more…]

Mastodon