When Everything Becomes a Service – Does ITIL Help or Hurt?


services-13For many years I’ve had an interest in the disciplines of Product Management and Service Management. These disciplines have been generally lacking in IT shops, though that is changing. Frameworks such as ITIL and standards such as ISO/IEC 20000 are helping sensitize IT professionals to Service Management, and methods such as Agile Development and Scrum are sensitizing IT professionals to the role of Product Owner, if not to the disciplines of Product Management.

However, my interest has been strengthened since reading the remarkable book, The Connected Company by Dave Gray with Thomas Vander Wal. Dave and Thomas have awakened me to a fact that I was subliminally aware of, but have reinforced for me why this is happening now. They have also drawn out for me some implications and subtleties I had not considered when thinking about the Service Revolution.

Everything is Becoming a Service

As the authors suggest:

Services cannot be designed and manufactured in isolation, like products. They are co-created with customers and are interdependent with wider service networks and clusters.”

They point out that most companies today have been finely tuned to “produce high volumes of consistent, standard outputs, with great efficiency and low cost.” Even some so-called ‘services’ are in reality “factory-style processes that treat people as if they were products moving through a production line.”

The Customer’s Experience of a Service is Key!

A product is largely experienced as it was manufactured. We may have subjective reactions to the product, but it does not change, other than through built in features. Services, however, change as they are experienced. This means that services cannot be delivered simply through efficient and operationally excellent processes. Services demand a ‘customer intimate’ delivery model that adapts to the ways the service is co-created by the customer and optimizes the customer experience.

The Strengths and Weaknesses of Standards and Frameworks Such as ITIL

My esteemed colleague at BRM Institute, Dr. Aleksandr Zhuk, just posted a wonderful short post titled “BRM Role and Service: ITIL Dyad Revisited.” As an officially certified ITIL Expert, ‘he knows what of he speaks’, as they say. Please check out his post – and tell us both what you think, and how these observations resonate with your own experiences.

 

Graphic courtesy of Augustedge

Enhanced by Zemanta
About these ads

ITIL and the Business Relationship Manager: Avoiding the Performance Trap!


order-taker

I have good news, and I have bad news!

The Good News…

The IT Infrastructure Library (ITIL) 2011 edition and the ISO/IEC 20000 standard for IT Service Management formalized the existence of the Business Relationship Manager (BRM) role and corresponding Business Relationship Management process as a new best practice and international IT Service Management standard requirement.  This is good – for professional BRMs around the world, for the IT profession in general, and for improving the business return on IT investments, as technology becomes ever more deeply embedded in business processes.

The Bad News…

(And I know I will get hate mail and lose readership for saying this, but…) As defined by ITIL, the BRM role comes off as somewhat tactical – not something to get business leaders salivating over their new partnership with IT, nor hungry to innovate business products and services!  Let me be clear – the ITIL vision of BRM is necessary – but from my experience, it is insufficient to drive real business value beyond a certain point.  It will help an IT organization with poor service quality get better.  But it will not help an IT organization with good service quality to excite and delight their customers with the new business capabilities that are enabled by information and information technology!

Business Relationship Manager Role

I’ve posted extensively on this role in the past – the BRM is a bridge between the IT organization and its business clients (just as a good CIO is a bridge between the IT organization and corporate leadership).  As such, it both represents the business clients to IT, and IT to the business clients.  This role has surfaced over the last 10 years or so and Gartner predicts that the fraction of IT personnel dedicated to Relationship Management and Change Leadership functions will reach as much as 15% by the end of 2013 and grow up to 20% by 2016.  LinkedIn hosts two groups dedicated to the BRM role.  One group – IT Business Relationship Management - currently boasts over 1,800 members.  The other group, Professional Business Relationship Managers currently has over 2,600 members!  (In the interests of full disclosure, I co-manage the latter group.)

I’ve conducted a significant amount of consulting, assessment and training in the BRM space, including designing and leading BRM training and development programs for global companies with over 100 BRMs (as well as for those with fewer than 5 BRMs).  From that experience, and from my ongoing activity on the LinkedIn groups, I’ve seen two distinct ‘flavors’ of BRM – “Tactical” and “Strategic.”

BRM and Business-IT Maturity

