“Don’t write about that,” I’ve been told by several colleagues, when I’ve mentioned that I was working on a post about how best, as the senior technology executive, to negotiate with vendors.  “You’ll give away all your tricks!” they’ve said.

Well, actually, no.  Here’s the main trick: this particular CIO doesn’t have any “tricks”, if by tricks you mean ways to outfox the opposition, or anything else that is best kept secret.  In fact, I’m not a natural avid negotiator. I’m not one of those people who looks forward to buying a new car because of the thrill of haggling with the salesperson.  But I’ve learned over the years how negotiations can best be structured for the optimal outcome.  Like cryptography, where greater obscurity isn’t equivalent to greater security, successful negotiation isn’t dependent on tricks or subterfuge.

I’m quite content to tell any vendor or salesman how I go about negotiating, because doing so doesn’t provide them any kind of advantage.  If anything, it’s beneficial to me and my company that all parties in the negotiation understand clearly the basic principles and approach that I’m using; it cuts a lot of the normal gamesmanship out of the equation.

What I’m about to tell you about negotiating actually strikes me as incredibly obvious. Yet, time and again, I’ve come into a new CTO/CIO role and been astounded at the poor technology deals that were cut by the previous executive: inadequate terms, failure to protect both parties instead of just the vendor, unnecessary and undesirable contractual lock-in.  What happened in most of these cases, as far as I can usually determine, is that the executive in charge got swept away by emotional attachment to a specific solution, and tipped his or her hand. Game over: at that point they were putty in the vendor’s hands. I’ve even seen cases where contracts have completely put the vendor in the driver’s seat of actual implementation, including spending authority, to an unconscionable degree.

Make no mistake: vendors are typically much more experienced and skilled in negotiations than most of the technology executives they deal with.  Achieving excellence in negotiation should therefore be seen as a critical part of the technology executive’s skill portfolio.  But, like finance skills, it’s a skill more honored in the breach than the observance.  Your ability to negotiate well can not only protect your company’s long-term interests, but can actually recoup far more than the equivalent of your annual salary to the bottom line. It’s not uncommon for technology executives at even relatively small companies to negotiate deals worth hundreds of thousands or even millions of dollars of capital and operating expense.

So let’s cut to the “secret”. It boils down to this simple principle: give yourself choices. Identify two, preferably three, viable, affordable, achieveable ways to solve your problem or need.  Once you’ve successfully established that viable short list, the power is all in your hands.  If you haven’t fully done that, you’re not really ready to negotiate, so you shouldn’t even start. Power in negotiation comes from not being wedded to a particular solution. Another way of expressing this idea is “always be truly ready and willing to walk away.”

Pay attention here: I’m about to say two apparently contradictory things, both of which are true and key:

1. You need to regard all of the choices on your short list as fundamentally on equal footing, each with its own advantages and disadvantages, but on balance having roughly the same merit as a solution.  Don’t ever go in having already decided which one you really want!
2. Yet, you need to remember that all of the choices are also fundamentally different in their details. For example, one might have 30% greater functionality or come from a more established and stable company than the others, but recognize that this advantage probably comes with a cost premium. The market is generally pretty efficient that way.

Your goal in the negotiation process is to see where you can find “wiggle room” on each alternative’s components (price, terms, features) that will ultimately make one of those choices outshine the other, on balance.  In other words, you are looking to unsettle the equilibrium you’ve achieved in #1, so that one choice comes out on top. And here’s another key: let each vendor know, and remind them frequently, that this is what you’re doing. Usually, there’s no need (or benefit) in letting the participating vendors know exactly what your list of alternatives consists of, but it will suffice that they know that you know that you have choices.

Miscellaneous tips and observations:

• Negotiation, in general, is not simply about money, although that’s certainly a key dimension that can make one of your viable alternatives rise above the others.  Any facet of the deal should be open to scrutiny and discussion: cost, terms, rights to upgrade, SLAs, warranty, etc. You don’t always automatically choose the least expensive option, nor do you always choose the most featureful.

• Don’t ever tell vendors (and believe me, they’ll ask again and again) what your budget is for this project. They don’t tell you what deals they’ve cut when they’ve sold their product to other customers, do they?  Again, the fact that you are actively pursuing other alternatives needs to speak the loudest.

• Remember, though, that your goal is not to hammer down the price so far that the vendor won’t make any money on the deal. You can do that, at times, but it ultimately means that you’ll get poorer service and less attention when you need it.

• Where possible, involve your legal counsel in the negotiations; don’t just bring them in at the end. The best negotiations for me, in terms of viable outcome, were where I had a tight bond and common approach with my legal counsel.

In the end, it’s all about getting a viable solution for your need, at a reasonable price and beneficial terms for all. It’s not really about “winning”; it’s about choosing. Give yourself choices, and in the end, you (and your organization) do win.

Lagniappe:

• Ward Keever, “Ten Keys to Successful Negotiations”
• Martin Ewing, “5 Can’t-Miss Vendor Negotiation Tips”
• Michael Krigsman, “Negotiation Tips for CIOs”
• Peter Kretzman, “More tips for dealing with IT vendors“

A few years back, I had an extremely surprising and unpleasant experience as CTO. The director of my Program Management Office ran a weekly status meeting for project stakeholders, where we’d all methodically go through the current project portfolio, in order to communicate on issues, gather necessary feedback, and align everyone’s expectations. I typically attended in order to provide input and executive-level decision participation, but left it to the director to actually run the meeting and present the topics.

