Sunday, August 29, 2010

How To Use IT Governance To Drive IT Business Alignment

Continuing our series on the Real Professors of the 15th Annual IT Management Conference, Dr. John Beachboard is a professor of Computer Information Systems (CIS) at Idaho State University (ISU).  He has more than 25 years experience implementing large-scale information technology and telecommunications systems, and has received an AIS Award for Innovation in IS Education for his work incorporating IT Service Management concepts in the CIS curriculum. ISU has been recognized by the National Security Agency as an academic institution of excellence for its teaching of information assurance and computer security.

At the conference, Dr. Beachboard will present an actionable executive-level IT governance framework specifically designed to align IT investment and practices with business strategy.  His presentation includes: an overview of contending understandings of IT governance, which includes COBIT; a discussion about why and how an overly broad definition of IT governance can undermine substantive executive-level participation in key IT governance decisions thus diminishing strategic IT alignment; a review of the elements comprising the development of a strategic IT vision and actionable IT principles for governing the development of IT strategy and investments.

The IT Skeptic talked to Dr. Beachboard recently:


You mentioned “...an overly broad definition of IT governance can undermine substantive executive-level participation” - indeed!  I’ve railed against the terminological debasement of “governance”.  Do you think ISO38500 did a good job of getting us back to a more precise understanding of governance of IT?  it looks to me that COBIT 5 will better clarify the distinction between management and governance, and I’m crediting ISO38500 with at least some of the impetus for that.

Yes, I think that it does… but with some inevitable limitations.  These include:

1. The definition and approach adopted in ISO38500 does align with the more common understanding of corporate governance and I think that is very important with respect to distinguishing IT governance from IT management.  The “inevitable” limitation is that, at least in the US, the actual independence of corporate boards is questionable.  ISO standards can’t fix that, but the reality is that corporate executives have more influence over governance decisions than is probably desirable.  So in my view, a “workable” understanding of IT governance (at least in the US) must recognize the role of executive-level management as well as the “official” governing body.
2. To some degree, the ambiguity between IT management and IT governance will remain unavoidable because both deal with management control.  Granted, IT governance works at a meta-level, presumably establishing management controls processes over lower-level management controls.  But then if you look at risk management, much of the detailed analysis would be conducted by business process-owners and IT and security specialists.  Yet we look for corporate directors to make ultimate risk management decision.  It is not surprising that many practitioners will categorize the analytic effort as constituting an IT governance activity.  It is not clear to me that such fuzziness need be resolved; it is probably more important to recognize that some boundary conditions are fuzzy and attempt reach a common understanding in the enterprise. 
3. Finally, policy and principles do not necessarily address the underlying problems that they are intended to address.  I will explain this more when answering a later question.  But the short answer is that fairly good policies and principles have existed for quite some time but enterprises do not necessarily implement them well.  As Pfeffer and Sutton suggest in their book “The Knowing-Doing Gap,” too often we confuse know-what knowledge (the policies and prescriptions) with actual know-how.  This does not mean that the policies and principles are uncalled for.  It does mean that we probably should be humble in thinking about what we have actually accomplished writing them. 

“…a workable understanding of IT governance must recognize the role of executive-level management as well as the official governing body”: Is that “wrong”?  The Executive are delegated executors of day-to-day governance on behalf of the Governors themselves so they have both a governance and a management role - they represent the overlap or intersection of the two.

No, this overlap is necessary, particularly when some executives may also be board members.  But the messiness needs to be acknowledged.  The same individuals may wear IT governance and IT management hats.  In my writing I have adopted the term executive-level governance and attempt to finesse the issue.  I support ISO38500 emphasis on identifying board level responsibilities but feel that in the US, the boards will continue to rely heavily on corporate executives to perform IT governance (if its truly performed at all). 

I agree about the fuzziness at the boundary between governance and management.  In my up-coming book BSM: Basic Service Management, I am using the term “governance support” to distinguish from governance:

In order to have governance, the managers and staff need to provide governance support: policy enforcement, strategy planning, measurement, audit, reporting. These aren’t governance – they are the parts of operations that support and “plug into” governance: take direction, provide monitoring. They often get referred to as governance but not in this book.
Governance support cascades down: you have policy specific to service management, and reporting specific to it. But the governance itself always flows back to the organisation’s governors. There is no such thing as service governance. Put simply, the Board are responsible for service: the accountability cannot be delegated, only the management, and the governance support.

