CTO/CIO Perspectives http://www.peterkretzman.com Intensely practical tips on information technology management, by Peter Kretzman Mon, 07 May 2012 19:51:11 +0000 en hourly 1 http://wordpress.org/?v=3.3.2 IT consumerization, the cloud, and the alleged death of the CIO http://www.peterkretzman.com/2012/03/14/it-consumerization-the-cloud-and-the-alleged-death-of-the-cio/?utm_source=rss&utm_medium=rss&utm_campaign=it-consumerization-the-cloud-and-the-alleged-death-of-the-cio http://www.peterkretzman.com/2012/03/14/it-consumerization-the-cloud-and-the-alleged-death-of-the-cio/#comments Thu, 15 Mar 2012 05:11:01 +0000 Peter Kretzman http://www.peterkretzman.com/?p=811



As with just about any area, IT is a discipline subject to fads and memes, “received truths” that seem to arise in the press or the blogsosphere and then ricochet around the echo chamber until they sound plausible even to skeptics. A number of these roll across my Twitter stream every day. But one such meme rises so high to the top that it has to be the sole focus here. And that is the much-repeated “death of the CIO” meme, coupled as it is currently with dreamy visions of the world brought to us by the consumerization of IT and the cloud. They’re all linked, at least in many pundit eyes.

Here’s the gist of their argument: users can go out and get their own technology now; they don’t need IT to do it for them. End-users are now IT-savvy, and can fend for themselves.They’ll bring their own devices (BYOD); they don’t need or want IT to provide devices for them. They’ll procure the services they need and want from the various SaaS offerings in the cloud or from outsourced vendors, and they’ll handle it all themselves.

All this ultimately gets not only expressed as the question of who needs a CIO anymore, it goes even further: who needs an IT department at all anymore? Says one article, “If IT does not provide the end user with the infrastructure they need, the latter can rent it, by the hour or month from companies like Rackspace or Amazon… All you need is a credit card and no approval from IT.”  Other CIO “thought leader” articles feature astonishing blanket statements like, ”With the consumerization of IT, consumers can create value for themselves and the enterprise, using technology that costs the enterprise nothing.” And people even take this so far as arguing that the CIO at this point should just leave technology up to the VARs.

Let me be clear once again: this frequent linking of cloud and IT consumerization to the looming demise of the CIO and IT is not just misguided, but actually gets it completely backwards. In fact, I argue that IT consumerization and the cloud will actually elevate the importance of IT within a company, as both a service and a strategic focus.

Let’s list and then discuss some of the ways that combining these memes (IT consumerization, cloud, and the ensuing heralded death of the CIO) falls down when measured against common sense and reality:

  • It fails to understand the full range of what a CIO (or IT) actually provides for modern-day companies
  • It fails to recognize the profound pitfalls of a decentralized and fragmented approach for company systems and technologies
  • It erroneously equates IT consumerization with the BYOD trend, missing the larger important picture that underscores the strategic need for IT
  • It misunderstands the interplay of commoditization and competitive strategic advantage

What IT provides

People who see the CIO’s role diminishing or IT even vanishing altogether don’t seem to understand the full range of the CIO’s responsibilities, and the importance of more, not less, technology stewardship as system access broadens. They somehow seem to view the CIO and IT predominantly as the folks who keep the servers running. If we have no in-house servers etc., they reason, why do we need IT? But, as someone recently and eloquently said, that’s like viewing the job of the parent as being the one who drops the kid off at school every day.

Face it: it’s not technology alone, the bits and bytes and systems and wires, that’s the hard part when it comes to leveraging technology itself to provide value to an enterprise. Rather, firms desperately need someone, at a suitably high level in the organization, to actively shepherd the business prioritization, integration, implementation, outsourcing, and articulation of value when it comes to complex, technology-based undertakings: that’s the hard part. That part won’t go away. That part will never go away.

What it means for IT to be a service organization

Yes, IT needs to be a service organization to the rest of the company. But, pundits complain, often it isn’t a very good one, or it’s too expensive, or often it focuses so much on being a service organization that it doesn’t get perceived anymore as adding much value beyond that service. And as those services become readily and cheaply available elsewhere, and users more sophisticated in technology, it’s easy to jump to the conclusion that IT is no longer necessary, and many do just that. But that leap reflects a kind of tunnel vision about IT’s role.

Many IT pundits can’t seem to recognize two simultaneous truths: IT needs to be a strategic value-add; and it needs to be a key service to the company when it comes to getting things done, reliably. When things don’t work: people need help. It doesn’t matter if we have cloud or BYOD or the upcoming Apple IT telepathy product; users will still need help. But realize that the day-to-day work of helping users is actually not the major role of IT in any non-trivial modern-day firm: even before the days of BYOD, administering desktops and laptops, while important, was one of the relatively minor services provided by IT. Even if that aspect of the work disappears entirely in this brave new cloud-driven world, we’re left with everything else: the hard part of making things work together, support business changes, and so on. And tackling the hard part is actually the key IT service to the organization.

Because sure, maybe people can now administer their own devices and procure their own systems in the cloud. But then, often without having planned or anticipated it, it turns out they need those systems to talk to one another. Then they need to worry about changes and versions and backups and downtime. All the simple stuff about cloud and BYOD works just great, but only while it’s still simple. As Marc J. Schiller puts it, tech-savvy business users ”don’t have the time or the inclination to work through all of the nitty-gritty details that are required to ensure that the systems they are putting in place do, in fact, collect and integrate data with other corporate resources. They don’t have the time or the expertise to evaluate the information integration and interface requirements a particular system may create. And they certainly don’t want to be on the hook for all of the data security and regulatory compliance issues that are growing by the day.” In other words, we’re left with the hard part, the messy part, the part that someone needs to figure out holistic, long-term answers to.

That won’t go away. That will never go away.

The pitfalls of IT fragmentation

Stop for a moment and realize that the argument that the “cloud and IT consumerization will lead to the death of the CIO” pundits are making amounts to this: that in an IT world that is becoming staggeringly more complex, with ever more options and an accelerating rate of change, we somehow no longer need skilled IT management to manage that transition carefully. How can that make sense to anyone?  As MIT’s noted IT researcher Jeanne Ross pointed out recently, companies already tend, in terms of their systems, to “let everybody decide what’s most important for their part of the business. The usual result is a tangled mess of IT system architecture.”

The answer to this dilemma can’t be dispensing altogether with IT-specific leadership and hoping for the best. Dell CIO Robin Johnson wrote a piece last fall that described the pitfall of balkanized decision-making amid burgeoning complexity: Dell wanted to add a new payment type to its web site, but had different systems in every region, ten separate customer databases, etc. The estimate simply to add this one new type came in, staggeringly, at a year. Picture, then, pushing for a world where every line of business has made its own technology decisions, not just with no unifying presence of leadership, but with the avowed philosophy that IT leadership is actually no longer necessary at all. Scream with me, now.

Why the IT consumerization trend increases the need for skilled IT leadership

And the scale of such problems is increasing. Rather than IT consumerization consisting mostly of the identified BYOD dilemmas (which are important, of course), Bernard Golden points out, “Consumerization of IT isn’t about employees using consumer devices; it’s about consumers becoming the primary users of internal IT applications.” The ensuing greater volume and variety of application access, as consumers tap into what used to be internal IT systems from every conceivable device and geography and time zone, has huge implications for companies, their organization, their architectures. As we face this very real trend, and the resulting even greater requirements for system cohesiveness and robustness, it is hardly the time to opine that IT leaders are now extraneous.

Finally, let’s talk a bit about IT becoming a commodity. That’s nothing new. A company that had a great custom financial system used to (perhaps) have a competitive advantage, until such systems were commoditized by the advent of ERP. Commoditization of a technology means that that it can no longer provide much of a competitive advantage, other than through superior execution. But every time something gets commoditized, we are able to “move up the stack” in abstraction: we can now focus on reaping value from other, higher-order things that can’t (yet) be commoditized. If you’re using technology that’s available to everyone, off the rack, you have no differentiator, and no competitive advantage.