Unfortunately, immediately before one of these weekly meetings, that director was given bad news (in a brief hallway conversation, no less) about a major bug that had just been discovered in the software for our highest profile project, which was currently in testing and due to launch in just a couple of weeks.  This project, with its strategic and revenue-enhancing potential, was foremost in the minds of everyone in the company.  Stakes were high, in other words.

Without conferring with me or anyone else, the director announced to the entire group of assembled stakeholders that the project had hit an insurmountable snag in terms of our target launch date, and that it would be delayed potentially by weeks. No further information was available on specifics, and people’s concerned questions went unanswered. You could feel the anxiety spread through the room. I actually had to truncate the meeting abruptly and promise to reassemble the group when we knew more.

My director was quite upset with me. Rather than having my action be understood as a necessary attempt to prevent panic until we could get some real facts, I suddenly realized that I was being accused of wanting to “hide information” from the stakeholders. The director even told me, “Well, I like to be honest and tell it like it is, but that obviously just isn’t what is wanted here.” I was stunned. Here was a person who had the wrong idea of transparency, and astonishingly for their position, a warped idea of what project management is all about.

As most experienced project managers know, it makes utterly no sense to drag stakeholders through the entrails of every back-and-forth readjustment that is discussed and worked through in the course of a project’s lifetime.  To do so lowers stakeholder confidence, unnecessarily in many instances.  In this case, the director somehow wanted to be a kind of Paul Revere, forewarning the stakeholders, but instead came off as Chicken Little. Transparency can’t be an act of individual heroism; it needs to be a concerted, institutionalized, collaborative philosophy and approach.

Moreover, good project management isn’t about making everything go smoothly. There’s probably no project plan in the history of the world that has gone completely smoothly from beginning to end.  Instead, project management is about responding appropriately when it doesn’t, and recalibrating to keep everything still on track. In fact, it should be expected that not everything will go as planned, and your whole team should be prepared to take some bumps and glitches in stride without panicking.

It’s not hiding anything to hold back on discussing, in a public forum, a problem that has just been discovered, the ripple effects of which initially can only be guessed at.  When you promulgate potential bad news prematurely, it puts you into the position of trotting out the absolute worst case, before you really have any idea whether that worst case is likely or even plausible. In fact, it’s a fundamentally selfish act: it takes your own personal panic and extends it to as many people as possible.  And if there’s one thing we know about panic, it’s that it’s contagious.

You need to shoot for judicious and organized transparency. That’s where you plan on regular status communications, and you methodically, soberly assemble the facts in a structured manner before you make those announcements. Most of all, you collaborate internally: before you bleat about a potential crisis to the stakeholders, you bring in the rest of your team to talk through the possibilities and “degrees of freedom” in how you’ll act with respect to that crisis. Otherwise, you may think you’re nobly playing Paul Revere, but instead of imparting critical facts, you’re shouting “The British might be coming!”  And that’s not transparency, that’s mere alarmism.  Remember that especially during the dog days of a stressful IT system development effort, what often seems like a dire setback, upon careful and collaborative examination in the light of day, turns out to be merely a minor speed bump that is easily overcome.

Is it “controlling the message” to be cautious about spreading the alarm? You bet it is. And doing that is in everyone’s interest. Remember my adage: show that you’re in control. Your job as project manager (and, by extension, the job of the Director of the PMO, and the CIO) is to be in control and to demonstrate to the users that you’re in control.  That doesn’t mean that you “hide” anything; it does mean that you deliver bad news broadly only when you’re sure of your ground, have weighed the options for how to cope with that bad news, and are ready to present those options soberly instead of in a flailing manner.

Adhering to a philosophy of transparency is a far cry from shouting every blip or misgiving about the project from the rafters. This is particularly so if you’re in a leadership position. You want your communication to be transparent, yes. But without appropriate structure and caution, transparency can be the height of irresponsibility. In those cases, in fact, you’re just building a slightly more institutionalized rumor mill.

Lagniappe:

• Karen Guglielmo, “What is transparency, and how is it relevant to IT?“
• Phil Windley,  “Tools for IT Transparency“
• Peter Kretzman, “Why the CIO should air the dirty laundry“

OK, let’s assume you’ve gotten great at picking the right projects to do to benefit the company. How do you know you can actually accomplish the ones you’ve picked with the resources you have? If you’re like most companies I’ve seen, it’s done on a wing and a prayer. But there’s a better way.

Last time, I wrote about ways to pick projects that satisfy the company’s “SHOULD do” dimension: ones that are strategic, financially beneficial, risk mitigating, or legally mandated, for example. I set out practical guidelines for the process of selection in that dimension, to ensure as level a playing field as is possible.  And I left it for this follow-on post to discuss the other dimension, the “CAN do” dimension, which needs to calibrate the list of chosen projects to what can actually be accomplished by the available resources.

Both dimensions inform each other, of course; they’re not independent or sequential. In other words, the company might be able to tackle five smaller projects rather than one huge project, and figuring out if it’s a good idea to actually make that trade-off will be based on executive judgment of the benefits in both scenarios.

