CIO: “We can’t go live in six weeks as you want.  It’s going to take at least three months.”

CEO: “That’s … unacceptable!”

One of the most recurring memes in IT, for me, has to be hearing “we don’t like that estimate”, coming from stakeholders, senior management, etc. Depending on the mood and/or semi-intellectual rigor of the person saying it, the conversation then typically devolves into one or more of the following:

1. identifying and removing any hint of schedule contingency (which is often viewed as padding just to make life easier for IT);
2. mentioning repeatedly the idea of “what if we double the team size to get it done twice as fast” etc.;
3. conducting a scrutiny, one by one, of the bottom-up estimates (”it won’t really take three days to test that feature”);
4. volunteering resources (usually less than qualified) to “help”;
5. insisting on scheduling full-time work for all remaining weekends and holidays between now and the desired launch;
6. making frequent use of the phrase “why don’t you just …”
7. declaring that system delivery must occur by a specific date, no matter what.

A real-world micro-example of estimate pushback: one of my Twitter colleagues tweeted this a few months ago: “Me: it’s six weeks effort. Client: what can you give me in two weeks?” That was obviously tweeted in frustration, and was most likely intended to serve as an example of how incredibly unreasonable the client (or manager, or CEO, whatever) can be.

Yet, at core, and read literally, it’s a perfectly natural question coming from an executive who is looking to explore all the possibilities.  IT people need to learn to anticipate such scrutiny, and have coached and practiced enough with their own team to show that they’ve thought through some alternatives.  That’s collaboration as a key business contributor.  That’s strategy. In fact, showing that kind of maturity is what will take IT beyond being mere order-takers.

So the CIO/CTO’s role as leader here is to inculcate the following mindset in the collective team: don’t assume that these management suggestions are simply ignorant or obstinate. In fact, I’m arguing here that management reactions along these lines are understandable, though admittedly sometimes misguided and excessive.  I’ve been there: I’ve done it myself, frustrated (as an exec) by the estimates the team was telling me.  So now, instead of just getting annoyed at the upper management behaviors listed above, I see both sides.  Even better, I have some recommended behaviors that the IT team can adopt that will help in such situations.

First, and this is key, adopt the mindset that every plan needs to withstand some scrutiny. Expect scrutiny and plan how to deal with it. The answer from IT can’t be “these are our estimates, so you just have to accept them.”  Just as with making any management presentation, you need to anticipate the obvious questions, adjust your plan to accommodate them where possible, and have further answers at the ready.  It’s a back-and-forth, not a one-way. Delivery discussions need to be about ways to provide viable business value given the constraints. It’s a collaborative process, not a confrontational negotiation where one side makes demands and the other side caves in.

Second, spend some time seeing and removing your own (IT’s) flaws.  Specifically, consider flaws such as these, common reasons why estimates become regarded with skepticism once an executive drills down:

• Every task in the schedule, no matter how slight, is assigned at least a day’s worth of work in the plan. IT teams need to doggedly squeeze out the obvious air.
• Easily understandable tasks (ones that the executive has good familiarity with) are being estimated as taking much longer than they have historically. Way before it gets to an executive presentation, the team needs to challenge every number themselves so that this either doesn’t happen, or can be explained with a supportable rationale as to why things are different this time.
• More generally, there appears to be little or no historical basis or metrics used in establishing the estimates. Estimates that are based on facts and data, rather than people’s gut, are almost always more credible.
• Once the executive starts to drill, people cave immediately: “Oh, OK, I guess we could do that in a couple of days, rather than a week.”  Making this kind of admission is throwing raw meat to a hungry bear.  It shouts that your estimates probably had little basis in fact.  Or, that your emphasis on certain must-haves like integration testing isn’t so heartfelt at all.  At the very least, it reveals that you haven’t thrashed through the numbers internally well enough to be able to stand behind them with greater firmness. Believe it or not, and often with all evidence to the contrary, the executive is looking for where there’s strength of conviction, and where there isn’t. Strength of conviction (supported by facts, of course) may ultimately be disagreed with, but it’s usually respected.
• The team and/or project leader shows little or no recognition that there may need to be some kind of interim solution, some sort of early delivery. There’s no “team attitude”, no searching for midway points (i.e., acceptable scope reduction), no exploration of “what ifs”, such as “what if we delivered the system without an administration GUI at first?”  Once again, there’s no substitute for holding internal practice sessions and staging multiple “devil’s advocate” discussions.
• Conversely, there’s no clear “line in the sand” visible, meaning points you stick to no matter what, points that cannot be compromised if the company wants a quality delivery.