I dislike the continual debasement of the word governance so I’m making a stand by introducing “governance support”.  On the graphics of a presentation for the itSMF Australian conference, I called it “governance enablement”.  To me “enablement” is more accurate but too ponderous.  For an even snappier name, let’s call it “policing”.
But I suspect all is lost and governance is always going to be used more widely than is ideal.  Do you think giving a name to the “fuzzy zone” would help or is it too late?

Well, I am on your team on this and am willing to adopt the term as well.  I guess where the wrinkle inevitably remains, at least in my opinion, is that the governance support activities have long been a part of good IT management practice. 

There doesn’t seem to be much written about practical implementation of the links between governance and IT management.  Lots of fine words but what does it actually LOOK like in reality?

I very much agree with your statement.  I think that Jeanne Ross and Peter Weill have done some very good work in this area but it still leaves a fair bit to be desired from a practical perspective.  I was working in this area and a conference paper of mine on the subject was forwarded to Mark Toomey just this summer.  Mark wrote a kind email to me and my co-authors acknowledging our work and gently chastising us for not having specifically referenced the ISO [38500] standard or his book Waltzing with the Elephant [no connection to Pink ones].  Sort of embarrassing actually, but due to the cost it took a while to actually get access to the ISO standard.  Mark provided the first three chapters of his book to me for evaluation and they align very well with the thinking and writing I had been doing.  I have not had a chance to read the full book yet. 

Had I stumbled across his work earlier, I might not have pursued this line of research with as much diligence.  Yet, I believe that my colleagues and I will still be able to make a contribution with respect to writing “actionable” approaches to IT governance and management.  While no written work can substitute for actual experience, we are trying to provide specific suggestions and background knowledge to help managers more effectively employ the IT governance/management frameworks that are available. 

Waltzing With The Elephant is the only systematic treatment I have found of practical implementation of governance of IT.  Is there anything else out there? 

I agree that Mark probably has the best books out there (expecting that the remaining chapters are as good as the first three). 

I think a major problem is that there is a lot of good information published but it is spread throughout numerous books and articles.  Each author addresses a particular set of issues and the overall synthesis of ideas is lacking.  For example, Weill and Broadbent wrote a “Leveraging IT Infrastructures” in 1998.  There are some interesting insight in that book that could have been usefully brought forward to his more recent work with Jeanne Ross, but it wasn’t. 

James Martin’s 1984 book, “An Information Systems Manifesto” has some good ideas that are still relevant today as does Paul Strassman’s 1995 “Politics of Information Management.”  In truth, I can find points to argue with in all of these books, but they all contain useful ideas that have informed my thinking on IT management practice.  But it’s a lot of reading for practitioners to wade through and it takes some real effort to separate the wheat from the chaff. 

I am working with some colleagues on a monograph tentatively titled “IT management for Non-IT Managers” in which a practical approach to IT governance is offered.  Much of the content is not really new content; we are trying to provide a useful synthesis of the literature in a concise and readable form.  While I have been using early drafts in teaching my MBA courses, the work is not ready for publication. 



The world needs that monograph - we’ll look forward to it. 

Look for the rest of our fascinating discussion with John Beachboard in another post soon…

Wednesday, August 25, 2010

Common sense is better than nonsense

When it comes to defining let alone understanding or explaining what the IT department is or does many are baffled or scratch their head.

Unlike the lyrics from a popular song by Bob Dylan from the 1960s, the answer is not blowing in the wind.

The answer is quite simple. IT is a part of an organization. Its a simple matter of common sense.

Common sense – noun
sound practical judgment that is independent of specialized knowledge, training, or the like; normal native intelligence.

Origin: (in the English language)
1525–35; translation of the Latin sēnsus commūnis, which is itself a translation of the Greek koinḕ aísthēsis

Since it appears the Romans borrowed this expression from the Greeks, we could extrapolate the Greeks may have borrowed it from earlier civilizations. Why, we could even argue that every civilization had and used common sense!

I am on a roll! Let me go out on a limb. I claim that information technology has been around since the invention of the written language. This is currently acknowledge to be around 6,000 thousand years ago. There are current discoveries that could push that number back but let us not speculate or argue and this is not what this entry is about.

The technology has changed since then; from using rocks, clay tablets, papyrus, vellum, paper, to the current computer interfaces we are using today. No matter when, no matter what needed to be recorded, the information had to be « managed ».

Fast forward to today and people are still arguing about what IT is. As I said before, IT is « a » « part » of an organization. Every function in an organization uses some form of technology to store information.

IT has never been apart from the organization even if some people claim the opposite. The difficulty is that technological advancements fast outpaced the management of the technology and of the information captured or created (see Moore’s law). This created a few decades where technological wonders be it hardware or software were more anticipated then what we could realistically do. The management aspects quickly lagged behind.