Pundits argue that since some key technologies are now a commodity, we no longer need a CIO to handle them. But I’d turn that argument around: that’s precisely when you do need a CIO, to rise above the commodity level and figure out how to leverage technology for competitive advantage and business value. And the way to do that means using something other than technology that’s available to everyone, just off the rack. You want a differentiator.

So, get rid of the CIO because some technologies have now become commodities? You might as well posit that since we now have drugstores, there’s really no need for doctors anymore.

Or with a different spin, there’s an old joke about a small child who observed brightly, “We don’t need the farmers anymore; we just go to the grocery store instead!” That’s a true-but-false statement if there ever was one. Ponder those two analogies, and consider how IT represents both the farmers and the doctors. And that the need won’t go away.

Lagniappe:

]]> http://www.peterkretzman.com/2012/03/14/it-consumerization-the-cloud-and-the-alleged-death-of-the-cio/feed/ 8 Novels of IT, Part 3: Adventures of an IT Leader http://www.peterkretzman.com/2012/01/31/novels-of-it-part-3-adventures-of-an-it-leader/?utm_source=rss&utm_medium=rss&utm_campaign=novels-of-it-part-3-adventures-of-an-it-leader http://www.peterkretzman.com/2012/01/31/novels-of-it-part-3-adventures-of-an-it-leader/#comments Tue, 31 Jan 2012 22:14:04 +0000 Peter Kretzman http://www.peterkretzman.com/?p=791



My long quest for an insightful, broad, and practically applicable “novel of IT” finally met with resounding success, once I got my hands on the outstanding book that is the subject of this post: Adventures of an IT Leader, by Robert D. Austin, Richard L. Nolan, and Shannon O’Donnell.

To recap: I was looking for a book that was both reasonably engaging as a novel and one that accurately portrayed a broad swath of the inner workings, nuances, and personality types that are typically part of the landscape of IT in today’s world. Reading the book should provide a window into common dilemmas and disagreements regarding IT issues, lending perspective and insight into all parties’ motivations and interests. See my earlier posts on Chris Potts’ FruITion and John Hughes’ Haunting the CEO.  Again, my views aside, I should emphasize that all three of these “novels of IT” are worth reading and forming your own opinion.

Adventures of an IT Leader comes by far the closest to meeting the criteria I had outlined for a “novel of IT.”  It opens with an executive, Jim Barton, being unexpectedly tapped as CIO by the new CEO of his firm, after long and successful stints managing other areas of the company.  In short, Barton isn’t an IT person by training or experience. In fact, one reason for his selection as the new CIO is that he has long been the foremost critic of the IT function at his company. And now, unexpectedly, he has to walk a few miles in IT’s moccasins, so to speak. The novel then follows Barton and his numerous IT challenges and crises for about a year.

Note that it doesn’t make sense for a novel (any novel, but especially a “novel of IT”) to be a how-to manual or a set of detailed instructions. It’s meant to be fiction, after all, not an O’Reilly cookbook. As a novel rather than a cookbook, the book should provide enhanced, realistic insight into personality types, situations, common dilemmas, trade-offs, etc. A great outcome of such a book, to my mind, is for it to portray common IT scenarios evenly enough so that the reader comes away thinking, “wow, that issue is not as clearcut as I’d always assumed; I’ll have to think about those nuances some more.”

This book excelled in that respect: without falling into the trap of loftily providing the “right answer”, the book depicts realistic situations and conversations (among well-drawn and not stereotypical characters in the novel) that surface the important nuances without pointing fingers of blame. As Barton struggles to understand his new milieu and ponders what actions he should take at the helm of IT, we see balanced, careful discussions of key IT concerns such as the following:

  • Why important IT infrastructure investment is often neglected;
  • How and why projects fall prey to scope creep and become “runaway”;
  • Why IT resources’ views and recommendations are often ignored, in favor of promises made by external vendors;
  • How technical complexity tends to increase over time, resulting in risks growing ever higher;
  • Why depending on ROI alone as a project selection criterion results in limitations for the business;
  • How issues can arise with developers working on their personal side projects even while major project deadlines loom, and why the answer on what to do about this isn’t obvious.

Readers see quickly that the authors’ goal isn’t to provide definitive answers on what precisely to do on any of these; instead, the lines of the pro and con arguments emerge naturally in each case as Barton wrestles with it, and the reader comes away realizing that the answer, any answer, will necessarily involve trade-offs, risks, downsides. Running IT often consists of placing bets, as it were, not determining the “one true path” that is the right answer. Even the chapter-ending “Reflection” sections provide genuine and thoughtful open-ended discussion questions, not framed with a predetermined agenda. The book would work well as a set of case studies for group discussion, in fact.

The reader comes away realizing that the answer, any answer, will necessarily involve trade-offs, risks, downsides.

As with any CIO, not all of the decisions that Barton makes (or the ones that he inherits) turn out to be successful bets as events transpire. In fact, the company is thrown into crisis when a production outage occurs, due in part to a security update that had been de-prioritized. How Barton deals with that crisis and the ensuing fallout is one of the most compelling aspects of the novel.

The epilogue of the book, looking back on its incidents, provides an especially cogent summary of a truth often missed by people who haven’t themselves worn the shoes of IT management: essentially, that much of the devil is in managing the nuances, the day-to-day seemingly trivial details.  The authors observe, “The lack of effective IT management decision-making on the mundane issues will eventually lead to spectacular and seriously negative consequences.” Note how that’s a far cry from (and a much wiser perspective than) the stance taken in FruITion, which argues that the IT function has become so trivial as to not need an executive at all.

This book isn’t perfect of course, and I have a few quibbles with it: the patchwork nature of its organization at times, for example, or the ease with which Barton generally succeeds despite his rookie nature; however, more than any other “novel of IT” I’ve encountered, it is extraordinarily even-keeled and insightful on the key issues surrounding IT and IT’s role within companies. It explodes stereotypes rather than reinforcing them; it serves up genuine insight and understanding rather than pat solutions. As such, of the three novels I set out to review, it best fulfills one of my criteria: I’d be eager to recommend it to my CEO, or to anyone who works closely with IT.

Lagniappe: 
]]> http://www.peterkretzman.com/2012/01/31/novels-of-it-part-3-adventures-of-an-it-leader/feed/ 1 IT anti-patterns: reverse behavior lessons from Steve Jobs http://www.peterkretzman.com/2011/12/02/it-anti-patterns-reverse-behavior-lessons-from-steve-jobs/?utm_source=rss&utm_medium=rss&utm_campaign=it-anti-patterns-reverse-behavior-lessons-from-steve-jobs http://www.peterkretzman.com/2011/12/02/it-anti-patterns-reverse-behavior-lessons-from-steve-jobs/#comments Fri, 02 Dec 2011 23:51:09 +0000 Peter Kretzman http://www.peterkretzman.com/?p=763



I’ve written before about how I value Twitter’s ability to fine-tune one’s personal information gathering, selecting people to follow who, over time, prove to be the most useful, interesting, and stimulating. I commonly refer to the people I follow as my “personal Algonquin Round Table,” in homage to the well-known literary group of the 1920s.

More simply put, though: I value Twitter because I fundamentally believe in consulting others, picking their brains, observing what they find useful or funny, enjoying their (often differing) perspectives, and learning as much as I can from them.

To my frequent surprise, however, this basic belief in the value of consulting others turns out not to be universally shared. In fact, it can even be scoffed at. That disconnect came glaringly to light recently in the aftermath of the death of Steve Jobs. Basically put, the burgeoning legend of Steve Jobs rests in large part on how, in his path to multiple successes, he fundamentally rejected the value of consulting others.

Particularly in the days immediately following Jobs’ death, an incredible spate of adulatory articles and posts emerged, lauding this legendary refusal to compromise (“Machines and robots were painted and repainted as he compulsively revised his color scheme” ), his attention to the most minute of design and implementation details, his insistence on molding every aspect of his company’s products and culture.  It was widely quoted how he scoffed at the idea of focus groups and obtaining user feedback:

“Some people say, ‘Give the customers what they want.’ But that’s not my approach. Our job is to figure out what they’re going to want before they do.”