The very fact that these reasons for estimate-related skepticism even occur in the first place demonstrates the value-add of such skepticism. In other words, everyone needs to realize that it’s actually OK for management to ask people to dig deeper, to explore every option, because it turns out sometimes they don’t on their own.  It’s OK to be asked, and everyone should expect to be asked.  That’s part of everyone doing their jobs, and, cynicism aside, such active scrutiny is most certainly the job of senior management.

Steve McConnell, in his outstanding book on Software Estimation, writes eloquently on this issue.  He points out that executives typically have certain notable characteristics and well-honed skills.  The first two of these?  “Executives will always ask for what they want.” “Executives will always probe to get what they want if they don’t get it initially.”

Example: a developer once told me that it’d take two weeks to generate a report I needed as CIO. Taken aback, I probed into it with him.  Together we determined that the report I was asking for entailed nothing more than a rudimentary SQL SELECT statement, slightly dressed up. Every time a manager drills down into an estimate, only to discover that there was no “there there”, it feeds his or her unfortunate but lingering suspicion that most estimates are grossly padded. Getting the “win” (beating down the number) spurs them into even more dogged drill-down.

So I’m preaching a several-pronged approach:

• doing one’s homework so that maximum scrutiny has been self-applied long before the estimate reaches the executive;
• sticking to one’s guns to an extent that is both reasonable and facts-based;
• and then actively looking for ways to reach value for all.

One important note, though: there are often bad (but unfortunately common) ways to compromise when discussing project delivery estimates.  Here are a couple of important places not to cave:

• Suddenly deciding that you don’t really need contingency. Until perhaps the last week, it’s usually a huge mistake to assume that the rest of the schedule will go exactly as planned. Contingency in a schedule is not padding!
• Suddenly deciding that you don’t need thorough testing. Forgoing testing is pretty much a guaranteed way to launch an unstable, buggy product that ultimately will cost you much more work (not to mention the customer backlash) than taking the necessary time up front to shake out the problems.

Where’s the CIO/CTO in all of this? Supplying active leadership: educating everyone on the tenets above, coaching, cajoling, reminding, monitoring.  Strong leadership can and does reduce these common “we don’t like that estimate” kinds of proposed “solutions”. In fact, it is the mettle of the mature and successful CIO/CTO that they constantly “upward and sideways” manage their peers and management to get them to understand the cold harsh realities and weigh appropriate and reasonable trade-offs.

