How do we (IT executives) get away from being typecast as technologists, unconsulted on core business issues and approaches? Face it, that’s a common situation and dilemma that we all encounter, early and often, and it’s the grist for a constant mill of articles and blog posts and books on business/IT alignment.

Lately, though, a part of that mill has started insisting that focus on technology should be avoided altogether by what they usually cast as the “next generation” of CIO.  So I’m going to (again) be a bit of a contrarian here: it’s possible for the pendulum to swing too far in the wrong direction. I think that we can at times go overboard in our desire to avoid being seen as the geek with the pocket protector.  Examples: some preach outright denial that there might be such a perception problem: don’t even think of using the terms “IT” and “business”, they urge, and they recommend against ever discussing “alignment” as a goal.  Stop referring to the “business” as something separate, they recommend; IT is just as much part of the business as anything else! Similarly, their advice is “avoid discussing the technology itself.” As if a mere shift in language could solve the perception problem and automatically propel the CIO into the inner circle of decision-makers.

Here’s the gist of how I see it, though: in many (I daresay most) companies, the path of IT from high priesthood to strategic key playerdom has not really been fully traversed: in other words, greater alignment IS still needed of IT with “the business.”

In many companies, there’s still a trust problem. IT is arcane. IT can be as resented as a roadblock as the in-house corporate counsel types who veto certain kinds of corner-cutting.  Of course we’re “part of the business” (and increasingly so), but that doesn’t mean it’s wrong to continue to focus on breaking down the walls that linger.  The walls, in many/most places, are a reality, and it’s going to take steady, relentless, active work, not just a shift in language, to scale them. What especially will not help our effort to do that is if we embrace this odd trend of sneering at technology as a lesser-order concern—basically, positing that we should let someone else do that while we do the important (strategic) stuff.

In other words, I differ (vehemently) with those folks who now look down on such things as the need to align IT with the business, or who don’t recognize the benefits that come from regarding people as “internal customers”, or who recommend even avoiding using the terms “IT” and “business”. While the basic spirit behind those sentiments is of course valid—again, it’s undeniable that IT is part of the business, as much as any other department—it is in fact IT that has a problem in how it’s perceived by other elements of the company, going back to the high priesthood. Let’s be frank: IT folks have often been snooty, vague, cagey even, about what we do, why we do it, and how we’re meeting the company’s business needs as a whole. Deprecating the important progress and mentality shift that’s occurred in the last few years (that is, the high priesthood evolving to a service mentality) is exactly the wrong approach.

And somehow, inexplicably, the deprecators are getting louder, despite years of research and general agreement on the value of approaches such as IT governance, the ongoing need for IT/business alignment, etc.

Taken to an extreme, insisting loudly that IT is part of the business can extend to feeling that IT knows just as much about what’s good for certain business processes (say, manufacturing or shipping or collections or whatever) as the people executing those functions on a daily basis.  From there, it’s just a small but perilous step back into the old sort of IT arrogance, where systems were designed and deployed with little or no feedback from the actual users.  I exaggerate? Quite possibly, but I’ve seen it happen.

IT needs to both know its place and insist on its place, not one or the other. Here’s another example of a truly ham-fisted (even though well-intentioned) attempt to align IT more closely with business: I took over as CTO at a high-profile internet company, in the midst of deep, bet-the-company changes to its main product, a consumer-facing web site. I learned in my first few weeks that my predecessor had initiated a robot project.  His idea was apparently that he’d program this robot to walk the halls of the company, greeting people and thus making them feel more comfortable with technology. As Dave Barry is fond of saying, I am not making this up.  Needless to say, this project swiftly became a laughingstock across the company, representative of IT embracing technology for technology’s sake, completely OUT of alignment with business needs. Meanwhile, systems were crashing, projects delayed, etc.  This CTO somehow thought he was being strategic and business-oriented, but he actually was just being plain clueless, and more tech-focused than ever.