I then noticed how the seemingly universal trend towards Jobsian hagiography became part of various unrelated discussions.  When it came to anything related to being detail-oriented or on the wisdom or folly of consulting others to help determine one’s decision on a matter, Steve Jobs loomed implicitly or explicitly over the conversation. Discussing how IT managers need to move away from sheer focus on detail? “Yeah, but what about Steve Jobs?” came the retort. Talking about the importance of understanding one’s customers’ needs?  “Yeah, but what about Steve Jobs?”

With all due respect to Steve Jobs, who was an unfathomably brilliant, influential, ground-breaking disruptor of not just one but arguably six major industries, attempting to mimic his success simply by adopting his specific behavior is a horrible idea, and in particular a grave danger when it comes to IT. In fact, his behavior exemplified at least two IT anti-patterns, and here’s why.

Attempting to mimic Steve Jobs’ success simply by adopting his specific behavior is a horrible idea.

IT, as I’ve noted before, is frequently accused (and often guilty) of ignoring its customers, and proceeding down the path that we think is ideal. In fact, that’s the single most common complaint I hear when doing high-level IT consulting, and I typically hear it in spades and high frustration from the business peers of the IT leader (CIO/CTO), not to mention the CEO.

Similarly, IT leaders, having emerged (often) from the ranks of the highly technical, can be notoriously reluctant to relinquish diving into the details: if they’re not still logging into systems, tweaking code and configurations, or examining stack traces, many IT leaders can feel as if their edge is slipping away. At its most extreme, this syndrome means they can’t let go of any detail, however small. Example: when I opined on Twitter that successful IT management meant having to leave a lot of the details behind and embrace a certain level of ambiguity, at least one respondent told me flat-out that such ambiguity was unacceptable, and that IT leaders “need to know the details in order to make informed decisions”.

So the snowballing legend of Steve Jobs bolstered both of these IT anti-patterns, unfortunately:

  • Don’t consult others as you design or tweak your products? At its worst, I’ve seen IT people embrace that notion in full hubris, and even reject polling users about system requirements: we already know what they need, after all, far better than they do. And the frequent result is (and we’ve all seen this happen) a system gets launched that users reject instantly, because it doesn’t fill their needs. Our instincts, for most of us, are anything but Jobsian.
  • Stay on top of all technical detail as an IT leader? In any but a very limited arena, that’s simply a recipe for leadership failure. Leaders are there to handle the “big picture” issues, the politics, the prioritization. It doesn’t matter what your skill level or degree of experience with technology is; when you focus on the big picture items, any reasonably large and complex environment will quickly outstrip your ability to keep up on the technical details, and sooner or later, you’re going to have to rely on your people to handle those details promptly and correctly.  Here again, legend outstrips reality: Jobs (of course) didn’t stay on top of every technical detail; he picked the ones that mattered to him, and over time, proved to be right in his instincts more often than not.

Let’s remember that Jobs was an outlier. Citing him as a role model for all business decision-makers needs to take that into account. You might as well cite the musician who’s never taken a lesson and can’t read music, the orator who never rehearses his speech, the athlete who doesn’t practice, the writer who never does rough drafts. Those outliers exist, are noteworthy and even admirable, but they’re not something to directly aspire to.

So the lessons from Steve Jobs can be taken way too far, especially in IT. People can start to think that all it takes to mirror Jobs’ success is to insist on having things your way, go with your own instincts, watch every detail no matter how small, and dismiss the notion of seeking out customer input. Unfortunately, for every Jobs out there with magical instincts about what will work and a track record to prove it, there are thousands of us lesser souls creating products without such infallible insight into what customers really need. We actually, gasp, have to ask them.

]]> http://www.peterkretzman.com/2011/12/02/it-anti-patterns-reverse-behavior-lessons-from-steve-jobs/feed/ 2 A CIO’s skeptical look at the QR code phenomenon http://www.peterkretzman.com/2011/07/13/a-cios-skeptical-look-at-the-qr-code-phenomenon/?utm_source=rss&utm_medium=rss&utm_campaign=a-cios-skeptical-look-at-the-qr-code-phenomenon http://www.peterkretzman.com/2011/07/13/a-cios-skeptical-look-at-the-qr-code-phenomenon/#comments Wed, 13 Jul 2011 23:30:29 +0000 Peter Kretzman http://www.peterkretzman.com/?p=692



I had the good fortune last month to be invited to participate as a guest CIO on ITSM Weekly, a great IT-related podcast with the amusing ongoing tagline, “What happens when a CIO, a Service Desk Manager and an industry junkie chat weekly?!”

Amidst the discussion and banter, Chris Dancy of ITSM Weekly gave me a bit of a ribbing about what he perceived as my all-too-common anti-QR-code rants on Twitter. And yes, I have tweeted more than once with outright skepticism about the usefulness and likely impact of QR codes.  Chris’ good-natured needling made me step back and think about why: what exactly makes me so resistant to the notion of QR codes?

And the answer runs deeper than just QR codes per se.  It turns out, as I thought about it, that the story surrounding QR codes represents, for the modern CIO or CTO, kind of a horrible blend: the worst aspects of technology advocacy, combined with the worst aspects of marketing.  This post is an attempt to explain those broader implications.

For those (probably many) of you who don’t really know what QR codes are, look at the upper right of this post to see an example: they’re a two-dimensional barcode of sorts, typically consisting of black modules arranged in a square pattern on a white background.  QR codes can encode all sorts of information: text, a URL, or other data, and they are typically read/decoded by smartphone applications that are readily and freely available on most mobile platforms.

QR code enthusiasts envision people walking up (for example) to the door of a restaurant, using their smartphone to scan the code displayed in the window, and, well, getting any number of potential outcomes on their screen: a menu, a coupon, a URL, a pointer to a video about the place’s history, etc. In fact, in some countries like Japan, QR codes are everywhere, used for these and many other business situations.

From a technical point of view, it’s indeed really cool that this Rorschach-worthy splotch can be instantly converted to text or other information. Depending on the specific format (yes, there are several divergent standards) and on the nature of the content, as many as 4,296 alphanumeric characters can be contained in one of those splotches. That corresponds to roughly 700 words, or almost three typical pages of ordinary text. That’s a lot of information available at a smartphone glance, so to speak.

So what’s my beef with all that? What’s not to like? Two aspects particularly rankle me as an IT executive:

  • It smacks of technology for technology’s sake. Most great CIOs I’ve known have spent a lot of their career pushing back against being typecast as a mere technologist; most of them recognized early on that the way one adds value to a company as a technologist is to get deeply steeped in the business ins and outs, especially customer and financial aspects, and to apply technology appropriately, not just because it’s “cool.”

So sure, QR codes are “really cool” technologically. But are the business use cases really there? Will customers, in numbers, actually go the extra mile of seeing that splotch and feeling motivated enough to pull out their phone and scan it? Personally, I’m an early adopter of and avid experimenter with new technologies (especially when they’re free and widely hyped, as is the case here), but I have scanned fewer than ten QR codes ever. For many advocates, I fear that the coolness (and granted, the potential) of the technology is making them overestimate the probable acceptance of that technology by the masses.

  • Excessive hype.  Aside from applying a basic “sniff test” to the breathless, even giddy posts pertaining to QR codes, I’ve noticed that many such posts and even press releases quote surveys and reports on the supposedly major acceleration in QR code penetration here in the US. (Sample purple prose in one such report: “QR barcode use has suddenly gone ballistic.”)

The surveys themselves, and the reports based on data taken from those surveys, are visibly flawed.

If you dig into these posts and reports, it turns out nearly all the data cited stems from a mere handful of companies (ScanLife, JumpScan, and Mobio Technologies, Inc.), all of whom, wait for it, just happen to market QR-code related products! Can you say “conflict of interest”?