As more and more people became computer-savvy and started using computers in their lives outside of work (shockingly, there is such a thing as life outside work) they realized that computers, computer technicians, programmers, and developers were OK to have around but that they did not necessarily knew how to manage the IT department.

I have been involved with and in IT since 1984. One of the mistakes made was to ask people who were great at their job to become managers. In insight, this was a bad idea and it was poorly executed.

This lack of managerial experience and knowledge was a significant contributor to the chasm between IT and the business. Mind you, I am not blaming the people who accepted the « promotion » to a management position.

So eventually, people started to think about managing IT better. Being IT people, they tried to invent a solution. Some people eventually sat together and came up with “best practices” for IT. It was a good idea. I was not involved so I can’t speak for the original « creators » of those practices but they already existed in the business.

The above preamble could have been written much more succinctly. I did not do so on purpose as I want to make a point. The point is this. Look around you. Look at what the people in the other parts of the business are doing.

I can and I will provide, in upcoming entries in this blog, examples of the existence of all of the activities in ITIL v3 in other parts of the business.

Because what we do in IT is no different that what the business does. It is simply a matter of common sense.

Stop trying to re-invent the wheel. Stop to smell the roses. Have fun. Turn off your mobile device for a day. Go play in the park, read a book, relax.

Like my former colleague, Jim used to say, « Have fun out there ».

Friday, August 20, 2010

ConfBOK: Luggage Validation and Testing

Several decades ago I flew from Melbourne to Washington DC for a database conference in the Hilton, not long after Ronald Reagan got plugged outside the same building.  (By a curious symmetry of history, I’m flying to an itSMF conference in the Melbourne Hilton tomorrow.  If you don’t hear from me…. ).  It was a cheap Continental flight, so it stopped in Sydney, Honolulu, LA, Denver, New York and then Washington.  Forty-something hours as I recall.  Of course I got there and my bags didn’t.  Despite buying some nice GAP shirts back when that was a novelty, the resulting discomfort was enough of a lesson that I always carried my bathroom-bag and a spare pair of undies in my carry-on after that.  Until the “liquids and gels” thing.  That put an end to it.  It was probably a good thing anyway - I never enjoyed the look I got from the neckless LA security thugs when they found a pair of underpants in amongst my magazines.

Of course 9/11 put an end to carrying a laptop too.  Travelling well is all about making the journey smooooooth.  Unpacking a laptop so they can see it isn’t ticking is one more hassle I don’t need.  Now of course Google Docs has liberated me completely from that little black back-wrecker.  Since airport shops charge more for bottled water than they do for cognac, that put an end to my water bottle as well.  And I outgrew the sarong that served as sheet, bathrobe, flannel and beachwear.  Suddenly there was very little in my carry-on.  Just a New Scientist and some emergency chocolate rations, a passport (no tickets any more), a memory stick with my presentation, and some US bills.  Despite its imminent displacement by the yuan, the greenback is still the lubricant of choice for the traveler who likes to travel smooooth.  Many countries still have a “late fee” or “special processing fee”.  In some places they’ll recognise a buck before they recognise their own currency.

But it feels so un-natural getting on a long flight with next to no hand luggage.  When it comes to packing, I’m a natural Boy Scout.  I want to be prepared for anything.  What if a waiter drops a glass of red wine on me (again)?  Will I have enough spare pants?  It took years to talk myself out of the lunacy of taking along gym gear (anyone who knows me knows how pointless that was).  Spare battery AND a charger for my PDA.  A small pharmacy.  Two extra shirts for evenings.  Shorts and golf-shirt in case someone takes me out on their yacht.  An umbrella (no a small folding one.  What do you think I am?).

After thirty years of adult flying I’ve slowly weaned myself off almost all of it.  But the stress of checking and rechecking never leaves me.  I’d hate to get there and find I needed something I didn’t bring.  A thirty-second act of packing before you leave can save hours of hassle when you get there.  If you are the same way inclined, here are some things to consider for the next Pink Elephant conference:

• books (buying anything with a reading age above 12 is almost impossible in or near the Bellagio)
• flipflops or Crocs or deck shoes, beach shorts and a suitably Caribbean shirt (trust me on this)
• sunnies (on the rare occasions you get outdoors before sundown, it HURTS)
• Vitamin B
• your most outragous set of clothes, so you can blend in when you go for a walk on the Strip
• a Segway

 

Monday, August 09, 2010

ConfBOK: Learning 1.1.1

ConfBOK: the Conference Body of Knowledge.

1. Learning

1.1 Staying Conscious

1.1.1 Environment