I recently had the privilege of being interviewed, along with other experienced senior technology executives, by CIO magazine for my thoughts on communication mistakes still made by CIOs. Some great ideas came out in the article, but when it comes to communication (see tip #1 below), there’s always more to say. So here goes.

• Communication can always be worked on and improved. I was at one company where we did a semiannual employee satisfaction survey. Even better, the company was admirably dogged about implementing specific measures to address areas of dissatisfaction that emerged from the survey results. But in every single survey, the number one vote-getter was the need to improve intracompany communications, no matter what initiatives were spawned to improve them. Communication is an ongoing challenge and necessity.

• Don’t just communicate upwards. Communication with your team is every bit as vital as your communication to management and to peers. You need your team to have a clear and common understanding of the goals, as well as getting their active contribution and buy-in on the necessary approach to getting there. You can’t go it alone.
• Hierarchy is actually helpful; use it actively. Do your best to avoid providing explicit nuts-and-bolts-level direction to staff members other than your direct reports. Jumping in and telling people at all levels what to do confuses people mightily, undermines the authority of your direct reports, and increases the likelihood of mixed signals. And it’s just plain inefficient. Early in my career, I was a director responsible for a major week-long software rollout in one of my company’s regional offices. The project manager of the initiative was one of my direct reports. But then, the stakes were high enough that the CIO decided to fly down, and of course, the regional VP of IT was there as well. So for a week, we had four management-level people all sitting in every meeting, each trying to actively demonstrate they were in charge and look good to the others. Or, there’s out-and-out, from-the-top, intentional bypassing of the chain of command: Amazingly, I’ve seen cases of a CEO setting up a task force without involving or even informing the people who managed the members of the task force. Talk about undermining!
•  Be clear about what’s actually a directive and what’s just an exploration. Dawn Lepore, CEO of Drugstore.com, recently spoke in an interview about how she couches her direction to her staff as to whether it’s a “a light bulb or a gun”. “A light bulb means this is just an idea I had, so think about it, see if you think it’s a good one. Either follow up or don’t, but it’s just an idea. A gun is, I want you to do this.” Surprisingly, people often can’t tell the difference on their own. As a leader, you typically want most meetings, particularly at a senior level, to feature open brainstorming, a free exchange of out-of-the-box ideas, but that means it’s all the more important to carefully identify what emerges as actionable initiatives and what things continue to be simply thrown around as possibilities.
• Put it in writing. Supplement the directions you give in meetings and one-on-ones with a clear and succinct written summary. Doing this both clarifies and makes an unambiguous record of what you’ve asked for, and accurately communicates it more broadly than just to the people who happened to be in the meeting. It’s a way of demonstrating that you’re declaring yourself accountable. Doing so is vastly preferable to having your people run around claiming “The CIO wants this.” (And with some, once they discover that such a line grants them all sorts of vicarious power, they’ll tend to overuse it, and at inappropriate points). I’ve seen a lot of ineffective leaders follow some kind of old-school “just tell them” mentality, and they cause significant confusion in the ranks by failing to put things in writing. And it’s no wonder that with this approach, which evolves into a kind of “Telephone” game, they’re often disappointed in what they get.

Oral communication is often vague and ambiguous. Written communication is on the record. Strive to go on the record as much as possible.

• Be utterly clear about who owns the execution of the initiative, and who will be making specific lower-level related decisions. Most notably, avoid having people think that everything needs to be cleared with you at all junctures. For most initiatives, your role is to set the overall goal, not to shepherd day-to-day the specific process of getting there. Lack of clarity here is common, even when everything else is done right.

Common sense, all these tips, no? The thing about common sense, though, is that it’s often frightfully uncommon.

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“

“We went live before the system was ready”.  It’s a common excuse/explanation that I hear from IT people when they tell war stories about system launches that failed miserably. Implicit (and sometimes explicit) is the add-on statement: “and we told them so beforehand, too.”

There are obviously many things (and many parts of the org chart) that contribute to a failed launch, but here I’d like to focus on what drives this particular kind of launch-before-readiness, where the views of the rank-and-file are unheard or ignored.

In a nutshell: it’s management pressure. Sometimes that pressure comes from middle management, sometimes from the very top, and often from both.

Why do executives apply the pressure? There are a number of reasons:

• They actually believe it’s the best way to keep the team producing and working hard. They fear that extending the deadline will cause a let-up.
• Their own bonus and/or job is on the line if there’s a delay. They, or their management, regard a launch delay as a failure, just as much as a bad launch. At the very least, a delay means losing face.
• Testosterone (for either gender) sets in: a “refuse to lose” mentality. To some extent, that’s what has gotten them where they are.

Deadlines matter, of course, a lot, and people who are lackadaisical about deadlines simply shouldn’t work in IT. That said, if you bull-headedly insist on adhering to deadlines, to the exclusion of facts-based input, it makes you all the more likely to delude yourself that you’re really ready, just because the launch date has arrived and the pressures are heavy. If the stakes aren’t high, that may even be fine. (But, are the stakes ever not high in these situations?)

Let me tell three anecdotes that illustrate management “refuse to lose”:

• Earlier in my career, I was a middle manager, wrestling with a project that was both controlled by and staffed with a single “Big 5” consulting vendor’s people, with millions of dollars per month of consulting costs being racked up.  The high-profile initial system launch was a week away, and according to the bug tracker, there were still over 100 open major bugs. I sat down with the vendor’s partner-level project head. I don’t remember the precise conversation, of course, but it went something like this from him: “Oh, we’ve already got 39 of those 100 fixed in dev, 44 others are being worked by our best people and will be resolved by tonight, so really, there are only about 15. Four of those we think have workarounds so there are something like 10. I don’t think we’ll be getting many more bugs. We usually resolve bugs in a day or two, so even if each one takes two days, we’ll be able to close those ten and be ready for launch in a week.” I sat in awe (and frustration) at this hand-waving, this magic with math, and at his reluctance to think things through without an agenda. Here, “refuse to lose” had developed blinders, simple math had turned fuzzy and infused with vested interest, and IT best practices (not to mention common sense) had flown out the window.

• I worked as VP of Operations under a dev-oriented CTO. We had a late night launch, and the CTO was there in person, hovering over my sysadmins who were attempting to install the latest release into production with little success. The installation had failed, starting with the very first run of the script. “No, try this: run just those three lines of the installation script we provided you, then type these two commands, then run these other five lines.”  When that didn’t work, he came up with another idea, and then another. The next day, he sent out a company email declaring victory and congratulating his dev team, because the system had come up finally, even though it had run for a total of only two hours before crashing hard. Installation by seat of the pants. Refuse to lose.

• I arrived on the scene as the new CTO of a company in the midst of a complete replatforming project, completely retooling and replacing their sole product. The project had been underway for about nine months already; just before the point of my arrival, the team had been told by senior management that their launch date was going to be in six weeks, no ifs, ands, or buts.  I proceeded to do what I call a quick “temperature check”: I asked to see key indicators of readiness, such as bug counts over time and test case execution reports.

As you’ve surely guessed, I quickly determined that the facts didn’t even remotely support the possibility of a launch in a mere six weeks. About 40% of the code was still to be written; less than half of the test cases had been executed at all, with an even lower percentage having passed.  I marshaled my facts and figures, and went in to tell the CEO of this sorry state.  Judging from my experience, I told him, it looked like it would be a number of months, not weeks, before the product could be successfully launched. I remember him sputtering “that’s unacceptable”, and pressuring me on what I could do to, yes, bring off a launch in six weeks. (Cutting to the end of the story: we launched, successfully, nine months later).  In this case, a mixture of testosterone and probably some job-on-the-line aspects were driving this CEO to ignore facts and look for ways to bull through to success despite obvious counter-indicators.

The tragedy of the space shuttle Challenger has become almost cliché along these lines: a combination of executives feeling pressure and ignoring communication from lower ranks about major problems. “They also disregarded warnings from engineers about the dangers of launching posed by the cold temperatures of that morning and had failed to adequately report these technical concerns to their superiors.”  For whatever reasons, NASA management gave the green light for launch despite the adverse weather conditions. In essence, they “refused to lose”, and by doing that, they lost in a major way.

Takeaways:

• Don’t let your executives turn you, and don’t let them become, riverboat gamblers, where failure is a strong possibility through a premature launch. The company culture must be shaped so that it views a spectacularly failed launch as much more onerous than a delayed launch.
• Don’t let “groupthink” settle in, where your people are afraid to speak up. Any and every member of the team should have a chance to “pull the emergency brake”.  Especially, holding a formal “go/no-go” meeting is essential, where any stakeholder or project participant can voice concerns and point out facts that speak against readiness.
• That said, do be careful of the pessimist amid your ranks, who typically voices dire predictions on every project, and who sooner or later will be proved right. Insist on facts, not “Eeyore-ism”.
• Let your team watchwords for these situations become the following: candor, and facts. Bring both to the meetings, or go home.
• The best way to avoid letting pressure drive a premature launch: establish your launch criteria clearly and openly, with quantitative measurements, way in advance. If you don’t have legitimate facts-based ways to tell if you’re ready (i.e., not just the launch date arriving, and not your testosterone level that morning), well then, you’re not ready.

Without a doubt, “refuse to lose” can be a great attitude, up to a point. No executive, no team, should ever become blasé about missing a target. But “refuse to lose” can’t ever be allowed to become “refuse to face facts”. When it does, you don’t just lose face: you just plain lose.

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.

If you’ve been in the information technology industry for a number of years, certain jokes tend to pop up again and again. Why? I’d say it’s because their underlying premises, the things that make them applicable and funny, continue to occur. So even if you’ve heard these before (and that’s probably the case), it’s worth taking a few moments here to look at them again and consider what makes them timeless.  Remember, even jokes have morals to the story. Sometimes especially jokes.

1) Just what they asked for but not what they want
Something that’s been drifting around the Internet for decades, it seems, are various IT versions of the famous poem, “Twas the Night Before Christmas,” usually called “Twas the Night Before Implementation.” I won’t include the whole text here; most notably, the poem ends with the “super programmer,” akin to Santa Claus, swinging into action and saving the day.  And yet, the final two lines read,