Moreover, the surveys themselves, and the reports based on data taken from those surveys, are visibly flawed, chock-full of statistical and methodological red flags:

    • the reports almost invariably feature graphs that lack Y axis labels, or that are labeled (for example) as “no scale given; relative measure only.”
    • The reports often combine data for all bar code scans (including UPC (conventional) barcodes, which are of course a far more plausible and prevalent use case, due to the abundant comparison-shopping apps that people use in bookstores etc.), and then use that data to infer QR code usage. One survey evidently asked the general question, “Have you ever used a barcode scanning application?” And the data then obtained from the answers to that general question now leads QR code advocates to conclude (erroneously) that “while QR codes aren’t mainstream yet, they’re past the early adopter phase.”
    • There’s seldom an attempt made to take into account one key factor in the increase in barcode scanning: the meteoric rise in smartphone penetration overall. A rising tide lifts all boats, and even if we’re seeing an increase in QR code scanning, that needs to be taken in the context of millions more smartphones being sold per month.

Finally, in a particularly delicious example that Darrell Huff would be amused by, ScanLife shows a graph comparing 1D (conventional) barcode scans with 2D (QR code) scans, favorably to QR codes, of course. Well, read the fine print under that graph: “Note: 2D traffic includes 3rd party apps while 1D traffic is only sourced from the ScanLife app”. Apples are being compared to oranges here, in other words. Vested interest. When data is presented in so obviously skewed a fashion, by people with a clear commercial agenda, one has to wonder whether it’s really all part of a sales job.

And the reports also don’t even begin to address a potential major factor when examining such data at this stage: what percentage of people scanning QR codes are doing so right now simply out of the sheer novelty of it all? As Steve Smith observed, “we are still in the gee-whiz stage of 2D codes”. Will this phenomenon have legs, so to speak?

So let me recap my main concerns about the QR bandwagon:

  • Even relatively widespread adoption (which QR codes have yet to see, of course) of a great new technology by technophiles doesn’t guarantee eventual deep penetration to the mass market. That should be obvious to anyone who isn’t running a Linux box for their desktop.
  • Will a critical mass of non-technical people (say, those who couldn’t manage to set the time on their VCRs back in the 80s and 90s) really tend to whip out their smartphone and scan QR codes in profusion? Maybe, but right now it’s just a matter of opinion.
  • Will there ever be enough “bang for the buck” with QR codes (i.e., investment of time/money versus benefit obtained from using them)? Even as an early adopter, I’ve scanned fewer than 10 QR codes ever, because there was never sufficient payback for my effort. And for the retailer or marketer: will QR codes really pull more people in the door, or is it just another gimmick? Where’s the data? (the real data, that is). Even in museums (one plausible use case mentioned for QR codes), I can envision only the highly motivated museum-goer as likely to indulge in QR code scanning.  It’s technology for a very narrow slice of the audience. It may be worth doing for that slice, sure, but let’s not go overboard in our excitement or our investment.

Back in the late 90s, several companies invested millions of dollars promoting what amounts to an earlier version of this scheme: specialized barcodes published in magazine ads, designed to be read by a “CueCat” scanner which they distributed broadly, for free, to people like Radio Shack customers and Wired magazine subscribers.  It failed miserably. In December 2009, the popular gadget blog Gizmodo even voted the CueCat the #1 worst invention of the “2000s” decade.  Yes, now we have smartphones and don’t need to obtain special equipment, so that gives QR codes an advantage that CueCat didn’t have. But still, it gives me pause that QR codes are being promoted with much the same zeal, and perhaps with similar blinders as to the true practicality of the technology. It’s déjà vu all over again: endless hype, plus technology pursued without solid practical reasons to do so: these are, and deserve to be, twin bugaboos for any technology executive.

And that’s why I express skepticism about QR codes on Twitter.

Lagniappe:

Opinion:

“Data”:

]]> http://www.peterkretzman.com/2011/07/13/a-cios-skeptical-look-at-the-qr-code-phenomenon/feed/ 8 Novels of IT, Part 2: Haunting the CEO http://www.peterkretzman.com/2011/07/04/novels-of-it-part-2-haunting-the-ceo/?utm_source=rss&utm_medium=rss&utm_campaign=novels-of-it-part-2-haunting-the-ceo http://www.peterkretzman.com/2011/07/04/novels-of-it-part-2-haunting-the-ceo/#comments Tue, 05 Jul 2011 05:05:50 +0000 Peter Kretzman http://www.peterkretzman.com/?p=619



Last time, I introduced this series by pointing out that reading what I call “novels of IT” could serve a few very useful purposes for those of us who work in and around information technology.  In fact, I presented a number of criteria that come to mind when answering the implicit question of why anyone should bother to read a novel of IT.

Ideally, it’s because such novels, at their best, can do the following:

  • provide a degree of engagement and entertainment in making their points
  • provide a realistic insight, in a “show not tell” kind of way, into what motivates the typical players in these business scenarios,
  • help all factions (inside and outside IT) come to see the other side’s perspective and arrive at deeper understandings of common problems and disagreements.
  • allow the CIO to hand the novel to his or her CEO or CFO and trust that everyone’s reading of it will help reach common ground in how to collectively and collaboratively approach the company’s goals.
There are, of course, pitfalls involved in constructing such a novel, the foremost of which is falling into blatant stereotypes: most notably, the nerdy CIO who clings to technology and can’t see a larger role for himself or herself. The book I covered in my first post on IT novels, Chris Potts’ FruITion, not only fell into this trap in spades, but took it to a whole new dimension, painting IT in general as basically no longer needed as a separate discipline, and as having become so trivial as to not need an executive at all.
This time, I’ll discuss John Hughes’ recent and excellent contribution to this genre, Haunting the CEO.

Haunting the CEO is a slim, readable novel that depicts a CIO, Brian, who is faced with a new CEO, Jim, who wants to make changes in order to turn around the company’s declining results.  Jim tells Brian that he expects IT to drive business growth and profitability, as well as innovation.  He keeps Brian on, provisionally, while telling him in no uncertain terms that he needs to see action and results sooner rather than later. But Brian is a techie, through and through, and doesn’t really have an inkling of how to begin.

Enter Carol, Jim’s CIO from his previous company, who has agreed at Jim’s request to serve as informal volunteer mentor to Brian.  As they meet over coffee and lunches, she walks Brian through examining his current practices and IT staff, challenges his thinking, and ultimately helps him both to achieve greater insight into what he needs to change in his own behavior as a leader, and to take concrete action to turn around IT in general at the company.

You can tell this novel was written by someone who’s been there, done that.

This novel of IT distinguishes itself enormously from FruITion in particular in one main way: you can tell it was written by someone who’s been there, done that, rather than delivering an abstract solution from on high.  John Hughes’ foreword directly admits as much: discussing his 30-year career, he writes, “my mistakes are woven throughout the stories, characters and events you’re about to immerse yourself in.”  True to one of the core leadership traits he espouses in the book, humility, the author’s own words here foreshadow CIO Brian’s own path to learning what he needs to change and leave behind (in himself and in his staff) as he turns around IT for the greater benefit of the company.

Haunting the CEO is filled with small and large insights about leadership in general, and IT leadership in particular.  As with other small business books with great wisdom (Kenneth Blanchard’s The One Minute Manager comes to mind), it’s easy to pick on its occasional oversimplification of complex issues, or to quibble about the vagueness of the necessary steps to follow in order to echo Brian’s success.  But above all, the book reasonably and accurately depicts, in broad brush ways, the necessary “mental transformation” (to use its own words) required for an entrenched technologist to become a true business leader.

Personally, I would have preferred that the book show much more of Brian’s changed interactions with his business peers, and would point out the unfortunate aspect that in the end, the changes Brian effects appear to come mostly through his firing of about 10% of his IT staff.  For that reason and more, I’d be a little leery of whether this book fulfills the criterion I established up front: wanting to be able to hand this book to my CEO so that he or she can get deeper insight into IT and its interrelationships with the rest of the business.  The danger behind doing that with Haunting the CEO is that the standard image it paints of the CIO as the entrenched technologist is fading, so to some degree the book may be making points that reinforce and thus risk perpetuating a near-obsolete (and damaging) stereotype.

All that said, this is a fine novel of IT, and well worth the time spent reading it and absorbing its many lessons.

Next time, I’ll talk about the last of the three novels of IT on my initial list, Adventures of an IT Leader, by Robert D. Austin, Richard L. Nolan, and Shannon O’Donnell.