With IT’s background and history, the push towards IT/business alignment is ongoing and needs to be continual, rather than dismissed as something we’ve now evolved beyond. Even more, alignment mustn’t be deprecated as somehow beneath the higher goal of strategy. It’s not an either/or, and it most certainly doesn’t happen through mere declaration. And openly striving for alignment with our peers is nothing that anyone should present as a taboo or a sign of weakness. Additionally, at the same time that we serve as service providers to the company, we can and must be strategic in our outlook. This shouldn’t be either a surprise or controversial; in fact, excellence in tactical delivery is the ante that gets you to the strategic table.

It’s taken decades to get where we are—and I’d say (given, for example, the anecdote I cite above) that most of us are not really there yet anyway. Let’s not risk reinstating the “ivory tower” of strategy, devoid of the reality that comes from grappling with the actual pragmatics of implementation.

So, here are MY three tips on how to help convert your CEO’s understanding of where IT fits into the bigger picture. You’ll notice the emphasis of these points is quite different from the similar list in the piece I’m responding to here: in particular, my points stress a healthy balance between strategy and tactics, technology and business.

• Make sure there’s a rock-solid prioritization mechanism for all projects, where the priorities are clearly set, the tradeoffs carefully examined, and tough choices explicitly made and regularly revisited by the group of senior management, including the senior technology executive, who are jointly responsible for the business success of the company.  Focus on IT governance, Project Portfolio Management, etc.

• Speak up visibly and strongly to ensure that “roof projects” are given appropriate attention and priority. Build for the day after tomorrow rather than just for tomorrow. You in IT are a key advocate for this sort of basic corporate responsibility; you have and need to exercise your equal seat at the table.  And don’t let a misguidedly monomaniacal focus on strategy derail your obligation to keep the trains running on time. Nothing undermines the case for IT to be viewed as having a greater strategic role more than if the company is experiencing ongoing crises in basic delivery and systems.

• Be the straw that stirs the drink. IT, given a leader with appropriate vision and perspective, can and should be a natural cross-functional leader in the enterprise, both initiating business innovation AND espousing tactical responsibility.  They go hand in hand.

Let me end by quoting my colleague Steve Romero, who wrote, “Recognize that the “achievement” of alignment does not mean you’re done. This is where the “journey” analogy comes in. Think of IT-Business Alignment as “getting your head above water.” Once you reach the surface, you are not done. You need to keep treading water or you sink again. IT-Business Alignment is something that must be maintained as opposed to achieved.”

Lagniappe:

• Michael Krigsman, “IT failure? Blame your CEO.”  February 16, 2010
• Steve Romero, “IT-Business Alignment is Not a Meaningless Catchphrase“, October 28, 2009
• Michael Pattison, “Is IT – Business Alignment Meaningless?“, November 6, 2009
• Bob Evans, “Global CIO: Suicide Strategy For CIOs: Aligning IT With The Business“, October 13, 2009
• Fred Cummins, “Is Business-IT Alignment Suicide for the CIO?“, October 21, 2009
• Mary Nugent, “The Four Phases of IT/Business Alignment“, December 10, 2004
• Paul A. Strassman, “What is Alignment?  Alignment is The Delivery of the Required Results“, Cutter IT Journal, August 1998

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“

I’ve done several posts featuring what I call “Peterisms”, which are basically aphorisms I’ve adopted that encapsulate hard-earned IT lessons. Let’s turn it around this time, and talk about two sayings that sound equally folksy-sensible, and that I hear again and again, but which I feel are actually dangerous to apply to information technology work. And, of course, I’ll discuss why that’s so.

• If it ain’t broke, don’t fix it

• A camel is a horse designed by a committee

So, not all aphorisms are created equal. If you’re in IT, I advise that you avoid the attitudes and philosophies contained in these two.

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

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.

Cultural references are among the most powerful language tools around.  The old cliche may be true that a picture is worth a thousand words, but equally, a well-targeted cultural reference, used as an analogy, can stream light onto a subject better than dozens of droning paragraphs of prose.

So here’s one that comes to mind over and over again in the course of IT management: the Wizard of Oz.  And it’s not a flattering analogy; in fact, it serves more as a warning or a reminder of what not to do.