I once participated in a sleep deprivation experiment.  They didn’t call it that, they called it International Sales Training.  It was in DFW Airport [I am not making this up].  Since a psychopathic VP was prowling the dark airless hall firing anyone asleep [still not making this up] I took to stabbing myself in the stomach with a ballpoint [and still not making this up] every time my head did that violent drop-and-jerk thing where you slide down the slope and haul yourself back to consciousness reflexively at the last moment.  It worked but I still have little blue tattoo dots on my pot.  Of course I have no idea what the session was about.

Another time, the same company loaded hundreds of staff from everywhere from Australia to Sweden onto a cruise ship and sailed them across the Caribbean with a few hours of classes each day to make it tax-deductible.  Of course I missed that one [I wish I was making this up].  I bet they don’t recall much about those classes either.

The ideal learning environment is somewhere between the two. 

The venue should be comfortable but not too distracting, relaxing but not soporific.  Something like the typical American conference venue decorated in that we-shot-the-only-designer-with-any-taste style that looks like a French Renaissance brothel crossed with a Sicilian gangster’s furniture showroom.  It is certainly not bland and it is now and then so startlingly bad as to jolt you.  Casinos excel at this.

Location is important for mental stimulus.  If the venue is in Louisville Kentucky or Ede Netherlands then the attendees are likely to succumb to boredom.  Hold the training in Atlanta Georgia or Rio de Janeiro and they may not survive the week at all.  Put it in Sydney or ...say… Las Vegas and folk can revive their spirits without becoming one.

 

 

There is NO ITIL v4 coming your way

Social media is a great thing; don’t get me wrong. However, it is an excellent way to spread incorrect information, falsehoods, legends, myths, half-truths, etc.

Recently I have read in a few places “ITIL V4 is coming”. This is NOT the case.

As the “Hitchhiker’s Guide To The Galaxy“by Douglas Adams (1952 - 2001) indicates on its front cover “DON’T PANIC”

As I mentioned above, the ITIL V4 news is one of those incorrect information, falsehoods, legends, myths, and half-truth.

Yes, the ITIL V3 core books are being updated. However, no one is writing ITIL V4.

As I often say, when in doubt, go to the official source. In this case the source is the Office of Government Commerce (OGC)

Read the following document explaining exactly what is being done, why, who is doing this, what is in scope and what is not in scope.

Scope and Development Plan: ITIL® V3 Update

By the way, the qualification scheme will not change. The Examining Institutes, Qualification Board and the Senior Examiners will review the syllabuses/syllabi based on the new version of the appropriate books once the books become available.

So, in the mean time, and deliberately misquoting the great Frank Sinatra “STOP spreading the news, ITIL V4 is not for today”

I leave you with the following closing song lyrics from a Canadian television show called “Wayne & Shuster”. The duo aired on the Canadian Broadcasting Corporation (CBC) between 1954 and 1990 in various shows and specials.

“Well I see by the clock on the wall, that it’s time to wish you one and all… goodbye, so long…?
... farewell, adieu…

Be good (Stay Well) Bye Bye (Keep Warm) Relax (At Ease) Take Care (Stay Loose)
Adieu mon vieux. A la prochaine. Goodbye ‘til when we meet again!”

Thursday, August 05, 2010

Last Few Session Slots To Be Filled!

August-September is always a very busy time for Conference planning at Pink. Between now and the end of this month we need to have all remaining session slots filled. That allows us, in September, to get working on preparing, publishing and distributing the brochure - in paper and electronic formats.

In reviewing where we are with the overall program and the huge variety of topics we want to have covered, we would like to add a handful of sessions on:

• IT Governance & the Cloud
• COBIT
• Chargeback
• Supplier Management

All, ideally, from a practical perspective - someone who’s been there and done that. If that means YOU, or anyone you know, we’d love to hear from you. But hurry, we need to close the program building phase very soon.

Sunday, August 01, 2010

Management Of Change For ITSM:  Hitting The Sweet Spot

Dr. Sue Conger is Associate Professor, Director of IT & IT Service Management Programs, University of Dallas.  Dr. Conger is on the university’s faculty where she manages both IT and ITSM programs, she also has served on itSMF’s Academic Executive Committee and the Steering Committee for itSMF Dallas LIG.

According to Professor Conger, industry best practices, including ITIL, offer what sounds like great guidance until you start to actually do something.  The problems of where to begin seem easy when you begin to ponder exactly what to do and how to do it.  Dr. Conger has learned through her research that some common themes emerge based on an analysis of 12 case studies in the U.S., Germany, and Australia.  The themes relate to how ITSM project managers contextualize their work to optimize its chances for success. 