Lagniappe:

]]> http://www.peterkretzman.com/2011/07/04/novels-of-it-part-2-haunting-the-ceo/feed/ 1 Novels of IT, Part 1: Turtles All The Way Down http://www.peterkretzman.com/2011/06/16/novels-of-it-part-1-turtles-all-the-way-down/?utm_source=rss&utm_medium=rss&utm_campaign=novels-of-it-part-1-turtles-all-the-way-down http://www.peterkretzman.com/2011/06/16/novels-of-it-part-1-turtles-all-the-way-down/#comments Thu, 16 Jun 2011 20:11:55 +0000 Peter Kretzman http://www.peterkretzman.com/?p=598



Novels are harder than most technology-oriented people typically realize. The backbone of a good novel is character development, meaning that the character learns and grows — which makes it easy for especially amateur novelists to start off with a character who is, frankly, little more than a one-dimensional dolt. This is an even more dangerous pitfall when it’s a “novel of IT”: the temptation is almost unavoidable for the author to create as protagonist a stereotypical technology leader, clueless as to what is really important or how to be effective, who is then gradually enlightened by wiser individuals as the novel progresses.

There are three IT-related novels I’m aware of, all relatively recent, that fall essentially along those lines.

All of them are worth reading, but I had majorly different reactions to each. While I’d intended to cover all three in one blog post, the complexities involved in discussing the first, very problematic example have led me to divide this discussion into more than one post.

Not everyone is a fan of fiction, though: why read any of these novels? In my view, the veneer of fiction, of semi-realistic dialog and interaction among the typical players in business-IT situations, promises a degree of engagement and entertainment, as well as the chance to obtain a deeper understanding of how and why the involved parties interact they way they do. Ultimately, I’d want such a book to provide me with insight, in a “show not tell” kind of way, into what motivates the typical players in these business scenarios, and to depict a healthy growth of character and role that lets me understand my own situation and how better to foster collaboration, synergy, and business effectiveness. Beyond the superficial, the events of a novel and the utterances and interactions of its characters can eloquently illustrate various approaches and philosophies, often more forcefully and meaningfully than would a straightforward treatise.

As a CIO, I’d want to be able to hand the novel to my CEO or CFO.

In fact, a fundamental purpose of quality fiction is to enable the reader to live and understand another perspective. So primarily, I would want such a “novel of IT” to help all factions (inside and outside IT) come to see the other side’s perspective and arrive at deeper understandings of common problems and disagreements. Otherwise, it’s sheer polemics. As a CIO, I’d want to be able to hand the novel to my CEO or CFO and have everyone’s reading of it help us find common ground in how we approach our goals.

(One small aside: before I begin, I should note that none of the novels I’m going to cover can compete, as artful fiction per se, with what I consider to be the best IT-related novel: Ellen Ullman’s The Bug. Unlike the three novels I will cover fully, The Bug is intended primarily as art, not as a fictionalized essay designed to make points about how to run IT. Highly recommended.)

Let’s start with FruITion, by Chris D. Potts.

This book, which has been generally praised, depicts itself as essentially contrarian, as describing “what happens when corporate strategists decide to ignore all the IT strategy orthodoxies.” It’s meant to reveal “indispensable messages about the next generation of strategies for information technology,” as one of the blurbs on the back has it. The key distinguishing feature of the book, arguably even underscored by the implications of the photo on the cover, is that it’s intended to turn the conventional view of IT on end.

Well, I’m going to be a contrarian to the contrarian. Simply put, I think the fundamental thrust of the book is wrong-headed, divisive, lofty, unnecessarily diminishing of the importance of the role that IT plays in a business, and ultimately not helping disagreeing factions find common ground, or showing useful ways that IT can truly provide value to business.

As Twain famously said, history may not repeat itself all the time, but it sure does rhyme a lot. Or, as Yogi Berra said, “you can observe a lot just by watching”. Or, in Potts’ own words, “the language you use is taken as evidence of your mindset.” And, just by carefully watching the interactions and language in FruITion, my unavoidable observation is that Potts’ mindset is particularly, astonishingly, and blatantly ill-disposed towards IT.

Ian, the protagonist and first-person narrator and CIO, is a straw-man-stereotype kind of IT person. He’s tentative, focused on technology, set in his ways, reactive, defensive, a bit paranoid. Conversely, the novel presents the non-IT executives (the CEO and her delegates) as wise, fast-thinking, and a bit mysterious in their uncanny insights into what’s not working. They’re a little inscrutable, and more than a little threatening: Ian is constantly fretting about whether he’s about to be sacked, and the strategists are constantly making subtle and not-so-subtle references as to whether or not he’s “getting it” and whether he’ll even be around for the next go-round.

It’s “us vs. them,” in other words, in spades. Ironically, one character, presented as particularly insightful, is introduced positively as being “fed up with the ‘us and them” and ‘we know best’ attitudes of some IT people towards the rest of the company.”

Yet IT is presented mainly in the negative (indeed, with disdain) at every turn.

Yet IT is presented mainly in the negative (indeed, with disdain) at every turn, characterized repeatedly and triumphantly as “delivering no value on its own”, and it’s emphasized that “no one values what IT does.” Everyone else in the novel sees things clearly except for the IT people, who “execute their strategies at arms length from everyone else rather than by collaborating.” In one characteristically heavy-handed moment in the novel, Ian’s “IT Strategy Manager” views with excitement the chance to participate in a key software vendor’s new beta release: “It could change our whole strategy,” he enthuses, not realizing how narrow that statement shows his notion of strategy to be.

Face it, we’ve all known people in IT that exhibit those small-picture tendencies. But I don’t believe that it’s useful or accurate, in this day and age, to trot out such stereotypes and thereby blast the entire discipline. One “strategic” character in the book even tells Ian, “we want you to break loose, join the gang, help us turn the tables on those bastards in IT.” In the end, Ian escapes (ascends?) into this strategic realm, away from IT, but all the future pesky technical decisions are then relegated to a Technical Services Manager whom they elevate to “CTO,” and whose stated job it is “to get the IT we wanted to use delivered reliably well, economically, at an acceptable level of risk, and with economies of scale and synergies. Nothing else.” Simple, eh? (Note the amusing similarity of this new “CTO” role to what the role of the CIO was also thought to be, way back when. As the old joke has it: from here, it’s “turtles all the way down”).

In essence, it’s “technology bad, strategy good”: this novel presents an overly simplified, frankly offensive, and ultimately detrimental dichotomy. The book seems, quite intentionally, to consider current-day IT as a mere exercise in procurement: “All in all, our people now know enough about IT and how to use it not to need an executive to make those decisions for us. All we really need is someone who can source the IT services we want to use.” Really? We know what we want; IT just needs to get it for us. Order takers. How many years/decades ago did we all collectively figure out that that’s a counterproductive approach?

In short, if there’s any book that actually fosters the “us vs. them” rift that’s too often characteristic of how IT fits into a company, this would be it. It’s simplistic, dismissive, lofty, and ivory-towerish; in the end, despite its contrarian nature, it delivers next to no new practical insights. And one sad aspect of its dismissive nature: those who point out its failings will almost certainly be accused by its proponents of “not getting it.” (Witness this review of Chris Potts’ interview with Claudia Imhoff). I think I “get it” quite clearly, though, and I simply reject it as misguided, naive, and ultimately counterproductive to the needs of a modern organization.

Next up: two more novels of IT that I believe show a (much) more even-handed, useful, and insightful approach.

Lagniappe:

]]> http://www.peterkretzman.com/2011/06/16/novels-of-it-part-1-turtles-all-the-way-down/feed/ 5 Three IT behavior patterns seen in the wild http://www.peterkretzman.com/2011/01/27/three-it-behavior-patterns-seen-in-the-wild/?utm_source=rss&utm_medium=rss&utm_campaign=three-it-behavior-patterns-seen-in-the-wild http://www.peterkretzman.com/2011/01/27/three-it-behavior-patterns-seen-in-the-wild/#comments Fri, 28 Jan 2011 06:36:29 +0000 Peter Kretzman http://www.peterkretzman.com/?p=564



Assumed Omniscience, Chooser’s Remorse, and Fixation