To help understand “tactical” and “strategic” BRMs and how they’ve come to be, I’ll use my Business-IT Maturity Model (BITMM).  I’ve posted at length about the BITMM.  In its simplest form (see graphic below) the model represents both business demand maturity (highlighted in red to the left of the learning curve) and IT supply maturity (highlighted in blue to the right of the curve. These never move completely in tandem – sometimes demand is slightly ahead of supply, other times it is slightly behind.  If demand and supply get too far out of whack, there’s usually a change of CIO (or a turnover of the IT organization to an outsourcer!)

Slide1

The number of maturity levels is arbritary, but for simplicity let’s use three – business efficiency, business effectiveness and business transformation.  Where a company is at any point in time is a function of factors such as:

  • the industry it’s in
  • current business leadership
  • competitive and regulatory forces
  • quality of IT leadership
  • quality of service delivery

For example, the financial services industry tends to be highly information-intense, so is generally demonstrated higher business demand and IT supply maturity than say, manufacturing companies, which have traditionally been less dependent on information.  All that is changing, of course, as businesses and governments everywhere become increasingly digitized.

The ITIL Connection

Improving service delivery quality is where ITIL focuses.  According to its current owners (The APM Group Limited) ITIL is “the most widely accepted approach to IT service management in the world.”  Originally developed under the auspices of the UK Office of Government Commerce (OGC), ITIL is becoming a popular approach to service management.  Often loosely, and occasionally rigorously followed, ITIL documents processes and practices for service management.  This focus on service management is crucially important in moving IT supply maturity up from low Level 1 to mid-Level 2.

The Tactical BRM

The graphic below crudely cuts the BITMM in half.  The lower half is what I refer to as the “tactical” BRM space – focused on business efficiency and effectiveness.  The conceptual dividing line between these spaces is important.  Around the mid-point of Level 2 maturity, the learning curve changes direction.  This is also a common “sticking point” (see my earlier posts on “sticking points”) where IT organizations often become trapped and their efforts at performance improvement taper off.  In some cases, they actually fall back in performance.

Slide2

So, in the pursuit of service management quality, the BRM has an important role, establishing a strong business relationship with the customer by understanding their business and customer outcomes.   But the focus is service management, as opposed to the strategic possibilities for IT capability to enable new or improved business products and services.  Service management applies most to ‘steady state’ IT services – not to transformational projects and programs on behalf of business units.

The Strategic BRM

The upper half of the BITMM is the “strategic” BRM space – focused on business effectiveness and transformation.  While an IT organization must be careful not to slip back on IT service quality and customer satisfaction, simply delivering ever-improving services will not transform IT into a respected, value-producing business partner. Sooner or later, IT service management efforts reach a point of diminishing returns. Something quite different is then needed to further improve the business return on IT assets and investments.  While the “Tactial BRM” tends to focus on IT supply management processes and activities, the “Strategic BRM” focuses on business demand management – stimulating, surfacing and shaping demand for services, activities and initiatives with the highest potential business value.  The “Strategic BRM” works closely with her business partner to ensure that IT investments and capabilities yield real business value.

Leverage the Standard Frameworks – But Don’t Get Stuck

The message here is that it’s ok to leverage standards and frameworks such as ITIL, COBIT and TOGAF – but essential to do so with intelligence!  They have their place – and a context for which they were intended – that often being UK government entities.  Nothing wrong with that, but it tends to be a context of control – not innovation.  Control can help you get from low Level 1 to mid-Level 2 – but not to Level 3.  What kind of IT capability does your business need – controlling or innovating?

Thoughts on a postcard, please!

Graphic courtesy of giffconstable.com

Enhanced by Zemanta

How Good are your IT Capabilities and How Good do they Need to Be? – Part 2


This is the 2nd in a multi-part post on assessing IT Capabilities.  (See Part 1)

A Quick Recap

Part 1 introduced some assessment principles I’ve found to be important.

  1. The Process is more important than the results.  I’ve found facilitated self-assessments to be the most effective.
  2. The results must be actionable. An assessment must give you insight into what needs to be improved, with what urgency and in what sequence.
  3. The results must be multi-dimensional. For example, address performance, value delivered and health of a given capability.
  4. Process-based assessments only go so far – and may in fact be misleading! Not all IT Capabilities are process-based.  Some depend more on standardization of deliverables or the outputs produced by a capability, and some depend more on special skills and training. Concluding that a given Capability might be highly mature or highly immature might have nothing to do with its ability to deliver excellent results!

Capability Defined

There are several aspects to defining Capabilities:

  1. What is meant by “IT Capability”?
  2. What is the potential landscape of IT Capabilities?
  3. How do you know what IT Capabilities you need?

Let’s examine these in turn.

What is Meant by “Capability”?

Wikipedia defines Capability as:

The ability to perform actions. As it applies to human capital, capability is the sum of expertise and capacity.”

A couple of things to note about IT Capabilities:

  1. While Capability Maturity Models such as CMMI put processes as the central construct of a capability (and the key to capability maturity assessment), in practice not all IT Capabilities are inherently process-centric.  Some depend more on people’s skills and competencies (think Business Relationship Manager, for example) while others depend more on deliverables than they do on specific processes.  (For a more detailed treatment of this distinction, see Part 1 in this series or my earlier posts on Henry Mintzberg‘s seminal work on organizational constructs.)
  2. You don’t need to “own” any given IT Capability – you can “rent” it as in outsourcing or contracting, for example.
  3. Not all IT Capabilities exist in an IT (or IS) organization.  Some are embedded in business units or other organizations.  For example, the capability to chose, procure and maintain personal computing devices may belong to the business – think “Bring Your Own Device” or “BYOD” as this rapidly growing movement is often referred to.

What is the Potential Landscape of IT Capabilities?

I’ve covered this topic in some depth previously in my posts on IT Organizational Clarity, but as a quick recap, below is a normative, high-level IT Capability Model.

Normative IT Capability Model

One can debate the specific labels for each of these capabilities, but essentially, any enterprise that depends upon Information Technology to any degree needs each of these IT Capabilities.  Of course, the devil, as they say, is in the detail, and the detail exists in the drill-down decompositions for each of these high-level IT Capabilities.  We will get more into this in Part 3 of this series.

How do You Know What IT Capabilities You Need?

There must be a clear and explicit linkage from Business Strategy to needed IT Capabilities.  There are many methods for achieving and expressing this linkage, and this is the realm of strategy formulation.  At its simplest, a given Business Strategy will require a set of Business Capabilities.  In turn, most, if not all Business Capabilities will depend upon one or more IT Capabilities.  Common techniques for achieving this linkage include:

But, IT Must Not Only Satisfy Business Demand – It Must Stimulate and Shape Demand!

The big danger with most strategic alignment methods are that they are inherently reactive.  i.e., To enable “x” business capability or strategy, we need “y” IT capability.  But how do you know that the business strategy is properly informed by IT possibilities?  This is where the first in the Value Chain Capabilities (see graphic above) comes into play – Discovering Business-IT Potential – and where the role of the Business Relationship Manager is so key.  So, you don’t just need the IT Capabilities the business thinks it needs – you also need IT Capabilities that create IT “savvy” and equip the business to understand and fully exploit IT potential.

Coming Up Next…

In Part 3 of this series we will examine assessment dimensions and methods.

Graphic courtesy of LipheLongLurnERrdok

Enhanced by Zemanta

Service Measurement Index – An Unexpected Silver Lining?


Like it or not (for what it’s worth, I like it a lot!) Cloud Computing is here to stay, and as I’ve stated before in this blog, it is going to change a great deal of the IT landscape, including the future profile and role of corporate IT groups.  But there are some indirect consequences of Cloud Computing that in of themselves could have a profound impact.

How Can You Measure and Compare Service Providers – Including Yourself?

What does it really cost you to deliver a given service?  How does that cost change as you adjust service quality parameters?  How does it change if you incorporate elasticity into service quality – allowing, for example, for peak loads to increase by a factor of 100 on, say, Valentine’s Day?

These questions have never been easy to answer.  Even with attention to Service Management, and with the use of frameworks such as the IT Infrastructure Library (ITIL), most IT shops are not great at measuring these things.  Then, along comes Cloud Computing, with some very appealing value propositions, and potentially, a quick way to offer business services, flexible service levels and agile platforms.  Just how well do the various cloud vendors perform?  How can you compare one vendor against another – or against your internal service capabilities and performance?

To help answer these questions, there’s a new game in town called the Service Measurement Index. According to the Cloud Commons web site:

Hailed as an industry first, the Service Measurement Index (SMI) is a set of business-relevant Key Performance Indicators (KPI’s) that provide a standardized method for measuring and comparing a business service regardless of whether that service is internally provided or sourced from an outside company. Designed to become a standard method to help organizations measure business services based on their specific business and technology requirements, the SMI enables individual preferences to be the basis for what defines a good service.”

The SMI framework, originally created by CA Technologies, was recently transferred to the Cloud Service Measurement Initiative Consortium (CSMIC) to be independently developed and run.  The CSMIC is a consortium of academic institutions and representatives of business and government that is led by Carnegie Mellon University – source of the Capability Maturity Model Integration (CMMI).  The CSMIC currently comprises four Working Groups:

  • Service Characteristics & Definitions (includes Taxonomy)
  • Measures and Metrics
  • Literature and Relationship Review
  • Adoption and Strategy

The SMI Framework

The SMI Framework provides an holistic view into the entire customer experience for cloud service providers in six primary areas:

  • Quality
  • Agility
  • Risk
  • Capability
  • Cost
  • Security

Somewhere between JD Power & Associates and Consumer Reports, the SMI promises to provide a standardized way to describe, measure and, ultimately, benchmark service providers using ‘apples to apples’ comparisons.  Users of the SMI Framework should be able to compare cloud service vendors against their specific business and technology requirements.  They should also be able to make real-time decisions about where and how best to migrate or deploy an application.

Tackling the Largest Part of the IT Budget

While the White House attempts to reign in an ever expanding budget deficit by nibbling around the edges, most IT shops realize that the largest component of their budget goes to “keeping the lights on and the trains running on time.”  Making a serious dent in this budget could free up money and resources for higher value activities.

The jury is still out as to whether cloud computing will live up to all its claims for cost-effectiveness, but with the SMI, at least over time we will have the means to make those comparisons and make informed decisions about how best to source computing resources and services.

Join Me In a Live Conversation About The Cloud

As a reminder, I head out this week across the US for a series of CIO Forums about Threats and Opportunities In The Cloud.   Please click on the link for details and to sign up for this event!

Enhanced by Zemanta

‘Social’ IT Management – Part 3


In Part 1 of this series on ‘Social’ IT Management, we discussed the inherent complexity of the IT management function, and how a more ‘social’ and emergent approach can represent a better way to manage IT.  In Part 2, we talked about the types of things that would be in a ‘Social’ IT Management Platform and the advantages of such a platform for enabling this social approach.  In this 3rd post in the series, we will discuss some Principles my esteemed colleague, Roy Youngman and I have found helpful in moving to a Social approach to IT management.

Some Principles for ‘Social’ IT Management

Over the course of several client engagements, Roy and I have developed a short list of principles to guide the way we help a client move towards a ‘social’ approach to IT management:

  • Create a baseline quickly, set the quality bar high, and make rapid, incremental improvements thereafter.
    • Rationale: The emergent and more parallel process implied by a social approach can feel a little intimidating at first.  “Will I look like a fool?  How will my co-authors react?”  We’ve found that the best way forward is to “Just do it!”  Get started, and damn the torpedoes!  But also, don’t ask people to begin with a blank slate.  While some clients are o.k. starting from scratch, most prefer a starting point – a straw dog, if you will.  Having said that, it’s important to make it clear that the straw dog is just a starting point – that the expectation is that this will be refined into something we can really use and be proud of!
  • Follow a ‘cascading’ approach – deploy in waves, starting with IT leadership, rapidly engage Process Owners, then members of Centers of Excellence, and finally everyone.
    • Rationale: To be frank, there is something “1.0″ about this cascading approach – it’s rather top-down which flies in the face of a truly emergent, egalitarian and collaborative approach.  But most organizations have a hard time jumping from the “1.0″ to the “2.0″ paradigm.  So, we’ve found a “1.5″ approach to be a useful interim state.  It acknowledges the special role of the IT leadership team, and the reality of engaging them first.  It also puts them in a better position of experiencing the new approach and being able to model desired behaviors.  The trick is not to get stuck in a mode where everything has to start with the IT leadership team.  Get the process owners appointed early (they usually already exist, even if that role has not been formalized) and they in turn will engage process teams.  Typically, there are Centers of Excellence or Communities of Practice that are already blogging and participating in wikis (the IT architecture community is often an early adopter) so it is a natural to bring them into the tent.  Just be careful to not shut down their activity by legitimizing it.  They thrive as a 2.0 collaborative community because that was a truly emergent practice for them.  Legitimizing this practice as “leadership sanctioned and monitored” can shut it down, or drive it back underground, so don’t be too heavy handed in this sanctioning – shine a light on it, but not a floodlight!
  • It is far more important to instill pride-in-workmanship than to install a complex review and control process.
    • Rationale: Coming from the 1.0 world, it is natural for leadership to want to place controls all over the wiki environment.  I recall one client executive, when I first described the plans for their ‘social’ IT management, looking aghast, and saying, “You aren’t seriously suggesting we’d let stuff go up on the Wiki before it was fully vetted and approved?”  This is a natural reaction, but must be resisted.  The power and wisdom of the crowd to shape and continuously improve is relentless – if you let it be!
  • A Power-Law Distribution is expected and good; a few will contribute a lot and some will contribute little, but everyone has something worth contributing.
    • Rationale:  There’s no way around this.  It’s a well-researched and documented phenomenon.  Your major contributions will be limited to a small proportion of the IT organization.  Many will seemingly be bystanders.  The fact that they aren’t in the Wiki every day, participating in discussion threads, creating Wiki pages does not mean they aren’t participating or getting value from the it – they are.  Don’t be put off by it – just accept it and be thankful.
  • Leaders must demonstrate their commitment ‘by example’ while avoiding the temptation to criticize (which will be initially easy).
    • Rationale: Early on, people will look to IT leadership to see if they are “walking the talk.”  If they are, others will join the revolution.  If they are not – this too shall pass!
  • Consistency is a key to success; if every content page looks different, the Social platform will not create a sustainable social web.
    • Rationale: The emergent properties are a good force to tap, but can be a double-edged sword.  We’ve seen many clients with SharePoint (or Lotus Notes way back) where people were encouraged to participate. And participate they did – in spades!  Before long there were SharePoint sites everywhere – each with their own structure and style.  Pretty soon, the collaboration ecosystem is un-navigable.  You have to strike a balance between emergent and structured – and consistency in style and structure are important to sustain this.  Provide templates to make it easy for people to conform to a common style.  And have active Collaboration Managers and Wiki Gardeners whose role includes encouraging a clean and consistent style.

We will end this 3-part series here – but please keep an eye open for upcoming posts that further explore our work in this space.  Or ping Roy or me for a discussion on how this might apply in your organization.

And, of course, please comment on your thoughts and experiences – this is an emerging space, and we all have lots to learn about social means to improving IT management!

Graphic courtesy of Literate Web

Enhanced by Zemanta

Deming’s 14 Points Revisited: Part 1


deming

I was at a speaker at an nGenera Executive Summit recently where one of my co-speakers, Jeffrey Pfeffer, Professor of Organizational Behavior at Stanford University cited Deming’s “Drive Out Fear” dictum, from his 14 Management Points.

This reminded me of the genius and timelessness behind Deming’s teachings, and inspired me to tackle a couple of posts examining his 14 Points in the context of today’s economy.  Dr. W. Edwards Deming was an interesting and key figure in the quality movement.  He taught statistical process control (SPC) techniques to World War II workers and applied these methods to help improve crop and food yield during the war.

Regrettably, in the post-war frenzy for American products, he was largely ignored (rejected, even) by American industry.  However, due to his early work on the US census, he was invited to help with the census in Japan.  As a result, his work became visible to Japanese industry, and was wholeheartedly embraced and built upon by the Japanese, whose cultural inclinations were very compatible with Deming’s teachings.  The rest, as they say, is history!

Out Of The Crisis

In 1982, Deming published Out of the Crisis, a classic text that resonates especially strongly today.  Deming posited that,

Long-term commitment to new learning and new philosophy is required of any management that seeks transformation. The timid and the fainthearted, and the people that expect quick results, are doomed to disappointment.”

As one who has been involved in dozens of organizational transformations over the years – both as a consultant and as a “victim”, I say, “right on!”  Out of the Crisis offered a theory of management based on Deming’s 14 Points.  I will list them below, then pick a few to examine in each subsequent post.  From the perspective of 2009, and our Twitter/Facebook culture, Deming’s language may seem heavy and stilted, but, please, don’t let that put you off!

Deming’s 14 Points

  1. Create constancy of purpose toward improvement of product and service, with the aim to become competitive and stay in business, and to provide jobs.
  2. Adopt the new philosophy. We are in a new economic age. Western management must awaken to the challenge, must learn their responsibilities, and take on leadership for change.
  3. Cease dependence on inspection to achieve quality. Eliminate the need for inspection on a mass basis by building quality into the product in the first place.
  4. End the practice of awarding business on the basis of price tag. Instead, minimize total cost. Move towards a single supplier for any one item, on a long-term relationship of loyalty and trust.
  5. Improve constantly and forever the system of production and service, to improve quality and productivity, and thus constantly decrease costs.
  6. Institute training on the job.
  7. Institute leadership. The aim of supervision should be to help people and machines and gadgets to do a better job. Supervision of management is in need of overhaul, as well as supervision of production workers.
  8. Drive out fear, so that everyone may work effectively for the company.
  9. Break down barriers between departments. People in research, design, sales, and production must work as a team, to foresee problems of production and in use that may be encountered with the product or service.
  10. Eliminate slogans, exhortations, and targets for the work force asking for zero defects and new levels of productivity. Such exhortations only create adversarial relationships, as the bulk of the causes of low quality and low productivity belong to the system and thus lie beyond the power of the work force.
  11. Eliminate work standards (quotas) on the factory floor. Substitute leadership.  Eliminate management by objective. Eliminate management by numbers, numerical goals. Substitute leadership.
  12. Remove barriers that rob the hourly worker of his right to pride of workmanship. The responsibility of supervisors must be changed from sheer numbers to quality.  Remove barriers that rob people in management and in engineering of their right to pride of workmanship. This means, inter alia,” abolishment of the annual or merit rating and of management by objective.
  13. Institute a vigorous program of education and self-improvement.
  14. Put everybody in the company to work to accomplish the transformation. The transformation is everybody’s job.

We will examine each of these in subsequent posts, and place them in the context of the current global economy.

Reblog this post [with Zemanta]

Simple Processes


icon_simplify_titleI just came across a new blog called Simple Processes, and I’m sufficiently impressed to add it to my Google Reader, to my blog roll, and to use this post to point my readers to it.  In his current post, Glenn Remoreras discusses the achievement of the highest level of process culture maturity.  This is a very well-written, tastefully presented and insightful blog.

Process Culture is REALLY Important!

There are some fundamental disciplines that are at the heart and soul of the IT profession – project management, program management, portfolio management, service management, product management, and Enterprise Architecture.  All these disciplines depend upon the “meta-discipline” of process management.  It is easy in an age of Web 2.0, Enterprise 2.0 and Cloud Computing to take these fundamental disciplines for granted.  This is a massive mistake!  From my experiences, few IT organizations have mastered these disciplines, and in those companies where process culture is mature, I often find that the IT organization is the exception!

Do yourselves a favor – check out the Simple Processes blog!

Graphic courtesy of BizManualz

Reblog this post [with Zemanta]

I Must Have my Head in the Clouds!


Streaky Freaky CloudsI’ve been posting on and off about Cloud Computing since I began this blog a couple of years ago.  But, as one who spends most of his time with IT leaders of large global enterprises, sometimes the promise of the Cloud seems more like a mirage!

I’ve Looked At Clouds From Both Sides Now

Back in August 2008, not being able to resist the title to the wonderful Joni Mitchell and her reference to “cloud illusions I recall”, I posted on the denial I was witnessing among my client base.   I likened it to the denial that was common among CIO’s back in the early 1980′s.  To quote from that post:

(CIO’s) were mostly in denial, even as executive offices just down the corridor from the CIO’s office were beginning to become home to a variety of rogue PC’s – machines such as Apple II’s and Radio Shack TRS 80’s.

Fast forward 25 years or so. Now the press is full of predictions and prognostications about Cloud Computing, several key players are investing heavily in this space (pun intended) but many CIO’s and CTO’s either just don’t believe it, see it as warmed over service bureau computing from the 60’s and 70’s, or believe it’s the greatest threat to enterprise computing sanity since computer viruses first appeared.

Now, nearly 1 year later, I’m still seeing the same denial – Cloud Computing, for the most part, is on the back burner – a technology to watch!  Clearly, there are significant risks with the untried, standards are still evolving, and there’s something intimidating about such a simple concept being able to replace so much enterprise technology and expertise – the “heart and soul” of the typical IT organization.  In fact, for many IT shops, this “heart and soul” is where they’ve invested many of their improvement efforts over the last few years, implementing ITIL and process improvement approaches.  That’s been a hard-won fight, and CIO’s are loathe to admit that there might now be an easier and better way!

In another post earlier this year on The Dangers of Cloudy Thinking, I wrote:

I’m fascinated and bemused by this Cloud Computing phenomenon. Never before have I had such a strong feeling that something really, really important is happening – a fundamental discontinuity, if you will, in the way we leverage IT – and yet most of my clients and those I am interacting with in a couple of multi-company research projects are essentially standing on the sidelines.

Hincliffe’s “8 Ways That Cloud Computing Will Change Business”

Dion hits the nail on the head once more with his excellent June 5 post in which He says:

(Cloud computing offers) benefits that can potentially change the game for many firms that are willing to be very proactive in managing potential downside. These include access to completely different levels of scale and economics… Easier change management of infrastructure including maintenance and upgrades (cloud vendors extensively virtualize and commoditize the underlying components to make them non-disruptive to replace and improve) … Cloud computing also offers an onramp to new computing advances such as non-relational databases, new languages, and frameworks that are designed to encourage scalability and take advantage of new innovations such as modern Web identity, open supply chains, and other advances.

He goes on to show the major pros and cons, and then to cite 8 compelling ways that cloud computing can change business.

Cloud Computing – Ideal for the “Edgy” Opportunities?

Dion refers to the use of cloud computing beyond “edge” computing (which he describes as minor applications and non-critical business systems).  This is the only place where I take issue – I think “edge” computing is where the exciting action is, where the high value and innovative opportunities lie.

Back in July 2008, I posted on “Edginess and Innovation.”  In that post, I differentiated between “core” and “edge”:

Many IT leaders when talking about the “core” are referring to the “legacy” systems…  built over the years and have to maintain.  But in reality, the core goes much deeper than the systems and technologies. Business processes – especially when you include the unautomated practices and workflows that interact with the automated ones, are hard to change. The mindsets that dominate “core” thinking and “edge” thinking are radically different. I’ve noted before that quality guru Joseph Juran distinguished between “preventing bad change” (keeping processes under statistical control” and “creating good change” (innovating processes and products, or creating “breakthrough” performance as Juran put it) and the different management approaches and structures each requires. Most IT leaders have focused for years on management approaches more consistent with preventing bad change than creating good change. This has created a mindset that abhors risk taking.

I believe most of the “core” opportunities have been addressed in the typical global enterprise.  Sure, there’s always more to do (and the trap of saying “yes” to all the business requests to continually tweak and bolt onto core systems) but I believe you can move the business value needle significantly to the right by tackling more of the “edge” opportunities, and that is where, to Dion’s point, the Cloud (and its related technologies) offers real promise – now!

Reblog this post [with Zemanta]

“But We Don’t Have the Discipline to Implement ITILv3!”


student_discipline_head_photoI was talking to a consultant recently about some process work he was doing with a large, global IT organization.  I asked him if they had adopted any formal service management framework and he said that when he asked them about ITILv3, they said, “We tried that, but we just don’t have the discipline to do it!”

I was thinking about this admission from a multi-billion dollar, global enterprise, and thinking about analogies.

Businesses that Can’t Deliver What they Promise

Supposing, when you booked a flight, the airline said,

That flight might not get you to the destination you are paying for.  In fact, it might not get you anywhere with safety!”

Or, when you booked a hotel room (can you tell I travel a lot!), the hotel operator told you,

We can’t guarantee a room will be available, or that it will have clean sheets and towels.  We will try, but we really don’t have the discipline to ensure it!”

Or going to a hospital for surgery, and the admissions officer asking you to sign a waiver acknowledging that,

I understand that my surgery might not be performed by a board certified surgeon.  Or by anyone actually qualified to perform the needed surgery.  We will try to do no harm, but we don’t have the discipline to ensure it.”

For all the criticism we might throw at airlines, hotels, and even hospitals, by and large, these organizations have the processes, controls and disciplines to mostly do it right the first time.  IT service management is hardly open heart surgery, but the IT organization is being paid a significant amount of money to deliver services that people depend upon.  The customers of these services expect that they are being delivered consistently, reliably, accurately and at the best possible cost.  I can’t imagine what they would say or think if they knew this was not necessarily the case – that their service provider “did not have the discipline” to do it right!

Process and Service Management Discipline – Not Optional!

I’ve posted before about ITIL and about it being necessary but not sufficient.  I’ve never posted anything that implied that process discipline is not a critical success factor, or that ITILv3 is not a highly effective framework for bringing process and service management disciplines to an IT organization.  I do acknowledge that any process improvement methodology when applied without a modicum of intelligence can go overboard.  We see this in a phenomenon I call ‘death by Six Sigma‘ when the race to green belt certification leads to hundreds of mini process improvement projects without any overarching change architecture.  We saw it with Total Quality Management, and the Baldrige Award and Deming Prize winners that got into serious difficulty as the end of the prize became more important than the means to make money!

Do you have the necessary discipline to provide the best possible services at the lowest possible cost?  If not, what can you do to develop some commitment to do it right, and the discipline that comes with that commitment?  If the answer is “nothing,” how can you look your customers in the face?

Do You REALLY Have Effective IT Processes?


chickenprocessFrom time to time, we conduct IT capability assessments for our clients.  These typically examine two different kinds of capabilities – those IT capabilities that are largely owned and executed by the IT organization, for example:

  • Manage the IT Infrastructure
  • Deliver Business Solutions
  • Manage the IT Organization

They also (and sometimes, of great significance) assess those IT capabilities that are jointly owned by business and IT, such as:

  • Manage the Business-IT Portfolio
  • Manage Business-IT Relationships
  • Manage Enterprise Architecture

Capability vs. Process

An important element of capability is the concept of processProcesses tell you how work should be done, where inputs come from and outputs go to, what results should look like and how they should be measured and evaluated, how efficient and effective the process is, and how it should be evaluated and improved.  Capabilities bring in the dimensions of people and technology that use processes to get work done.

Some capabilities (typically those whose primary value proposition is Operational Excellence) require rigorous and robust process definitions.  For example, this is the primary domain for frameworks such as ITIL and COBIT.  Other capabilities, where the value proposition is Customer Intimacy or Innovation have a far higher “human content” requiring special competencies and judgment.  In these cases, processes may be less rigorously defined, but they are still important, even if only in the form of a checklist for the major steps, entry and exit criteria, and examples of the deliverables they create or outcomes to which they are intended to lead.

The distinction between capability and process is important for many reasons.  I sometimes find myself in debates with clients along the following lines:

We have assessed that your (fill in the blank) capability is low – not in place or only partially in place.

Which garners the client response:

That’s wrong – we have processes and artifacts to do (fill in the blank) – it’s fully in place, or at least mostly in place!

To which we respond:

You might think you have a process, but the people who’s role it is to deliver the capability associated with that process either don’t know about it, or are ignoring it – the net result is, you don’t have the capability maturity you need for (fill in the blank)!

The Characteristics of Real Process

So, how do you know you really have processes that are driving (or at least, shaping) behavior?

  1. Do you have a process definition that is known by and used by impacted stakeholders?
  2. Is it defined at a level appropriate to its purpose?
  3. Does it provide “best practice’ examples of input criteria, exit criteria and deliverables for each major step?
  4. Does it clearly spell out all roles associated with each given step?
  5. Do those roles call out or point to descriptions of the competencies (knowledge, skills and behaviors) needed to satisfy a given role?
  6. Are there outcome and in-process metrics and are these used to drive continuous improvement?
  7. If a new person, once familiarized with the formal process, stepped into the work mid-flight, would they know what to expect (and would find) what work has been done so far, and what steps need to be performed next?
  8. Do you have approaches to assure that key process steps have been followed (risk management)?

Some Questions to Reflect Upon…

So, think about your major IT capabilities:

  • For which ones do you really have good processes?
  • Where are your biggest gaps?
  • What would you gain if you closed those gaps?
  • Would it help with communications – internal to the organization and with your business partners?
  • Would it help clarify roles, responsibilities and accountabilities?
  • Would it help clarify the ‘rules of engagement’?
  • Would it make work more predictable and more easily repeatable?
  • Would it help identify non-value adding steps and activities, or missing roles?
  • Would it enable process improvement and innovation initiatives?
  • Would it help bring new employees or partners up to speed more quickly – accelerate ‘time to value’?
  • What would that all be worth?
  • What’s standing in the way of doing it?