Michael Masterson's book "Ready, Fire, Aim" is one of my favorites. Masterson, a serial entrepreneur who has built dozens of businesses, some to $100 million in revenue and beyond, explains that the biggest determiner between success and failure is how quickly we get going and execute…even if the plan isn't perfect. Spot on!
But, Masterson also takes great care to explain how critical (and often misunderstood) being truly "ready" is, and that "firing" without actually being ready is as bad as if not worse than delaying for perfection. So what do we do? Where do we draw the line when it comes to projects like client virtualization, with hundreds of moving parts, politics galore, and very little objective, unbiased information available?
Answer: The winners will get going today…now...and will get ready by talking to the people their work will ultimately serve, and learn enough about their needs and the technology and best practices to avoid the mistakes most likely to result in failure -- knowledge that they will acquire in less than 90 days. The fire process starts the moment they make an investment in new people or technology, and the aiming process continues through the life cycle of the service, steadily improving in value, effectiveness, and efficiency.
A while ago, in fact too long ago (but not in a galaxy far, far away), I wrote a blog called Giving Back To The IT Service Management Community where I surmised that IT service management (ITSM) practitioners need help beyond the ITIL books and associated training. They need real-world help; whether this is by way of guidance, quick-start templates to prevent the “reinvention of the wheel,” benchmarks, or by other means. And that, while some members of the ITSM community already offer help, what practitioners really need is to be offered targeted and focused help. A response that is practitioner “pull” rather than helper “push.”
In short, I proposed that we need to do at least five things (as a community) to help:
Recognize that we are a community and a community that often struggles with the same issues (particularly with ITIL adoption).
Offer up our time to help out others (and often ourselves).
Identify where our efforts need to be applied (for example with the creation of a set of standard (core) ITSM metrics and benchmarks).
Deliver on our promises to the ITSM community.
Never stop trying to improve our collective ITSM capabilities and the quality of delivered IT and business services.
There is growing evidence of a harmonic convergence of Infrastructure and Operations (I&O) with Security and it is hardly an accident. We often view them as separate worlds, but it’s obvious that they have more in common than they have differences. I live in the I&O team here at Forrester, but I get pulled into many discussions that would be classified as “security” topics. Examples include compliance analysis of configuration data and process discipline to prevent mistakes. Similarly, our Security analysts get pulled into process discussions and other topics that encroach into Operations territory. This is as it should be.
Some examples of where common DNA between I&O and Security can benefit you and your organization are:
Gain economic benefit by cross-pollinating skills, tools, and organizational entities
Improve service quality AND security with the same actions and strategies
Learn where the two SHOULD remain separate
Combine operational NOC and security SOC monitoring into a unified command center
Develop a plan and the economic and political justifications for intelligent combinations
Is it a blog? Is it a musing (that’s not “amusing”)? Or is it just a cheap attempt to pick the brains of others smarter than myself? Does it matter? Can I do anything other than ask questions?
My point (or at least my line of thinking while I plan a couple of ITIL-related Forrester reports) is that we spend a lot of time talking about what to do (or more likely what not to do) when "adopting ITIL," but how often do we talk about whether we have been successful in applying the concepts of ITIL, the processes, and the enabling technology for business benefit?
Maybe it is because we quote the mantra that “ITIL is a journey” and we can’t see a point in time where we can stop and reflect on our achievements (or lack of)? Maybe we segue too quickly from the ITIL-technology adoption project into the firefighting realities of real-world IT service management? Whatever the potential barriers to taking stock, where is that statement that describes what we have achieved and our relative level of success?
Looking at this logically (fatal mistake, I know), assuming (potentially a big assumption) that there was a business case for the “ITIL adoption project” where is the post implementation review (PIR)? Where can we look to see the realization of business benefits (I deliberately didn’t say “IT benefits” BTW)? I’m trying not to be cynical but, even if we forget the formalities of a PIR, how many I&O organizations can quantify the benefits achieved through ITIL adoption? More importantly what has been achieved relative to the potential for achievement? Where did we get to in our desired-future-state?
About five months ago, I “broke up” with T-Mobile in favor of AT&T. I was a T-Mobile customer for six years on a very competitive service plan. But none of that mattered; I wanted an iPhone, and T-Mobile couldn’t give it to me. It was a clean but cruel breakup: AT&T cancelled my T-Mobile contract on my behalf, the equivalent of getting dumped by your girlfriend’s new boyfriend.
I bring this up because it reminds me of the saying: “If we don’t take care of our customers, someone else will.” This is particularly important to remember in “The Age Of The Customer” where technology-led disruption is eroding traditional competitive barriers across all industries. Empowered buyers have information at their fingertips to check a price, read a product review, or ask for advice from a friend right from the screen of their smartphone.
This is affecting your IT just as much as your business: As an indicator, Forrester finds that 48% of information workers already buy whatever smartphone they want and use it for work purposes. In the new era, it is easier than ever for empowered employees and App Developers to circumvent traditional IT procurement and provisioning to take advantage of new desktop, mobile, and tablet devices as well as cloud-based software and infrastructure you don’t support. They’re “cheating” on you to get their jobs done better, faster, and cheaper.
To become more desirable to your customer – be it your Application Developers, workforce, or end buyers – IT Infrastructure and Operations leaders must become more customer-obsessed, which I talk about in this video:
Help mummy, that horrible man is talking about finance again.
I jest, but I very nearly titled this blog “Warning: This Blog Is About IT Financial Management And ITIL.” Sorry, but this is how I feel sometimes when I talk about the financial side of IT management, IT service management, and ITIL adoption.
But remember, accountants are supposedly boring not scary. The really scary thing is that IT infrastructure and operations (I&O) organizations have survived for so long without really appreciating what it costs to deliver their IT services.
There is no denying that I&O organizations have always “done finance” in some shape or form. There is not a single business function, IT or otherwise, in any organization that can escape the need for some semblance of financial management and the scrutiny from the formal finance department. So my question to I&O execs is not “Are you doing IT financial management?” but rather “How mature is your IT financial management?”
The changing business and IT landscapes are bringing an end to a somewhat slapdash approach to managing I&O’s finances and investment and usher in the need to extend IT financial management to encapsulate the concept of value. Read on, Macduff.
Why haven’t I&O execs focused on maturing their IT financial management practices?
In a surprising move, HP and Cisco announced that HP will be reselling a custom-developed Cisco Nexus switch, the “Cisco Nexus B22 Fabric Extender for HP,” commonly called a FEX in Cisco speak. What is surprising about this is that the FEX is a key component of Cisco’s Nexus switch technology as well as an integral component of Cisco’s UCS server product, the introduction of which has pitted the two companies in direct and bitter competition in the heart of HP’s previously sacrosanct server segment. Combined with HP’s increasing focus on networking, the companies have not been the best of buds for the past couple of years. Accordingly, this announcement really makes us sit up and take notice.
So what drove this seeming rapprochement? The coined word “coopetition” lacks the flavor of the German “Realpolitik,” but the essence is the same – both sides profit from accommodating a real demand from customers for Cisco network technology in HP BladeSystem servers. And like the best of deals, both sides walk away thinking that they got the best of the other. HP answers the demands of what is probably a sizable fraction of their customer base for better interoperability with Cisco Nexus-based networks, and in doing so expects to head off customer defections to Cisco UCS servers. Cisco gets both money (the B22 starts at around $10,000 per module and most HP BladeSystem customers who use it will probably buy at least two per enclosure, so making a rough guess at OEM pricing, Cisco is going to make as much as $8,000 to $10,000 per chassis from HP BladeSystems that use the B22) from the sale of the Cisco-branded modules as well as exposure of Cisco technology to HP customers, with the hope that they will consider UCS for future requirements.
Earlier this week, I attended the Hornbill User Group (or "HUG" as it is affectionately known) to listen to Malcolm Fry, IT service management (ITSM) legend and author of "ITIL Lite," talk about ITSM metrics in the context of ITIL 2011.
There is no doubt that metrics have long been a topic of interest, concern, and debate for ITSM practitioners (I wrote a piece a few years ago that is still the most popular item on my old blog site by a huge margin), and IMO I&O organizations struggle with the area due to a number of reasons:
I&O is not entirely sure what it is doing (in terms of metrics) and why.
We often measure what is easy to measure rather than what we should measure.
I&O can easily fall into the trap of focusing on IT metrics rather than business-focused metrics.
I&O organizations often have too many metrics as opposed to a select few (often led by the abundance of reports and metrics provided by the ITSM tool or tools of choice).
There is no structure or context between metrics (these can be stuck in silos rather than being “end-to-end”).
Metrics are commonly viewed as an output in their own right rather than as an input into business conversations about services or improvement activity.
We live in a time when customers expect services to be delivered non-stop, without interruption, 24x7x365. Need proof? Just look at the outrage this week stemming from RIM's 3+ day BlackBerry service/outage impairment. Yes, this was an unusually long and widespread disruption, but it seems like every week there is a new example of a service disruption whipping social networks and blogs into a frenzy, whether it's Bank of America, Target, or Amazon. I'm not criticizing those who use social media outlets to voice their dissatisfaction over service levels (I've even taken part in it, complaining on Twitter about Netflix streaming being down on a Friday night when I wanted to stream a movie), but pointing out that now more than ever infrastructure and operations professionals need to rethink how they deliver services to both their internal and external customers.
I need to make this brief; the failure of the lump of plastic that used to be my BlackBerry has made me very time-poor today …
It has been an interesting year for RIM and for the BlackBerry. RIM has seen the erosion of its corporate mobile-email dominance (as employees prefer the usability of iPhones and Android devices), its brand was adversely affected by the BlackBerry Messaging Service being "the weapon of choice" for the thugs involved in the London riots, its tablet play has limped into the iPad's market, and now we have the prolonged service outage ... Sorry service OUTAGES.
The extent of the outage has been and continues to be shocking (there is no way it should have been this severe). But to me, in my capacity as an analyst, and observer and advisor on IT service management best practice, the real issue here is how RIM has handled the situation.
In managing the outage, RIM has acted like an old-fashioned technology vendor rather than a modern-day service provider; while we talk about BlackBerry devices we are really buying into the BlackBerry service. And we expect that service to be consistently delivered relative to service promises and our expectations thereof.
While we would prefer there not to be an interruption to service, most of us appreciate that "stuff" happens. When there is a service-affecting issue, we have a set of minimum requirements as customers that need to be catered for:
Firstly, we want early notification and a speedy resolution or a work around. As a minimum, that the service provider is visibly seen to be applying significant and varied efforts to the resolution of the issue. We want to see that the service provider cares.
Secondly, we want our expectations to be managed. Communications should keep us informed and be honest about when we should expect service resumption.