With all due respect to the many fine folks I’ve worked with in the career I’ve spent decades pursuing: we IT types can be an idiosyncratic, even odd, bunch.  That’s actually well known to us all, and it generally makes great fodder for this blog.

I find the sociology of the profession—how people interact with one another—as fascinating as everything else about it.  Here are three interesting behavioral syndromes I’ve observed over the many years of IT projects and teams I’ve been a part of. And as with most of my observations of this nature, I’m not presenting them from “on high”: no, I’ve been at times as susceptible to these behaviors as anyone. They’re common, and easy to fall into, but all of them are things I strive to avoid. And all of them have a common thread, as you will see.

First: Assumed Omniscience
I’ve retitled the standard name for this syndrome: the usual term for it is actually “Male Answer Syndrome”, which UrbanDictionary.com defines as “the tendency, especially among males, to make educated (?) guesses about subjects and present them as fact.” Well, in my experience among IT professionals, it’s hardly limited to males. It’s unfortunately common for many IT people, of either gender, to venture assured-sounding explanations based on little more than a desire to appear knowledgeable. I remember early in my career hearing one peer explain, with no factual basis for his theory, why his document hadn’t come off the printer yet: “That printer is obviously getting a lot of erroneous packet hits lately.”

Whether it’s a suddenly contrived explanation of why something isn’t working or the delivery of a detailed but basically invented treatise on the technical underpinnings of a new device, it seems that it’s easy to find people in IT who just don’t like to use the phrase, “I don’t know.”  Or even to couch it as, “here’s one possible theory.”  Instead, out comes a categorical statement of “here’s what explains this.”  Assumed Omniscience. As a peer, or especially as a manager of people who are subject to this syndrome, it’s important to be wary of this. It never hurts to constantly reinforce that the work culture needs to be one where facts reign, and where theories are clearly identified as such.

Second: Chooser’s Remorse
In business in general, not to mention frequently in the case of IT, it seems that we often encounter situations where there is no ideal solution.  After copious brainstorming, the group wrestling with such a situation usually figures out several different approaches to the problem, and debates these at length, carefully identifying pros and cons.  Each of the identified solutions has definite downsides, usually; none is obviously superior and thus the clear approach to choose. Each approach has its adherents and detractors among the group of influencers / decision-makers. All this is normal, and common.

But of course, the choice among these alternatives needs to be made eventually, and when it is, what often happens? The very people who participated in the selection proceed to complain loudly and incessantly about the downsides of the chosen alternative. Chooser’s Remorse, I call it. And yes, this occurs despite the group having (supposedly) picked the least onerous or distasteful of the several possibilities, and despite going through endless discussion of all of them prior to the selection.  Instead of people remembering that the choice represented the “least bad” alternative, they turn and harp about how awful it is.

And, just as the Assumed Omniscience syndrome isn’t limited to males, Chooser’s Remorse isn’t limited to IT people.  We all do it. Perhaps it’s human nature, and perhaps it just comes out extra often in IT circles because of having to make frequent tough choices among not-so-great alternatives.

I’ve found it useful to remind people, as the choice of the “least awful among the bad alternatives” is made, that we’ve identified its downsides and are choosing it anyway.  And that whining about the downsides later will be both ridiculous and counter-productive. Let facts prevail over emotion.

Third: Fixation
According to historical sources, a Roman statesman named Cato The Elder became known for ending every single one of his speeches, no matter what the subject, with some variation of the phrase “Carthago delenda est”: “Carthage must be destroyed”.

And this relates to IT, um, how?  Well, I’ve seen exactly this sort of fixation appear in our world time and again. Whether it’s a zealous advocacy of a particular development methodology, a vocal fanboyism towards this or that vendor, or an unwavering devotion to a language or technology over all others: all of these affect people’s business judgment and undermine a necessary professional impartiality.  No matter what the topic of discussion in a meeting, I’ve seen such fixations crop up, via sudden declarations not much different in nature to inserting a sudden and unrelated “Carthago delenda est” into one’s casual remarks.

I was a new VP of IT once for a group that experienced a great success with a software rollout shortly after my arrival. I proposed to my operations manager that we have a team outing to Starbucks to celebrate. (Yes, call me a party animal). “Oh, no,” he said. “My guys won’t go to Starbucks.”  Hmm, I said. They don’t like Starbucks’ coffee? “No,” he explained.  “Starbucks announced a big corporate deal with Microsoft recently, and my team won’t have anything to do with Microsoft.”  Fixation.  Emotion reigning over facts, once again.

We all bring our biases and predilections to work with us every day, but all of us can work on purposefully leaving these behind as much as we can, and, again, letting facts rule the day. Other than a healthy drive towards high quality work, and integrity and kindness in our interactions with others, we should allow nothing to become a fixation for us.

There you have it: three syndromes, three IT behavior patterns seen in the wild.  Any of them sound familiar to you, too?
]]> http://www.peterkretzman.com/2011/01/27/three-it-behavior-patterns-seen-in-the-wild/feed/ 7 Can a CIO be successful without IT experience? Define your terms! http://www.peterkretzman.com/2011/01/16/can-a-cio-be-successful-without-it-experience-define-your-terms/?utm_source=rss&utm_medium=rss&utm_campaign=can-a-cio-be-successful-without-it-experience-define-your-terms http://www.peterkretzman.com/2011/01/16/can-a-cio-be-successful-without-it-experience-define-your-terms/#comments Mon, 17 Jan 2011 06:44:19 +0000 Peter Kretzman http://www.peterkretzman.com/?p=548



Yes, it’s déjà vu: certain topics crop up again and again on IT-related blogs. The age-old question: does a CIO really need to have IT experience?  I’ve touched upon this before, here and here, but it’s time for a full column covering the standard arguments posed in this debate.

I’ve gone through every article I can find on this topic (most of these are listed at the end of this post), read all the associated comments, and culled out the arguments that are typically cited in support of a CIO’s ability to be successful without IT experience. These are:

  • A non-technical CIO can surround himself with a capable team who can support him in all technical matters
  • It’s the ability to lead that’s really needed, whereby the issue of technical capabilities becomes secondary
  • After all, there are some successful business CIOs without technical background
  • Even supremely technical CIOs have been known to fail
  • Considering today’s rapid pace of change, past IT experience can be a hindrance to many CIOs today as often as it is a help: that experience can make a CIO “unduly resistant to the possibilities.”

As I looked at these arguments, though, I found them all strangely uncompelling. I felt truly puzzled: how could anyone argue vehemently in favor of a lack of experience as a job qualifier, for anything? But as I thought about it, I realized it’s a matter of basic definitions. As in so many debates, this topic has been seriously hampered by many parties failing to define clearly the basic terms: what does “IT experience” or “technical” mean, and what does it mean for a CIO to “be successful”? Without a clear and common understanding of what is meant by those phrases, advocates on both sides tend to drift into “straw man” postulates, where they reach a strong and usually quite self-righteous position based on divergent definitions.

Let’s look at what could be meant by “does a CIO need IT experience”, or, as it’s sometimes phrased, “does a CIO need to have a technical background.” These two things are usually conflated, but they are not the same. “Technical background” seems to usually mean academic qualifications: e.g., a Ph.D. in computer science, or at the very least, deep, low-level understanding of bits, bytes, protocols, APIs, etc.  “IT experience”, on the other hand, may be garnered through years of working on either the development or operations side of information technology, and may have involved relatively little purely technical activity. It’s easy for any given individual to have a great deal of one and not the other. But it should be noted that having more of the first (technical skills) doesn’t substantially improve your ability to cope with CIO-level issues, while having more of the other (IT experience) most certainly does.

What about the notion of a CIO being “successful”? What does that mean? Length of tenure in the position (not getting fired)? That seems like a dubious yardstick. Almost any industry veteran is aware of instances where highly competent CIOs have been let go due to political shifts within a company (e.g., advent of a new CEO), or retained for similar reasons despite questionable performance. Does it mean, perhaps, having measurable achievements? These too often depend on perceptions and political whims: a CIO can, for example, “successfully” roll out a system which works exactly as designed but fails to deliver hoped-for benefits.