Specifically, think about the Wizard of Oz’s behavior when Dorothy asks him to help her and her friends.  She gets upset when it seems that the Wizard isn’t going to help them, but he assures them that he will, if they do just one little thing:

The Wizard: Silence, whippersnapper! The Beneficent Oz has every intention of granting your requests. [Lion instantly regains consciousness and sits up.]
Cowardly Lion: What’s that? Huh? What did he say?
The Wizard: But first you must prove yourselves worthy by performing a very small task. Bring me the broomstick of the Witch of the West.
Tin Man: But, but, but, if we do that, we’ll have to kill her to get it.
The Wizard: Bring me her broomstick and I’ll grant your requests. Now go.
Cowardly Lion: W-w-what if she kills us first?
The Wizard: I SAID GO!!!

How often do you, as an IT executive and overall manager of people, tend to display that behavior?  How often do you ask someone (a business stakeholder, or one of your staff) to first go out and fetch you a broomstick, so to speak?  I know I have.  Why does this reaction occur?  There are two basic species of reason:

1. It’s a great way to delay having to act — so, be careful of doing this as a knee-jerk response simply because you’re busy and swamped.  It becomes a defensive mechanism, and yes, your stakeholders and/or employees will start to pick up on it and/or imitate it too fully and frequently.  I had one IT manager tell me with great delight that a really effective way to get people to shut up about their needs was to ask them to document those needs.
2. Sometimes, well, you actually need that broomstick before you can grant the request. In other words, sometimes (often, in fact) you can’t magically solve people’s problems unless and until they do a little groundwork themselves.  Sometimes that’s as simple as having them write down their actual requirements, rather than leaving it to a couple of ambiguous sentences exchanged in a hallway conversation.  Sometimes it’s asking your employee to more fully research alternatives before you sign off on a purchase order for a software tool or hardware acquisition.

Remember, it’s actually acceptable (indeed, it’s usually necessary) to set these kinds of prerequisites, such as asking users to provide things like documentation and requirements and prioritization.  Granted, sometimes doing so is one of the few ways to slow down the stream of needs from the firehose that’s trained at your eyeball.  Sometimes it’s the only way of giving a quality response on things like a request to estimate the work level of effort to accomplish something.

The trick, of course, is distinguishing between situations when you’re imitating this Wizard of Oz behavior out of a pure knee-jerk reaction, and situations when you really need that broomstick in order to fulfill a request.  The key? Don’t ever ask for any broomsticks that you don’t plan to use directly and rapidly to help serve the person bringing you the request.  That tends to backfire, especially when you’ve let your broomstick request become an implicit promise to grant their wishes once they comply.

Remember the outcome in the movie.  Dorothy and her entourage, amazingly, succeed in obtaining the broomstick, and they bring it back to the Wizard, expecting to now get their wishes granted.  That’s when things really hit the fan, and they have genuine reason to get angry.

The Wizard: Can I believe my eyes? Why have you come back?
Dorothy: Please sir, we’ve done what you told us. We brought you the broomstick of the Wicked Witch of the West. We melted her.
The Wizard: Oh, you liquidated her, eh? Very resourceful.
Dorothy: Yes, sir. So we’d like you to keep your promises, if you please, sir.
The Wizard: Not so fast, NOT SO FAST! I’ll have to give the matter a little thought. Go away and come back tomorrow.
Dorothy: Tomorrow? Oh, but I want to go home now!
Tin Man: You’ve had plenty of time to think already!
Cowardly Lion: Yeah!
The Wizard: DO NOT AROUSE THE WRATH OF THE GREAT AND POWERFUL OZ! I SAID COME BACK TOMORROW!
Dorothy: If you were really Great and Powerful, you’d keep your promises!

And it goes downhill from there; the Wizard is (rightly) ultimately exposed as a charlatan.

So, key take-aways:

• be careful what you wish for and ask for from stakeholders and co-workers;
• be even more careful about what you have promised to do for them once they provide it;
• and, as appropriate to the situation, be prepared to be Great and Powerful once you actually get it: keep your promises.

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.

THE BOY AND THE NUTS