In “practical CIO” terms, though, the SHOULD do dimension has the rather unfortunate trait of being a challenge to automate or model, especially fuzzier aspects of proposed projects such as risk or strategy or market positioning. In fact, I’ll go out on a limb and say that overemphasizing this dimension may even be ultimately pointless in terms of the eventual project selection. Bear with me here; I’m certainly not dismissing the value of ROI estimates etc.  Project managers of one persuasion will claim that a deterministic modeling for all such factors is possible — one recent blog informs us that “One can use either Benefit Measurement Methods (Comparative approach) or Constrained Optimization Methods (Mathematical approach) or both to arrive [at a] conclusion on project selection.”

I agree it is both possible and even desirable in the selection process to have a full and quantified assessment of factors affecting the “SHOULD do” dimension.  But here’s my practical experience, again: in the end, the findings of such a model are often ignored, almost arbitrarily.  In other words, in many companies of all sizes, the fact of the matter is that politics (and gut) trump spreadsheets: project selection often strays away from sheer issues of ROI or weighted risk calculations and into the realm of a CEO (or other senior executive) simply determining a strategic mandate.

Hence, I recommend not obsessing on honing a deterministic model with intricate weighting and scoring schemes, etc.  Instead, as I wrote last time, recognize that there will still be a judgment-based component to project selection, and focus on standardizing the input information to the “SHOULD do” phase to ensure that judgment is maximally informed.  Recognize that biases and politics will play some role in project selection, and seek actively at all times to mitigate the effects of such bias. A CEO who really wants to initiate a given project will often do so no matter what the model says; nonetheless, the inputs are still vital.

On the other hand, the “CAN do” dimension aligns the list of projects with what can be accomplished by available resources (I call this “factory capacity“). In essence, it’s meant to provide a way to overcome the natural corporate tendency to take on too much, to “stuff eight pounds of manure into the five-pound bag.“  This is one case where you can’t afford to have politics trump spreadsheets. Having determined, through whatever arduous and (no doubt) contentious process, the “vital few” projects of the “SHOULD do” dimension, it is absolutely critical that you achieve success with them. A key way to fail is to take on more than you have resources to do; doing so casts into doubt the success of all projects in the portfolio.

So here’s one relatively quantitative way to proceed.  In a nutshell, evaluate whether you’ve “right-sized” your selected project portfolio to your factory capacity by making some over-the-thumb squinting-style estimates for each project, simply classifying each into “T-shirt” size categories.  You then link these with general assumptions about the number of hours required for work on a given project in each category. Linked in the Lagniappe section is a sample template spreadsheet, containing three potential templates of varying complexity that you can adopt for such estimating. The goal? To make sure that the projects you’ve picked will be achievable by the resources you’ve got available, based on the assumptions you’ve made about how big projects tend to be.  Later, actual analysis and scoping will allow a more precise resource commitment.

Again, you can make this process very simple or very complex, depending on your needs, inclinations, and patience. Let’s start with a very simple model: three categories of project (small, medium, large). You and your staff should know best, from past experience, how many categories make sense to have, and you should be able to gauge, overall, roughly how many total hours of work are required on average for each size.  Include in your scope of consideration all core work of the through-launch development lifecycle: analysis, requirements, design, development, QA, and implementation.  These hours will be different for each organization, needless to say.

Also up front, you’ll need to enter your total headcount available for the given period (in my experience, a calendar quarter works well for this planning exercise), in the same work areas.  Don’t make the typical error of assuming that each person will be available for forty hours a week (or more): the model includes a productivity factor, currently set at 80%, to account for meetings, sick days, administrative duties, and the like. Remember, this exercise entails rough estimates, and they won’t give you a precise answer or actually do resource allocation.

Then, do a “speed chess” exercise where you estimate, project by project, whether it’s a S, M, or L.  This tends to go pretty quickly. Then the fun begins: along with senior stakeholders, you can play “what if” games: a spreadsheet is a great way to include or exclude projects (usually based on your “SHOULD do” evaluated criteria), trying to make as much as possible fit into the bag.  In this model, placing an “X” in the “Include in Final Total” column for a given project uses the estimate of hours for that project in calculating the total commitment (with all included projects), and judging whether or not you’re over capacity.

Here’s a look at an example of the most simple model:

As you can see, the included projects create a total of estimated hours (based on the T-shirt sizing), which is compared to the total hours available from the current headcount.  In the above example, the total hours is slightly over what will be available from the current headcount, meaning that you should look for a different mix of projects that will be achievable.

Additional sample templates are included for greater complexity: e.g., more categories (1-5 in the most complex template), or providing for component T-shirt sizing, recognizing that some projects involve little development but intense QA, for example.  Picking any of these is vastly better than just shrugging and thinking you can do it by instinct.  And it helps all participants understand the undeniable (but often-ignored tenet) that projects really do need to be narrowed to the “vital few.”

Lagniappe:

• Project Estimation sample templates (Excel spreadsheet)

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.

Any of these approaches, in my experience, produces a great deal of thrashing, and causes eventual frustration that, yes, things aren’t working well. Various elements of the business feel disenfranchised or just inadequately served; or, people realize that ROI may not be the universal answer (or worse, they start to “game” their ROI estimates even more than before); or, there’s an outspoken disgruntlement that the right projects still aren’t getting done. People start to feel that the model of project selection that you’ve been using (if you’ve been using one at all) doesn’t let those projects float to the top that they know “in their gut” are the most important.