A more meaningful definition of success, to my mind, is when a CIO can mobilize both his team and the company at large to obtain measurable value from the investments it is making in technology, and, moreover, gets that team demonstrably exercising continuous improvement in its processes and products. CIO success is not just about sticking around in the position; it’s not just about rolling out systems and supporting an infrastructure. It’s the impact on company results that matters.

If a given debate on a CIO’s necessary background assumes one set of definitions for these key facets, it’s easy to have the resulting arguments and conclusions dismissed out of hand by people who hold different definitions. And often, participants in the debate don’t even recognize the root of their disagreement: that they’re using the same terms for quite different situations.  In reality, they may agree more than they differ.

A CIO must have a good amount of IT experience (not necessarily specific technical skills) to be successful.

So using the definitions that I think are meaningful, as outlined above, my answer is that a CIO must have a good amount of IT experience (not necessarily specific technical skills) to be successful. (Note that citing that there exist occasional anecdotal exceptions to this, aside from depending on a usually unprovided definition of “success”, may be interesting but isn’t necessarily useful; Steve Jobs and Bill Gates both dropped out of college and still achieved prominence and prosperity, but they’re not examples one would logically use to formulate a general rule about the path to becoming CEO of a multi-billion dollar corporation).

Being a CTO/CIO is not about technology — I’ve stated that consistently, starting with my very first blog post. It is, however, about leadership and experience. The notion of an individual able to provide outstanding leadership but lacking a solid foundation of related experience doesn’t fly well in any situation or arena I’ve ever seen. Time and again, I’ve gone into turnaround situations at companies where IT matters have been completely bungled by having no CTO/CIO or otherwise inexperienced IT decision-making.  Bart Perkins’ recent excellent piece points out numerous specifics of what happens when there’s no CIO at all: business unit-centric decisions, standardization impasse, lack of new enterprise applications due to business unit parochialism, factionalism, and decreased economies of scale. I’d extend that: many if not all of those same situations tend to occur even with a CIO on board, if that person is inexperienced and thus unaware of these IT-specific pitfalls.

So again, my answer: to be a good CIO you don’t need to know, necessarily or specifically, what a left outer join is, or be able to reel off the seven layers of the OSI network protocol stack. You don’t need to know, necessarily or specifically, the difference between Java and JavaScript or to be able to have your way in either vi or emacs.  But, you’d better understand deeply the basic roles that IT elements play, how processes fit together to provide business value, and where the pitfalls may lie as your team goes about that fitting together.  You’d better be in position not to be easily swayed by a slick vendor or even a convincing pitch from one of your senior lieutenants; part of your job is to know when to push back. And that judgment comes from experience, not from some innate abstract leadership ability alone.

After all, IT changes radically every few years, and specific technical knowledge is of fleeting value in and of itself.  Only actual work experience, grappling with juggling priorities, making tradeoffs, and satisfying multiple constituencies, tends to teach people how to maximize the value from IT-related investments made by the company.  And there aren’t any true shortcuts. Again, the saying applies that I’ve cited here before: “good judgment comes from experience.  Experience comes from bad judgment.”

Lagniappe:

]]> http://www.peterkretzman.com/2011/01/16/can-a-cio-be-successful-without-it-experience-define-your-terms/feed/ 18 Mending Wall: Matches and mismatches in IT stakeholder expectations http://www.peterkretzman.com/2010/12/28/mending-wall-matches-and-mismatches-in-it-stakeholder-expectations/?utm_source=rss&utm_medium=rss&utm_campaign=mending-wall-matches-and-mismatches-in-it-stakeholder-expectations http://www.peterkretzman.com/2010/12/28/mending-wall-matches-and-mismatches-in-it-stakeholder-expectations/#comments Wed, 29 Dec 2010 05:23:31 +0000 Peter Kretzman http://www.peterkretzman.com/?p=525



Oil and water? Some days, the disconnect between stakeholder expectations and IT capabilities (and sensibilities) seems staggering.

Case in point: I was shown an astounding list of generic stakeholder expectations a while back, drawn up by an obviously frustrated group and titled “USER REQUIREMENTS FOR IT”.  The list is most interesting in what the items reveal between the lines. Let’s examine what probably caused this group to write down these specific but very abstract needs.

User requirements for IT

  • Must be adaptable to business situation
  • Must be able to employ multiple SDLC (Software Development Lifecycle) techniques as the situation dictates
  • Must be able to work in a highly parallized (sic!) environment
  • Must be able to accept and adapt to last minute scope
  • Should have multiple channels for functionality development both in terms of large releases and off cycle enhancements that occur in parallel.
  • Must provide the ability to externalize functionality to external teams to quickly develop new functionality
To most IT professionals, these come off as “unreasonable” demands at first examination. But they’re both understandable and revealing, if you take the stakeholder point of view, and if you remember the oft-cited adage that all progress depends on the unreasonable man.

It turns out that their list is almost certainly a history of (and response to) the various roadblocks they’ve been presented (by IT) over the years. (“Roadblock” being their view of matters, mind you).

Specifically, it’s likely that IT has tended to tell them something pretty close to the following at various key junctures on projects:
  • “This is the way we do it”; it doesn’t matter that the business situation would necessitate a different approach
  • Our SDLC dictates that we have to do it this way
  • Our work is going to be serial; first we need to do this, then we’ll get around to doing that
  • Last minute change just isn’t possible, no matter how necessary
  • We’re already working on a large release elsewhere; you’ll have to wait for that to finish for resources to be available to work on your needs
  • New functionality must be developed by our core team; we can’t offload that to another group for various reasons
Stakeholders don’t want the glass to be half empty or half full; they want a bigger glass and more liquid for it too.

But the stakeholders are tired of hearing such things. They “think different”, as the old marketing slogan had it.  These are people who don’t cheerfully accept the notion of “opportunity cost”. They don’t want their past decisions to automatically limit their future options.  They are impatient with the very notion of limits or constraints. They don’t want to be pushed to set priorities, because that means they’ve chosen one thing over another, when they really want both. They don’t want process to get in the way of immediate progress. They’re impatient with things being done serially, rather than in parallel. They know their needs change, legitimately, at the last minute, due to market pressures and other factors beyond their control. They don’t want the glass to be half empty or half full; they want a bigger glass and more liquid for it too.


In other words, IT stakeholders often look at IT processes and practices as being, well, a wall. And as Robert Frost put it in his well-known poem, “Mending Wall“, “something there is that doesn’t love a wall.” As you can see from the above list, to stakeholders, the wall of IT processes often shuts them out from getting what they need, rather than providing clear benefit.

But actually, despite how all this rings familiar to any long-standing IT worker, most stakeholders aren’t completely like this. Not deep down. Not if there’s proactive leadership and guidance. Most stakeholders, for example, actually do understand and welcome the opportunity to set priorities. They understand, in their gut, that it’s probably a good idea to avoid rework. They recognize that there are long-term considerations such as security and maintainability that can trump the need to “just get it done.”  But that doesn’t mean they won’t push back despite these understandings: as I wrote before, “everyone wants to get to heaven, but no one wants to do what it takes to get there.“

Stakeholders really do want things like robust delivery, solid systems, ease of maintenance and flexibility, and high predictability of time frames for development and release. It’s just that they don’t automatically, independently, intuitively understand the prerequisites to achieving those things: e.g., the need for careful prioritization of desired functionality; the importance of not trying to get everything all at once; the need to stick to a plan once it’s formulated, rather than changing the game every week; taking the time to test and carefully document even though those activities sometimes just seem to delay “the real work” of delivering what they want. They forget that “discipline is remembering what you really want.”

In short, it’s really a tug-of-war for the stakeholders themselves, a battle between their natural immediate wants and their long-term real underlying desires.