Her session at the 15th Annual IT Management Conference, Management Of Change For ITSM:  Hitting The Sweet Spot will discuss different approaches taken and why they worked in their particular environments, and will provide guidelines for contextualizing projects based on organizational characteristics.  We asked Dr. Conger a few questions about it to help you with your Session Strategy



What does “contextualizing projects based on organizational characteristics” mean?  Is that about fitting in with the culture?

Contextualizing means customizing whatever is done – project goals, schedule, and design, individuals involved, process designs, policies, software choices, etc. for its specific designed use.  Many organizations do not need to implement all of ‘ITIL’ if they have working processes and are happy with them.  It is important to define goals – e.g., centralization, standardization, or even reduce outages, then meet that goal using whatever processes and services are needed.
Contextualizing also means doing everything to ensure success, including attending to and dealing with political issues as they arise.  Complete agreement with design or the way changes are implemented is unlikely so don’t bother.  It is more important to consciously design and manage processes and services than to worry about doing every ‘shall’ in ISO 20000 or ITIL v3. 

I have a personal passion for getting ITSM to focus on the people aspects of getting things done instead of getting hung up on process, or worse still technology.  Does that resonate with what you have seen in your case studies of change?

Yes, at the end of the day, nothing matters if it doesn’t work for the company or the people involved.  That is part of the contextualizing.  There is a great study published through McKinsey & Co by Dorgan and Dowdy (2004) that clearly identifies bigger payoffs from intense process management over technology management.  Process must precede technology and technology needs to be molded to fit the process in the ideal world.  Therefore, being practical and realistic about what will work in this organization at this time are key concepts.

Some process areas are easier than others.  For instance, sometimes it seems introducing better Change Management is all stick and no carrot: you have to push it through and people only see the benefits once they start participating.  Do you agree?

Yes, as an academic, I’m very aware of research that prescribes attention to culture before change.  But, as an ex-IT manager I’m also aware that you have to get product out the door.  The best implementation I’ve seen (described below) paid zero attention to culture and essentially said ‘change or leave.’  The project mantra was ‘failure is not an option.’  This position was very effective. I’ve always thought adults were children in big bodies.  Therefore, at some point the kids have to be ordered to do what is needed (and own it) whether they like it or not.

How badly wrong can it go?  What sort of range have you seen from best to worst cases?

Well, complete failure is pretty wrong.  Most companies and three of five case companies in the US, three of four in Australia, and 2 of four in Germany all had failed projects before they were successful.  The failures all suffered from combinations of wrong people on the project, lack of organizational commitment, lack of resources, focus on technology rather than process, l, no management support, poor or poorly executed communication plans, change took too long, unintegrated processes,  training and change dates so far apart that people forgot, no followup or post-implementation audits, etc.  In every successful case (the 13 cases in US, Germany, Australia) all of these problems were dealt with specifically by the project teams.  Not all of the dealings were completely successful, but with a range of activity in the ‘sweet spot’ the failings in the successful projects were not fatal.
The best case I’ve seen is a multi-national outsourcer that obtained ISO 20000 certification for 7 locations in four countries in 12 months (including 3 of those months to develop evidence of success).  They then added another 7 locations the 2nd year.  In my opinion, this was like a clean hoop shot from, center court (of course if you don’t know basketball, this analogy is not useful).

How would you sum up your advice to those managing introduction of ITSM improvements?

• Be careful how you define your goal because that is what you will get.  i.e., ‘Failure is not an option’ forces attention to the changes.
• Require an executive team to provide policies, oversight, regular communications, and a kick in the rear when needed.
• Keep the central change group small and ensure diverse skills (i.e., coordination, process design, and change implementation).
• Use participative projects with reps for the project, each process, and staff who do the process from every affected location.  Process owners from affected locations should be responsible for guaranteeing the workability of the process for their location and for ensuring implementation.
• Communicate often about status and expectations.
• Worry less about culture and more about making the changes fit the work context.
• Require every staff member to be trained, be responsible for knowing his/her job and how it fits within the ITSM scheme.  This implies a web-based repository for all policy, process, and work instruction documentation as well as other related ITSM documentations.
• Change the executive and management compensation schemes to include compliance with ITSM changes as part of any compensation and/or bonus schemes.
• Change all job descriptions to use ITSM language (that fits the organization) and institutionalize the changes by rapid movement from ‘my job’ and ‘my ITIL job’ to just ‘my job.’
• Continuous monitoring and improvement are critical to avoid entropy and regression to the earlier state.

Looks like this is one session to add to your list!