A boy put his hand into a jar of nuts, and grasped as many as his fist could possibly hold. But when he tried to pull it out again, he found he couldn’t do so, for the neck of the jar was too small to allow the passage of so large a handful. Unwilling to lose his nuts but unable to withdraw his hand, he burst into tears. A bystander, who saw where the trouble lay, said to him, “Come, my boy, don’t be so greedy: be content with half the amount, and you’ll be able to get your hand out without difficulty.”

Do not attempt too much at once.

So, if it’s not at this point overwhelmingly obvious after the above, what’s the trap that I’ve seen quite literally take down small to medium-sized companies? It’s when business stakeholders insist that IT, no matter what the staffing and budget realities may be, take on multiple, simultaneous major projects. That way IT will deliver more, right?

Wrong.  In fact, almost never.  By pushing for doing more more more, you typically get effects such as the following:

1. a failure on almost all fronts, with everything from sloppy work to rework to absolute crisis, due to having been stretched too thin;
2. a systematic neglect of all-important sustainment and maintenance activities external to the project but often with overlapping personnel: since no one seems to be asking about these activities very much, they represent a great place to cut corners when being pressed on more visible projects;
3. a chronic and ever-spreading feeling throughout the company that “IT never delivers,” because if you ask for everything all at once, there will always be something that isn’t delivered on time or to expectations
4. a demoralized staff that wants to do great work but knows that it isn’t.  And everyone on your staff starts to feel that if they speak up about the reasons why, they risk being branded as “no can do” kind of people.

I’ve seen small to medium-sized companies engage in major systems replatforming, while simultaneously launching new products, going international, upgrading or even replacing their ERP, and initiating a significant data warehousing effort.  Oh, and doing all this while keeping a tight lid on, or even reducing, the staff available to work on these efforts.  Any seasoned IT professional would tend to counsel such a company to focus on at most two major efforts of this nature a year, but somehow, a sort of testosterone frenzy seems to set in, a mass euphoria, and people barrel ahead no matter what.

The hardest part of managing IT expectations in a company is knowing when and how to say no to fervent desires.  To put one’s foot down and say “enough”.  To draw a line in the sand. To insist on a sober prioritization of the many pressing needs.  And yet, to survive in a climate where influential people really (and forcefully) want what they want and don’t like hearing that they won’t get it anytime soon.  And who then, often, look at you as if you’re the problem, you’re the one stopping it.  What? they seem to say, or even say directly: you don’t want to set aggressive goals?  You don’t want to be audacious and assertive?

It’s not, or shouldn’t be, a source of shame for an IT executive to insist that projects be right-sized to the capabilities and the staffing that are actually available. It doesn’t, or shouldn’t, mark anyone as unwilling to be aggressive or hard-working when taking on projects if they simply make sure that they will have what they need to make the project a success.  Somehow, though, in many companies, it’s become normal and acceptable to squeeze and squeeze IT, with IT’s stated needs (time, resources) somehow regarded as overstated, and then to complain about the end results when projects don’t come off.

Your principal defense against this unrelenting pressure is to make sure, for each project you take on, that you carefully and visibly outline the probable time frame, holistic resource needs (including necessary participation from business stakeholders), and the full expense (taking all costs into account, as I’m so fond of saying).  Too often, despite having gotten this careful “full disclosure” approach in advance, I’ve seen executives panic about a third of the way into a major project, simply because the project was costing so much in time and treasure, even though those costs were actually completely in line with the planned expenses.

To be fair, this kind of chronic “Boy and the Nuts” behavior at such companies often isn’t limited to dealing with IT matters: it usually ripples into product development, sales office expansion, splintered and ultimately wasteful marketing initiatives, and other areas.  It’s well-meant, of course, with the idea being to do as much as possible, and get big fast, as the mantra of the Internet once had it.  Well, we all need to be a voice not so much for “get big fast”, but for “get realistic soon.”  Otherwise, we’ll all go, well, NUTS.

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.