The answer to this perennial standoff?  Well, quite literally, “there isn’t one”: by which I mean that there isn’t one single answer. Instead, there are several, to be exercised simultaneously. And more than any single other entity in a corporation, success here depends on the adroit senior IT executive to bring off an appropriate balance.
  • Be flexible. Your SDLC is important, but it can’t become absolute or “wall-like”. And while you’re being flexible (within reason, of course), recognize the downsides of doing so. It means there will be some rework. There will be interproject conflicts that could have been prevented had there been better planning and preparation. Roller derby is not ice ballet. Being scrappy will get you scraps and scrapes more often than not, but that’s just sometimes how the game needs to be played.
  • Educate, as the opportunity presents. The flip side of Frost’s “something there is that doesn’t love a wall” is “good fences make good neighbors.”  Your stakeholders don’t automatically see the value in various IT processes and practices; only targeted discussion will help them do so. Having metering lights on freeway on-ramps seems to slow things down, but it actually speeds things up. Recognizing that isn’t intuitive.  Talk them through why your project may need the equivalent of metering lights.
  • Emphasize collaboration and teamwork. In Frost’s poem, it can be argued, the actual process of working on the wall together (rather than the wall itself) is what makes for good neighbors. Figure out together what processes add real value.
  • Constantly look for ways to de-couple your work so that chunks/projects can be done in parallel. Serial thinking can often become an easy out, a lazy excuse.  You’ll note that at least three of the points in the stakeholder list that led off this post have to do with conducting work in parallel.
  • Lead. Without proactive, engaged senior leadership that constantly and effectively reminds everyone of the less visible goals, polls them on their reactions and then reframes the discussion, the stakeholder requirements list rapidly starts to include things that are frankly akin to wanting M&Ms for breakfast. Leadership brings balance and perspective.
Make no mistake about it: mending walls is hard. Doing just one or two of the above approaches will cause you to fail as surely as if you did none of them. And in my experience, absence of the appropriate balance almost always causes a company to devolve into systems chaos.
]]> http://www.peterkretzman.com/2010/12/28/mending-wall-matches-and-mismatches-in-it-stakeholder-expectations/feed/ 7 Business impact and transparency: expressing system availability http://www.peterkretzman.com/2010/12/08/business-impact-and-transparency-expressing-system-availability/?utm_source=rss&utm_medium=rss&utm_campaign=business-impact-and-transparency-expressing-system-availability http://www.peterkretzman.com/2010/12/08/business-impact-and-transparency-expressing-system-availability/#comments Wed, 08 Dec 2010 19:11:55 +0000 Peter Kretzman http://www.peterkretzman.com/?p=514



“System availability was 99.83% last month!  That’s up from 99.75% the previous month!”

Sounds kind of good, no? I mean, that’s a high number, right? Right?

Actually, no.  It’s not a very useful number, in and of itself. In fact, I regard the publication of uptime metrics like that as a regrettable symptom of IT focusing on technical aspects, rather than business impacts.  Here’s a discussion of why I see it that way, followed by a presentation of an alternative focus providing much more business value.

So, what’s wrong with a time-honored metric like “the system was 99.83% available”?

  • The number is deceptive. Few people can mentally translate “99.83% availability” into a more meaningful real number, such as “system was down for 1.3 hours last month.”  Even fewer can tell you the real difference between 99.3% uptime (also sounds pretty good, right?) and 99.8% uptime.  Both 99.3% and 99.8% look (to the vast majority of business people) at first glance like pretty good numbers for uptime, but the first represents more than three times the number of “down hours” of the second.

  • The number is ill-defined. It begs the question of what’s considered down: what if the system is just somewhat degraded in performance? Who decides that it’s down? Who declares that it’s back up? We’ve all seen situations where a technician will insist the system is up, even though no one is able to access it or get sufficient performance to actually use it.
  • The number is often not comprehensive in what it includes. Most notably, many shops don’t count scheduled maintenance as downtime when calculating their uptime metric.  When you don’t count scheduled maintenance, you’re ignoring potentially many hours of real business impact per month. Scheduled maintenance can’t be a “free pass” for downtime.
  • The number doesn’t compare apples to apples. Just tracking total raw downtime considers all outages to be the same, no matter what the time or situation.  A ten-minute outage at noon may impact your business much more than an hour-long outage at 3 a.m.  An outage that occurs right when you’re running a key campaign to drive people to your site can be especially devastating.

Alternatives

Somewhat better than the “99.83% uptime” style of metric is reporting on the specific number of system DOWN hours or minutes in the period.  It’s when the system is down that there’s business impact, so why not use that as your yardstick, instead of the reverse.  Some call these “impact hours”, in fact.  Stating that the system was unavailable for 20 minutes last week is much clearer (albeit sometimes more distressing!) to most business people, compared to saying it was 99.8% available.  Still, though, expressing the figure as down hours doesn’t address the other problems listed above.

The underlying insight here is that raw outage statistics, whether they’re expressed as an uptime percentage or as downtime hours, are nothing but a proxy for business impact. And not a very good one, for the reasons discussed.

Here’s a radical idea: the goal isn’t simply to report and then reduce your downtime per se.  Instead, you want to assess, promulgate, and then work down, the total business impact of your outages, and to do that effectively, you need to weight your outages by time of day and traffic. And you need to include every single outage in your assessment of business impact, including maintenance.

What’s the clearest expression of business impact?  In a nutshell: DOLLARS. How much did a given outage cost the company, in terms of missed sales and wasted expenses? Yes, there are a lot of factors and assumptions involved in figuring that out, but that’s what models are for.  Make some assumptions and build a model that will calculate the specific dollar cost for an outage, based on information about the outage’s duration, site traffic pattern at the time of the outage, etc.

We did exactly this at an internet site where the revenue stream was on the order of a million and a half dollars a week.  We incorporated considerations such as the following into our model:

  • Upon analysis, we realized that any outage resulted in missed subscriptions, site advertising, and ancillary signups for partner services from which the company derived revenue. We needed the model to incorporate an understanding of the patterns and dollar costs for each of these.
  • We also realized that an outage also meant that we’d wasted the money spent on external internet advertising during that outage that was driving people to our site. During an outage, external ads of course kept appearing for our site; people would click on those ads and land on our outage page. Ergo, wasted advertising dollars.
  • Outages at different times (hour of day, plus even day of week) were vastly different to our site in terms of business impact and cost. Specific time of the outage needed to be a key part of the calculations of business impact.
  • Outage impact also depended on whether it was a high-traffic day or not.  A high-traffic day might feature more than ten times the normal volume of traffic and transactions; an outage at that point would therefore arguably cost us ten times as much.
  • Not all outages were total: sometimes performance was degraded but access was still possible. We decided to incorporate a “% degradation” parameter in the model for an outage, recognizing that deciding on that percentage would be a judgment call for any outage.
  • As noted, most sites don’t count scheduled maintenance in downtime. But that’s still lost revenue. Assessing business impact requires both conservatism and full transparency. We decided to include all outages, scheduled or otherwise, when we published our outage business impact metrics.

Building the model required not just some adept spreadsheet skills, but the up-front accumulation (and regular updating) of various base data to drive the calculations.  Specifically, for each hour and day of week, we had to:

  • Collect and average our aggregated historical traffic data
  • Collect and average aggregated sales revenue numbers
  • Determine how to calculate probable advertising revenue

Once built, our model not only let us state our downtime in terms of true business impact (i.e., total dollars for a given period), but it also provided a ready way of analyzing, up front, the specific cost of a planned outage. Using that as a tool, management could much more effectively assess alternatives and opportunity costs when system interventions to address various problems were being considered.

Here’s a snapshot of the model’s inputs (in yellow) and its outputs, slightly altered for presentation:

From here, it’s a small step to logging and tracking these total estimated costs across a given time period such as a month. (You should anticipate, by the way, that disclosure of the total dollar cost of outages will tend to invoke far more attention and commentary than the old-style percentage figure ever did!  Transparency brings scrutiny. This is a good thing.)

Yes, estimates and aggregations were necessary in coming up with these approximate costs; it’s just a model, after all, with all sorts of incorporated assumptions. And the estimates will never be utterly perfect. But still, they’ll be a far cry better at helping you express the approximate business impact of your downtime than just proudly declaring that the system was “99.83% available” last month.

Lagniappe:

  • Publicly visible major SaaS system availability pages:
]]> http://www.peterkretzman.com/2010/12/08/business-impact-and-transparency-expressing-system-availability/feed/ 7