Who in IT can’t relate to this eleventh-hour disconnect between what the user “wants” and what IT has arduously created and delivered? Why does this phenomenon keep happening? A lengthy serious answer here would derail the intended levity of this post, but consider the following:  the long-standing industry practice of pure, unadulterated “waterfall“-style requirements gathering before design, build, test and deliver tends to lead to such disconnects. That fact certainly presents an argument for greater agility in the process, greater involvement of stakeholders throughout, and resistance of “big bang” approaches to systems delivery.

2) I had a truck like that once:

This joke almost always comes to mind whenever I hear IT people blissfully bragging about the complexity or size of their infrastructure, latest system, etc.  For example, most recently, my friend Gunner was telling me about his current development project, just entering User Acceptance Test: “Our programmers have gotten a total of 8 hours sleep in the last three days!”  “Yes, Gunner,” I replied. “I had a truck like that, once.”

Size, complexity, and lack of sleep are sometimes unfortunate realities, but they are rarely great things to brag about.  Don’t let your enthusiasm for what you’ve accomplished make you forget that simpler is nearly always better than more complex, smaller almost always better than large, and sleeplessness leads to bad decision-making in the trenches.

3) What you just told me is technically correct but of no use to me whatsoever

Rackspace, a prominent managed hosting provider, recently incurred a massive outage. Even though this is a company that prides itself on “fanatical service,” (and to be sure, is praised by many of its customers for providing such), on the day of the outage, it sent out a “customer incident report“, featuring sentences like, “The generators experienced a subsequent excitation failure forcing transition of cluster A back to the primary utility feed prior to the completion of UPS repairs.” Rackspace’s incident report is an amazingly bad example of jargon-laden, un-customer-oriented IT communication. There’s no discussion of real root cause (the breaker tripped, but why?) or specified action plan, just a bunch of seemingly nervous technobabble that lets no one understand what really happened, why it happened, and what they’re doing to ensure that it won’t happen again.

In other words, everything in their report is technically correct, but it’s no use to anyone. Sure, they were still in the throes of diagnosis, but that doesn’t excuse the plethora of excess detail and their failure to address what customers really are interested in. This kind of approach inspires negative confidence among one’s customers, needless to say.

4) Difference between a methodologist and a terrorist
This joke has also been around for decades. I stopped telling it for a few years after 9/11, but it continues to make a needed point:

I’ve frequently noted that some IT folks latch onto a particular methodology (Rational, Agile, Lean, whatever) and come to see it (and it alone) as representing pure, unvarnished guidance and truth.  If not brought back to earth, they can drift into a discipleship attitude that there’s really only “one true way” of approaching systems and projects.  If confronted with a failure in a project using their “one true way,” they’re quick to claim that the methodology wasn’t fully or correctly implemented (“If it doesn’t work, you aren’t doing it right.”).  This “one trick pony” perspective, a sort of tunnel vision that lacks introspection, creates a rigidity that’s almost always detrimental.

In fact, it tends to put you into situations where joke #1 is relevant.