So let’s turn to a practical, doable approach that I’ve seen help considerably.  First, you have to establish ground rules about the process of project selection, and they have to be, collectively, wiser than the ineffective approaches that are outlined above. Most importantly, those ground rules have to cover both of the main dimensions of a disciplined project selection, as I’ve discussed in detail before:

• projects that we SHOULD do (based on determinations that use benefit measures primarily, such as likelihood of financial ROI for the company);
• projects that we CAN do (based on the “factory capacity” of the resources on hand and on the magnitude of the projects being attempted)

Note that, again, organizations tend to struggle with evaluating both of these dimensions, and decisions on both are often made very much by the seat of the pants (i.e., chutzpah, wishful thinking, blind determination).

I’ll use this post to discuss ways to pick projects that satisfy the “SHOULD do” dimension, and in my next post turn to ways to ensure that those projects will meet the “CAN do” dimension.  Both dimensions inform each other, of course; they’re not independent or sequential. In other words, the company might be able to tackle five smaller projects rather than one huge project, and figuring out if it’s a good idea to actually make that trade-off will be based on executive judgment of the benefits in both scenarios. By the time the chosen projects begin, though, both dimensions must be analyzed and baked into a concrete plan: you need to be confident that a) the selected projects will all benefit the company; and b) you have the resources necessary to complete all of them with high quality in the allotted time.  In other words, and I perhaps belabor the obvious here: don’t plan for things you can’t do!

In my experience, a practical process for choosing which projects the organization SHOULD do needs to incorporate the following guidelines:

• The process must be a repeatable one, with standard input artifacts (not mere table thumping by determined champions). Artifacts typically include:
  • a project proposal, with a clear but high-level statement of the objective, scope, ownership, anticipated benefits/ROI, and expected measures of success;
  • high-level estimates of the magnitude (level of effort) required to implement the project
  • discussion of alternative approaches and risks of each approach, including possibly retaining the status quo
• The process must be cross-functional: it needs to have senior representatives of the business’s main constituents at the table. Include the usual suspects:
  • Finance
  • Sales
  • Marketing
  • Customer service
  • IT / Engineering
• The process must be multidimensional: it needs to recognize that the set of chosen, viable projects will (over time) cover at least these aspects:
  • expense reduction;
  • revenue increase;
  • strategic (market positioning);
  • legal/regulatory/security exigencies;
  • risk mitigation
• The process must recognize that there’s no single, obvious, automatic, metrics-based “silver bullet” for picking which projects to do. That said, it’s also true that metrics can and should be part of the discussion: especially, metrics on appropriate resourcing can help prevent the standard optimistic approach of “overstuffing the bag” with more to do than the factory has capacity for.  I’ve already discussed some of the pitfalls of relying solely on ROI, where it’s not unusual to see wildly optimistic assumptions by zealous stakeholders baked into the resulting number.
• The process must incorporate fitting the chosen set of projects to “factory capacity”. See Part 2 for more details on this.
• The process must recognize that there will still be a judgment-based component to project selection, and focus on standardizing the input information to ensure that judgment is maximally informed.  Recognize that biases and politics will play some role in project selection, and seek actively at all times to mitigate the effects of such bias.  Again, the most important check and balance? Not to take on too much, despite whatever urgency, politics, or potential ROI may exist: that would be nuts.
• The process must be balanced in outcome across time, rather than tending to favor one type of project to the exclusion of others. If “roof projects” are never approved, for example, that indicates a lack of balance and a probable bias towards short-term revenue projects.
• The process must not be overly complex (for practicality, and again, in recognition that it’s going to be largely a judgment call in the end)
• The outcome of the process must be clear and unequivocal: a set of approved, sanctioned projects for the given time frame, with all other projects considered as NOT approved at this time. Ambiguity here can render the whole effort moot.

Clearly, such a process requires an able, active, and respected facilitator.  There’s no one answer for who that should be, since it depends on the personalities and the culture. I’ve seen it work with the head of the PMO as facilitator, or the CIO, or the COO. I do recommend that it be a fairly senior individual with the ability and cajones to tell people when they’ve stepped out of line with the above guidelines.

More coming next time on specific ways to “right-size” the project portfolio to what can actually be accomplished.

Lagniappe:

1) Frank Hayes, “Time to PONI Up”, http://www.computerworld.com/s/article/print/76504/Time_to_PONI_Up?taxonomyName=ROI&taxonomyId=74, December 9, 2002

2) Joshua Greenbaum, “The Paradox of ROI: Do ROI studies really help organizations make better buying decisions?”,  http://www.intelligententerprise.com/021115/518enterprise1_1.jhtml, November 15, 2002

3) Sai Machavarapum, “Prioritizing IT Projects Based on Business Strategy”, http://www.cio.com/article/22976/Prioritizing_IT_Projects_Based_on_Business_Strategy, July 15, 2006

4) “Are you ready to analyze the demand for your 2010 portfolio? (Part II)”, http://www.chiefportfolioofficer.com/?utm_source=Twitter&utm_medium=twit&utm_campaign=Twit

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:

• Construct, as part of the annual budgeting process, the CapEx plan for the year, project by project, with anticipated months for each expenditure.  When the budget is finally approved, this CapEx plan becomes the Plan of Record.
• In addition to the expense grid, compose an initial outlined description/justification (at least a paragraph, definitely not just a vague phrase) for each project, assigning that project some kind of arbitrary ID for tracking.  This description needs to be signed off by the finance department for Sarbanes/Oxley purposes, and to ensure that the appropriate corporate guidelines for capitalization are being adhered to.  Note that often, a given project will end up having its cost split over several expenditures (e.g., multiple hardware purchases made in different months, so assigning each project an arbitrary but immutable ID is useful to help track back to the original plan.
• As a project gets actually kicked off during the year, there needs to be a deeper analysis and planning phase, during which the expected costs and timing get solidified and, of course, written down.  Here, it’s critical to document the alternatives to the proposed CapEx expenditure, including the risks and cost of staying with the status quo rather than going with the proposed approach.
• A regular process needs to be instituted and expected by all: a monthly formal review with the CFO, using the following tracking document: an itemized list of expenditures planned for last month, expenditures actually incurred,expenditures deferred, expenditures cancelled, expenditures upcoming for this month.
• The purchase order mentioned at the beginning of this post? That PO should come to the signing executive with predictable standard attachments: the analysis document for the project, the CapEx plan of record, and the current monthly CFO review showing the expected expense. What, this is an emergency and we don’t have those? OK, but emergencies had better be rare and explainable as exceptions.  In any case, the PO should appear at least a week before it “has” to be signed. No surprises.

Side notes:

• The analysis document for each project? That’s an excellent place to make sure that all the costs are taken into account, including non-capitalizable elements such as maintenance.  Again, “no surprises.”
• Any CFO or CEO who is being presented the justification for a technology project that lists and analyzes only one proposed solution has a right to be intensely skeptical: astoundingly, that single-minded approach seems to be typical at many companies.
• Here’s a key and often misunderstood basic tenet: just because a given expense is “in the budget” doesn’t mean that the amount is right or that the purchase should be made at all.  A budget is simply the bare bones of a plan, made with limited information at the time; for nearly all projects, a detailed investigation with multiple vendors is necessary to get true pricing and timing. The annual budget, your initial “plan of record”, should be regarded as a mere best-faith estimate.

If I were walking into a company, as a new CIO, CTO, or CFO, I’d immediately want to see the current CapEx plan, and the solid record of monthly reviews occurring as plans gel and change.  What, that isn’t all there? That tells me a lot.

And if you’re feeling that doing all this is a lot of work?  Well, if you want to be able to spend the money, you should be more than willing to put up with a certain amount of due process in order to get it.

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

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.

• The duty of stakeholders. Stakeholders need to be involved in any project, not look in from outside.  Note the recent and encouraging ascent in the industry of certain Agile practices that emphasize the ongoing and deep participation in a software project by its stakeholders, who provide constant input and feedback on micro as well as macro levels.  Contrast that approach with the more traditional, “over the transom”-style, one-time hand-off of supposed user requirements.  Stakeholders, take this to heart: jump in and insist on ongoing involvement in the projects you care about, otherwise the results that you eventually confront may not be entirely to your liking.
• The duty of IT. Equally, IT needs to work on an ongoing basis as part of the business, an equal partner at the table, and not just as IT in a vacuum, reacting to what it’s given.  At its worst, I’ve seen IT become little more than “order takers” for the enterprise — relegated to asking questions that are essentially equivalent to, “oh, do you want fries with that?” and obediently scribbling down the answers.  That approach of course seems cooperative and agreeable, but in truth, treating requirements gathering that way is actually a form of neglect of one’s responsibilities to the greater good of the enterprise.  Ironically, it often leads to long-term failure rather than success.  Don’t let this happen.  Instead, IT people need to be there at every juncture, going full throttle, to challenge and to help mold requirements towards greater viability and cost-effectiveness.  Few people in the enterprise are in as good a position as IT staffers to drive out the appropriate balance between long-term and short-term considerations.  User requirements often come in without context, or without practical weighing of consequences and ripple effects, or with a failure to consider plausible alternative approaches.  Molding and fleshing out those key requirements is a long arduous process; commit yourself to participate in it.
• The duty of leadership. Think about how you behave as an IT leader towards your employees.  Here too, do you participate in the process, or do you tend to just confront the results?  As an IT leader, it’s my obligation to resist falling into the rut of sitting back and mainly evaluating my staff on how well they’re executing.  Instead, I have to make sure that I stay actively and regularly involved in coaching, trend-setting, and occasional course correction, all (of course) without drifting into micromanagement either.  In other words, I need to focus on being a collaborator more than a critic, helping to further our collective agenda.  If I see something that isn’t working, for example, I can’t just ding my employee for the gap; instead, I need to work together with him or her to figure out the best way to regroup and move ahead.  We’re in this together, after all.  Not fully understanding or following through on this key duty, collaboration over critique, is in fact a frequent way that I’ve seen IT leaders fail.
  

But back to the film.  Of course, its main “gimmick” is that the message that it’s communicating isn’t clear at the beginning; it emerges into full clarity only upon successive efforts at articulating and perfecting it.  Who in IT can’t relate to that?  Think about how user requirements constantly evolve, for example, or management expectations, or even industry standards of success.  The message also reminds us of the benefits of “continuous improvement”.  Incremental and tiny improvements end up creating whole-scale shifts over time, and drive everyone to new levels of clarity and achievement.

Finally, thinking about this film helps me realize anew how far we’ve come with all those incremental technological improvements over the years.  After all, I don’t know anyone who works with punchcards anymore.

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.

I should first note that there are basically two kinds of assessment along these lines: tune-ups (which tend to be granular, tactical, and more specifically technical) and the “what’s fundamentally wrong with IT” kinds of assessments that are initiated when there’s long-standing dissatisfaction with the IT Department.  Most of my remarks concern the latter, which pops up distressingly often, usually at the behest of upper management.  The former, tune-ups, are what you, the CIO/CTO, should be initiating yourself at regular intervals, say every couple of years.  It’s a massive benefit to get some outside help (assuming it’s impartial) in looking carefully at your departments tools, practices, and staffing and seeing where the opportunities lie that might have otherwise gone unseen or unprioritized.

The other kind, addressing the question of what’s fundamentally wrong with the IT department, usually comes after business/technology alignment issues have persisted with upper management, whether that be your CEO, your board, or other senior executives in the company.  Such assessments are a little harder to swallow, but should equally be welcomed; if those perceptions exist, they need to be addressed, and outside help may aid you greatly by actually bolstering some of the same approaches that you’ve been trying to push within the company.  Sadly, outsiders sometimes are more readily believed than the people doing the work.

Let’s look at some of the issues and pitfalls more specifically.

1. Your staff, almost certainly, isn’t going to like the fact that the department is being “poked and prodded.” Make sure you lead by example in actively championing the benefits of getting this assessment.
2. It’s absolutely best to get an experienced, senior outsider to conduct this assessment.  For one thing, as I once heard Ted Nelson point out, “the fish cannot see the water”.  Even if you have the skills, experience, and tenure to conduct your own assessment, the weight carried by an outsider’s opinion, ironically, will be stronger than yours.
3. Be careful of hiring someone with an axe to grind (specifically, with services to sell).  For this reason, I recommend steering away from engaging the big consulting companies for such an assessment, or even smaller consulting companies, and suggest going with an independent.  Often, a larger firm will regard an IT assessment as simply a foot in the door, on the road to longer and more lucrative engagements.
4. Steer the effort, from its inception, in the direction of looking at IT/business interaction as a holistic issue. I’ve often seen such assessments unearth fundamental flaws in non-IT areas, most commonly in how the business played their role (or didn’t play a role) in project prioritization. Stakeholders across the business need to be prepared for such a finding.
   
5. No matter what level of involvement you have during the assessment, you need to realistically expect that more negatives will come out of the study than you think are accurate or justified.  After all, the company is not paying the assessor to discover that everything is fine, and most will tend to err on the side of exposing every possible blemish they perceive.  My advice, once again, is to cultivate a thick skin in yourself and your staff.
6. Equally, the findings of the assessment will often serve to confirm the points that you and your internal staff may have already been making to others at the company, but which were not being received well by stakeholders. It’s easy to have your staff, if not you yourself, feel some disgruntlement about that. To repeat: have a thick skin, and lead by example.
7. Insist that the assessment be useful, not simply voluminous and abstract.  It should sketch out some concrete plans of action, with possible timelines and a careful discussion of tradeoffs.  What’s not effective is for you or the company to simply put the resulting document into a drawer and do nothing about its findings.  I’ve actually seen this happen fairly frequently.
8. By the same token, don’t just merrily add the findings (as new initiatives) to the already teeming pile of things you have to get done.  As with all efforts, you need to weigh the tradeoffs, see how the internal pressures (from above) may have changed, and proceed accordingly.

Expanding on that last point: no assessment will substitute for what you need to do every day, as part of the basics of running an IT department. So, returning to those basics, as the CIO, how can you improve your IT department?  The major elements of your answer shouldn’t be much different from what any external assessment will tend to cover:

• measure the various areas (development, operations, QA, project management, etc.) over a reasonable period of time so that you’re dealing with actual data;
• prioritize the issues that are most injurious to the company and to the department’s perceived effectiveness; and
• plan specific measures for remediation;
• get buy-in to the plan
  

So the most important takeaway is that whether it’s internally or externally generated and pushed, prioritization is always king. You need to keep in mind what should be obvious: You can’t take a department from “zero to sixty” overnight.  Equally, you can’t solve all the deficiencies or problem spots at the same time.  Trying to do it all together, and all at the same time, is just plain nuts. Any assessment of quality will agree on that point.

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.

The impacts of all of these aspects of neglecting this key area?  Chiefly, the impacts are financial (loss through “leakage”, potential overbuying, lack of optimization, increase in service costs, inability to plan and budget accurately), but also security plays a part.  When you don’t know what you have or where it has gone, your company is exposed in many ways.  So most of all, it’s key to recognize that basic tracking like this is a key fiduciary responsibility for the whole company, and it’s in your house.  Moreover, it shouldn’t be something you have to spend a lot of time thinking about — it needs to be baked into what you do as a department.

The obvious key solution here is IT asset management (ITAM), which is a much broader topic than I’ll be delving into right now.  In fact, that breadth is part of the problem: if you’re proceeding on this from a point at or near stage zero as an organization, you’ll probably feel a bit daunted as you do some basic reading.  You’ll learn that asset management isn’t nearly as simple as keeping a list of your assets; to do a complete job, at some point you’ll need to worry about things like procurement, discovery tools, request and approval process, disposal management, and so on.

So, if you’re hanging your head right now and admitting that perhaps your company falls into the syndrome I’m describing, it probably feels to you like it’d be a huge project to get a better handle on your desktop and laptop assets.  But it isn’t, not if you focus on that key word “better”. Yes, it would be best to do a careful asset management package survey and evaluation, selecting just the right tool for your needs, and attempting to consider the full scope of ITAM.  But don’t let that hold you back, because the fruits of all that won’t be there for months. You can get 80% of the way there with a relatively minimal amount of effort, and it will surely be better than chaos. In short, if you’re grossly deficient in this area right now, it’s actually best not to jump right into a commitment toward an expensive package and implementation.  Work on your process gaps first.  As I’m fond of saying, “it is better to light a single candle than to curse the darkness.”

Recommendations:

• Begin to look into asset management software (see some of the links below)
• Don’t be paralyzed by not having chosen a suitable package yet. Dive in anyway.  Don’t let best get in the way of better.
  
• Recognize that (as with most things in IT), the work that needs to be done is way more about establishing a repeatable and logical business process than it is about obtaining and using a given tool.
• Work on getting a valid inventory of your current machines; that’s a manual process anyway.  Focus on the true basics:  machine ID, “birth” date, type (laptop or desktop), and current holder.
• Establish a reliable, airtight business process for adds and deletes from this inventory.  Make sure you will have a reliable master view at any point in time.  Make sure that nothing leaves or enters the pool of machines without it being reflected in the inventory.
  
• For now, stick with a simple approach: just use a spreadsheet to capture and analyze this data.  It can do a lot for you, all the way from basic inventory management and providing basic breakdowns, to helping you with your replacement strategy and budget.  An example is contained in the attached spreadsheet model, offered under a Creative Commons license for your use and adaptation as you see fit.
• The spreadsheet is designed to help answer basic questions about your machine inventory, including but not limited to examples like the following:
  • How many laptops do I have that are over two years old?
  • How much should I budget next year for machines, assuming I switch out desktops after three years and laptops after two years?
  • When is a given machine due to be replaced?
  • What’s my laptop penetration (laptops as a percentage of total machines)?  How is that due to change, based on my other assumptions?

Do you have a success story from your company with respect to the tracking and handling of laptops and desktops?  I’d like to hear about it!

Lagniappe:

• Asset Management resource chart
• InfoWorld Asset Management report
• “IT Asset Management and ITIL“
• IT Management Software

Sample “asset management light” spreadsheet:

• Corporate Desktop and Laptop refresh model

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.

His answer to me was to detail all the next steps, including negotiating the lease, hiring a staff, and so on.  He never mentioned a target date.

I pointed out to him that I’d asked him an executive question, and he’d given me an IT answer. This actually wasn’t meant as a criticism, just an observation, and I had suddenly realized that this pattern of interaction is fairly common in the IT world.  Hey, I realized, I’ve even done that myself, on both the asking and answering sides.

In other words, in this case I wanted a high-level estimate, a “when”, and I really wasn’t at all interested in the steps. IT people are trained to focus on the “how”s of a project, by necessity, and they tend to dive down quickly into determining the specific steps to get from point A to point B.  And they know that especially early on in a project, the “when” is basically unknown, since it’s so dependent on the particulars that have yet to be unearthed.  There’s such a wide range of possibility in the conceivable “when”s that to them it seems pointless to speculate.  Moreover, IT people aren’t stupid: they’ve also learned that this form of executive question frequently comes from people with an elephantine memory and a deaf ear for caveats, plus a high tendency towards great disappointment and surprise if, down the road, it turns out that the tossed-off rough estimate wasn’t accurate.  Thus, IT folks retreat into the world of the “how”s, deferring the clarification of “when” as long as they can.  And both sides end up very frustrated with the other.

So, after that prelude, there are a couple of major takeaways from this pizza parlor conversation:

1. Gunner didn’t know the opening day.  In fact, he doesn’t have any idea yet about a possible opening day.  It could be months, or it could easily be more than a year.  Gunner knows instinctively, without having to put any thought whatsoever into the matter, that there are loads of important issues to resolve before he will be able to zero in on a plausible target date.
2. It was thus kind of a stupid question on my part — but exactly how stupid it really was depends on my attitude towards the exactness of the answer I get.  I need to be utterly aware that any answer I get, this early on, is going to be a wild stab, at best an approximation, and that it may indeed be completely wrong.  In essence, I’m asking a question akin to “how long is a piece of string?”  But it’s actually only an unreasonable question if I have unreasonably lofty expectations as to the accuracy of the answer.

As we all know, CEOs and other executives do ask those kinds of questions; in fact, they need to, unless they want to just operate day-to-day and see what happens.  One can’t completely avoid answering them, and moreover, one shouldn’t.  I’ve written before about this, something I call the “impedance mismatch” between IT mentalities and executive mentalities.  It leads to the situation I’ve described where “you don’t really know anywhere near enough to estimate early on (say, during annual budget season, thinking about what you’ll do in the second half of next year), but you have to estimate anyway.”

What’s the answer?  Play speed chess. This is my frequently cited metaphor for pushing IT people into making judgments and estimates without full information and in-depth analysis.  Speed chess is where you aren’t given a lot of time to think through your moves and their implications.  And if you don’t move fast enough, you lose the game.  Equally, a group of knowledgeable, experienced IT middle-level managers can, relatively quickly, give you “SWAG” estimates on even high-level descriptions of projects, if you push them into it.  They’ll naturally be reluctant to do so, but the way to overcome that reluctance is to insist that the basic rule of the game is that these are “guesses without penalties”. They’ll do their professional best to come up with reasonable estimates (neither padded nor overly optimistic), but everyone in the game, executives and technologists alike, has to clearly understand that these estimates will be wildly wrong at least 30% of the time, because they’re based on limited information and a lot of implicit assumptions.  “Play speed chess”, intoned repeatedly as a slogan, can help both the executives and the technologists remember that, now and down the road.

So, maybe I can get Gunner to put some chess boards and time clocks into his new pizza parlor.  I’ll have to ask him for an estimate on when that’ll happen.

Lagniappe:

• Malcolm Gladwell, Blink: The Power of Thinking Without Thinking

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.

Well, that’s not at all how I see the purpose of status reports, and it’s definitely not how status reports can actually help an IT department push forward towards its collective goals.  The key start is to recognize that the status report isn’t principally a tool for evaluating the person constructing it. After all, any given project or area can encounter speed bumps and difficulties; indeed, problems are to be expected, and simply because they’ve cropped up doesn’t mean that the person writing the report is at fault.  To the contrary: mentioning problems in a status report is a good thing, because it demonstrates that the person writing it has recognized the problem and is smart enough to escalate it to your attention.

To that end, for the executive, reading the status reports of your direct reports is a really important way to keep your finger on the pulse of what’s happening in your department.  The status reports communicate to you in a regular, structured way; they educate you; they make you truly part of the process rather than an outside observer. It’s worthwhile to spend some time honing them with your staff.

As I’ve said before about writing in general, it’s the process that matters as much as the product.  The value of a weekly report is not in the information it contains; it is in the preparation. When I have to produce a status report, I (and my whole team) are forced to review all due and overdue tasks, and we’re likely to push hard to close as many of these as possible.  Nobody wants to publish a status report that shows things aren’t on schedule, so that provides a little extra incentive.  Would that behavior happen anyway, without the onus of producing a report? Sure, in some cases, but an extra kick in the pants to get some of the little things checked off tends to have a helpful effect. And even if that effect is just with respect to clearing away the little things: as the saying goes, “take care of the pennies and the pounds will take care of themselves.”

What about you, the leader, and your own attitude towards status reports?  Are you possibly one of those “don’t bother me with details” executives?  That’s fine, perhaps, but you still need to be a “do bother me with exceptions” executive.  The best exec is the one who actually wants to hear bad news.  Status reports, at their best, often provide early warning of looming bad news, and that warning should be welcomed, with no messengers beheaded.

Let’s get practical, once again.  Here are some specific tips and guidelines to pass on to your staff about status reports:

• Make and keep the reports short.  I had one direct report whose report grew by a page a week, it seemed, no matter what I told her about the need to keep it short.  Make the focus of the report the exceptions, and don’t spend much time on what’s going according to plan.

• Make the report read from the top down, like the inverted pyramid rule in journalism:

“Journalism instructors usually describe the organization or structure of a news story as an inverted pyramid. The journalist top-loads the essential and most interesting elements of his or her story, with supporting information following in order of diminishing importance.

This structure enables readers to quit reading at any point and still come away with the essence of a story. It allows people to enter a topic to the depth that their curiosity takes them, and without the imposition of details or nuances that they would consider irrelevant.”

Assume that the reader will stop reading at any given moment. Have you communicated the most important information thus far, or did you “bury the lede“, as journalists say?

• Sections I like to see included in a status report, in approximately this order:

• Highlights of period
• Topics requiring management attention
• Major activities in period
• Near-term milestones and target dates (as originally planned and as now adjusted)
  
• Key initiatives/progress towards overall goals
• Staffing report (hiring, departures, etc.)
  
• Planned travel/vacation (4 week forecast)

• The exercise of writing the report, deciding what merits inclusion, is the most important thing of all.
• It’s not about justifying your job/role/decisions/work level.  It’s about communicating the most important things so that the exec can understand the key issues/impediments, and then potentially help.
• No one should need to spend more than a half hour a week on completing his or her status report.  Yet, don’t just make it automatic! It’s a communications vehicle, so you want to weigh carefully what goes into it.
• Try not to give people a “hallway pass” on their reports, meaning absolving them of having to do one for a given week, even if they’re obviously swamped.  Communication is part of everyone’s job.
  
• The target audience (i.e., the executive) should be able to “roll up” the summary (“Highlights of Period”) as-is, into a higher-level report.  Write it accordingly.
  
• Don’t put in “gotchas” for your boss, or CYAs.  Again, that’s not the purpose of the report.
• Do collect information about hiring progress, as well as vacations/travel for you and your direct reports; it’s a logical place to record those things for public record.
• If at all possible, the report should be public, accessible to all in the department.  If there are sensitive matters (personnel, projects, strategies) that need escalation, communicate those separately.

As with so many important things in IT, you’ll know you’ve successfully ingrained status reports as part of what you do when you stop hearing your staff mention them.