A sports team that concentrates mostly on the razzle-dazzle plays (the flea flickers, the statues of liberty) usually lacks a lot of grounding in the fundamentals, at least eventually.  Sometimes this focus on the “trick plays” also becomes an excuse for the team to run wild and free: lots of “hail Mary” plays, some of which unfortunately sometimes even work, with all of it leading to the near-total abandonment of a disciplined approach.  In this kind of scenario, fundamentals only get some attention when (to continue the metaphor) a missed block ruins a trick play.

I am, you see, talking about blocking and tackling: executing the fundamentals for everyday success.  Recognize that a significant part of success in IT (and of great value to the company as a whole) consists of making sure there’s “no news,” so to speak: seamless upgrades and launches, no outages, no instabilities, no glitches, no long-standing bugs.  That’s what I mean by “no news”: it’s never the subject of corporate press releases, but it does take work; it can’t be taken for granted, and it can’t be allowed to be invisible and/or unvalued when budget and staffing comes under scrutiny.  If the subject of all management scrutiny on IT has to do with “trick plays”, you’ll implicitly push your IT staff to focus mostly on those, to the likely detriment of the everyday “keep the lights on” work.  You’ll run any number of trick plays, and as I said above, some may even work.  Even after the successes, you probably won’t clean up or do the necessary afterwork later, because you’ll have moved on to the next trick.  Eventually, the backlog of work left undone, or work done poorly, will catch up with you, and something, perhaps a lot of things, will come crumbling down.

As in most things, a more balanced approach will reap better and more consistent rewards.  You want to strike that sort of balance in what you shoot for as an organization: equal parts process improvement; bottleneck elimination (long, slogging work with little glamour to it); and methodical, planned, well-executed new systems work.

2. Keep telling IT that they need to be “results-oriented”. The trouble here is that in IT, quick “results” that appear to be good often aren’t.  They often carry with them untold amounts of what industry observers call “technical debt“:  basically, in your haste to deliver, you make decisions, or cut corners, for which you will pay down the road, and in spades.  A system is rolled out on time, but then has months of instability and heartache because, well, it wasn’t really ready.

It’s a well-known fact that any given two developers can differ in productivity by an order of magnitude, and that it’s really hard to tell the difference.  Nearly anyone can churn out a report, for example.  Without solid analysis and careful testing as part of its construction, that report might be missing key ingredients. It’ll produce numbers on a page, but those numbers could lack validity.  The fact that the programmer got it done by Friday is next to useless if the report causes you to make a seriously incorrect business decision.  “Results-oriented” has to be defined with some ingredient of long-term success, not just immediate gratification of the desire.  I’m certainly not arguing against results, but I am quite carefully distinguishing between apparent (and short-term) results and solid, bankable, long-term success.  With IT, it’s admittedly pretty difficult to tell the difference – in fact, telling the difference requires a depth and detail of involvement that business stakeholders are basically never going to have. To work through that dilemma, you’re going to need to find a solid IT executive and senior staff, with a grounded, sober, aggressive-yet-methodical approach towards striking the balance. And you’re going to need to empower and trust them.

Remember, management tends to get the behavior that it rewards. If you reward mostly the trick plays, or if you reward simple speed of delivery in the misguided notion that you’re being “results-oriented”, you’ll probably train the team exactly towards exhibiting those behaviors. What will you be giving up, though, and will you even know it when you see it?  Most importantly, will you know it before there’s a crisis that ensues?

I saw a sign on a roadside billboard once that stuck with me and that I’ve repeated to my staffs since then, because of its stellar applicability to IT strategy and projects: “Discipline is remembering what you really want.” What you really want, of course, is solid, dependable IT systems, run efficiently and reliably, with little fanfare.  You just need to remember that as you’re screaming for results on the latest trick play.  One tell-tale reminder of the need to remember what you really want often comes when a crisis erupts because something got badly botched in delivery (the flubbing of the trick play, so to speak) due to a failure to execute the fundamentals.

Next time, I’ll write about trap #1, the biggest trap of them all, the single most guaranteed way 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.  Want to guess what it is before I write about it? Post a comment with your idea!

Lagniappe:

• Steve McConnell, “Productivity Variations Among Software Developers and Teams: The Origin of ’10x’”