Friday, June 4, 2010

ITIL: H2I - Chapter the Fourth - When Squares Become Circles

The Hitchhiker’s Guide to ITIL – EXAM Preparation Guide

Introducing the Service Lifecycle Model
Probably one of the biggest changes made to the ITIL library when comparing it to previous versions is the introduction of the service life-cycle concept. Where earlier versions seemed to be a bit of a service management hotchpotch – this version, labeled ITIL v3 is clearly more structured and guides the reader from service strategy all the way 'down' to service operation, and clearly emphasizes the importance of continual service improvement.

The five volumes that make up the Service Lifecycle are:

  • Service Strategy

  • Service Design

  • Service Transition

  • Service Operation

  • Continual Service Improvement


As with everything else in our world, things have a beginning and most often also some sort of ending. Where and when ITIL will end (if it ever does) is only known to those with the gift of foresight, but when and where it started is crystal clear. We’ll have to go back to the late 80s, and more precisely we’ll have to go to the United Kingdom to a place called Norfolk.

It all started with the CCTA – the Central Computing and Telecommunications Agency – collecting and publishing “best practices” on how to setup and manage IT environments. The first set of publications was released late 80s and had more than 40 volumes in it. This first set worked pretty well for IT environments as they were used in the late 80s: “mainframes and dumb terminals”. With the rise of the 90s “best practices” in IT started to change and they changed dramatically. PCs, LANs, WANs, distributed computing, the almighty Internet, even mightier e-commerce and outsourcing were new phenomena that just didn’t (to most people) exist in the 80s. In other words, there were many valid reasons to rewrite the ITIL publications as written in the late 80s, and to release a new set of volumes in the late 90s. This new set consisted of 9 loosely connected volumes. With the change from ITIL v1 (late 80s: 40+ volumes) to ITIL v2 (late 90s: 9 volumes) CCTA decided to change their name into OGC: The Office of Government Commerce.

Office of Government Commerce: http://www.ogc.gov.uk

By now, ITIL (Information Technology Infrastructure Library) had gained a lot of popularity and was known and used by many public and private organizations around the world to increase the efficiency and effectiveness of delivering services to their customers. The ITIL v2 model was basically a big square (rectangle) depicting the nine (9) volumes in various states of overlap and synergy. An interesting fact remains that most ITIL courses were constructed around only 2 of the 9 volumes from the ITIL v2 set, hence its full potential was never fully utilized or understood.

When Squares:



The story continues in much the same way when we’re extending the time line from late 90s to late 00s (2007). Because of changes business models, changing technologies, and changing “best practices” ITIL needed to be rewritten again, hence ITIL v3 was born. This time the set only contains 5 core volumes (the ITIL core set), but the main difference compared to the previous two ITIL versions is that ITIL v3 no longer consists of loosely connected volumes, but of tightly connected volumes. It’s almost impossible to read any of the 5 books in isolation, because it’s really just one book cut in 5 digestible pieces – well at least that’s my opinion. I guess OGC cannot sell ITIL as one volume, otherwise it would hardly be a library anymore!

Become Circles:



It's also interesting to note that when ITIL v2 was rewritten, the new version was labeled ITIL v3 Refresh. Unfortunately there are so many typos and inconsistencies in the ITIL v3 Refresh version, that it's currently been 'rewritten' again. The new version is labeled ITIL v3 Refresh Refresh - I wonder why it's not simply called ITIL v3.1 (like CobiT 4.1). Why make things really simple if you can make them really complex and confusing! I believe that adoption rate of any framework is directly related to its simplicity, but then again, who am I?

The Service Lifecycle
The Service Lifecycle is quite an ingenious model, and makes absolute sense. Before you start to do anything you need strategy, direction, focus and yeah - some money too (Service Strategy). What type of services are we going to provide, and do we have the resources and capability to provide them? How do we transform our IT assets into added value to the business?

If we all agree what type of services we want to deliver, then the next step is to ensure the infrastructure will be capable to deliver against the requirements as identified in the strategy. In other words we need to design (and plan for) (Service Design) our new or changed services. We need to plan for capacity, availability, information security, and service continuity (disaster recovery management).

Once we’ve established how we’re going to deliver the new or changed services, and we’ve ensured all capability can be catered for (people, processes, products, and partners), it’s time to handover to that part of the organization who will manage the transition from the “old” infrastructure to the “new” infrastructure (Service Transition). It’s the service transition processes and functions that will manage the full-blown change related processes (and its associated functions), such as Change Management, Service Asset and Configuration Management, and Release and Deployment Management.

Service transition will also need to plan for the handover from project environment to operational/production/live environment. Once the new or changed service is implemented and live it needs maintenance and ongoing support. The operational processes, like Incident Management, Problem Management, and the function Service Desk provide just this type of support (Service Operation).

Many organizations work with the phrase: “If it ain’t broken don’t fix it!” ITIL uses a different type of phrase: “If it ain’t broken, can we still improve it, without breaking it, and doing so in a cost-effective way?” The second phrase is likely to put you in a more competitive advantage, where you’re continuously improving, and your competitor isn’t. In other words, we need to create a culture and structure that supports continual service improvement (Continual Service Improvement). We need to implement and run a continual service improvement process that keeps us on the tip of our toes at all times! All processes, functions and roles in all ITIL books should be open minded towards improving whatever they’re already doing.

ALICE: Our famous hotel chain “Constellation Hotels” is bombarded with questions from their customers who would like to book their accommodation online. Currently bookings can only be made via telephone, fax, or hotel reception (walk-in-facility). How would you progress through the various stages of the Service Lifecycle to add/upgrade services to the current environment? Who is doing what, and why?

Service Lifecycle Structure
The structure of the core five volumes is in the form of a (service) lifecycle. It is iterative and multidimensional (well, that’s what it says in the book). Sounds pretty groovy: multidimensional! The core provides structure, stability and strength to Service Management capabilities with durable principles, methods and tools. The guidance can be adapted and adopted by all organizations, small and large, public and private, commercial and not-for-profit.

The ITIL core consists of the following five publications:

  • Service Strategy (most left picture below),

  • Service Design,

  • Service Transition,

  • Service Operation, and

  • Continual Service Improvement (most right picture below).





Service Lifecycle Components
The ITIL Library consists of the following components:

  1. The ITIL core – best practice guidance applicable to all types of organisations who provide services to a business.

  2. The ITIL complementary guidance – a complementary set of publications with guidance specific to industry sectors, organisation types, operating models and technology architectures.

  3. The online web resources.


ITIL's key online web resources can be found here: http://www.itil-officialsite.com


Service Strategy

Service Strategy Goals:

  • To support the organisation in transforming service management into a strategic asset.

  • To provide a clear insight into the relationships between various services, systems, processes, business models, strategies, and objectives.


Service Strategy Objectives:

  • What services should we offer, why and to whom?

  • Surely we don't want to look like our competitors, so how are we going to differentiate ourselves?

  • At when moment in time will the customers perceive our services as to be valuable to their business?

  • How do we capture and grow this value?

  • What type of business case do we need to prepare for this specific investment?

  • How can finance support us to have insight into the costs of delivering services?

  • How are we going to define quality? How do we measure it?

  • Which of the alternatives is the very best given our specific situation?

  • How do resource the services (buy, make, rent, outsource, etc.)

  • How do we keep everyone happy (resolve conflicting demands for resources)?


Service Strategy Business Value:

  • We actually know what we're going to do

  • We know the best order in which to do these things

  • We understand the costs and risks of what we're going to do

  • We'll make sure we're ready to deliver when push comes to shove

  • We'll be different and unique in the things we're doing

  • We make sure that the business noses and IT noses point in the same direction (business and IT alignment)


Service Design

Service Design Goals:

  • To design new or changed services for introduction into the live environment. Taking into consideration the impact on the overall service, management systems and tools, architectures, technology, service Management processes, measurements and metrics.


Service Design Objectives:

  • To ensure that new or changed service is consistent with all other services.

  • To ensure that technology architectures and management systems are consistent with the new or changed service.

  • To ensure that processes, roles, responsibilities and skills have the capability to operate, support and maintain the new or changed service.

  • To ensure that existing measurement methods can provide the required metrics on the new or changed service.


Service Design Business Value:

  • Reduced Total Cost of Ownership (TCO)

  • Improved quality of service

  • Improved consistency of service

  • Easier implementation of new or changed services

  • Improved service alignment

  • More effective service performance

  • Improved IT governance

  • More effective Service Management and IT processes

  • Improved information and decision-making


Service Transition

Service Transition Goals:

  • To assist organisations seeking to plan and manage service changes and to deploy service releases into the production environment successfully.


Service Transition Objectives:

  • To plan and manage change related resources

  • To minimise unpredicted impact

  • To increase satisfaction amongst all staff

  • To increase proper use of the services

  • To provide plans that align customer and business change projects with the Service Transition plans


Service Transition Business Value:

  • Improved cost, timing, resource and risk estimation

  • More successful change

  • Change easier to adopt and follow

  • Reuse of assets across projects and services

  • Reduced delays from unexpected clashes/dependencies

  • Reduced effort spent managing test/pilot environments

  • Improved expectation setting

  • Increased confidence

  • Maintainable and cost-effective services


Service Operation

Service Operation Goals:

  • To coordinate and carry out the activities and processes required to deliver and manage services at agreed levels to business users and customers.

  • Service Operation is also responsible for the ongoing management of the technology that is used to deliver and support services.


Service Operation Objectives:

  • Day-to-day operation of processes:

    • Conduct

    • Control

    • Manage



  • Systemically:

    • Monitor performance

    • Assess metrics

    • Gather data




Service Operation Business Value:
Each stage in the ITIL Service Lifecycle provides value to business.

  • Service value is modeled in Service Strategy.

  • Cost of the service is designed, predicted and validated in Service Design and Service Transition.

  • Measures for optimization are identified in Continual Service Improvement.

  • Service Operation is where these plans, designs and optimizations are executed and measured.

  • From a customer viewpoint, Service Operation is where actual value is seen.


Continual Service Improvement

Continual Service Improvement Goals:

  • To continually align and realign IT services to the changing business needs by identifying and implementing improvements to IT services that support business processes.

  • To continually look for ways to improve process effectiveness, efficiency as well as cost effectiveness.

Continual Service Improvement Objectives:

  • Review, analyze and make recommendations on improvement opportunities

  • Review, analyze and make recommendations on Service Level Achievement results

  • Identify and implement individual activities to improve

  • Improve cost effectiveness of delivering services without sacrificing customer satisfaction

  • Ensure applicable quality management methods are used


Continual Service Improvement Business Value:

  • Tangible:

    • Improvements

    • Benefits

    • ROI (Return on Investment)

    • VOI (Value on Investment)

    • Intangible:



  • Increased organizational competency

    • Integration between people and processes

    • Reduction of redundancy increases business throughput

    • Minimized lost opportunities

    • Assured regulatory compliance that will minimize costs and reduce risk

    • Ability to react to change rapidly


Live long and prosper

Nanoo... Nanoo...

IsleBeeBach

ITIL ® is a Registered Trade Mark, and a Registered Community Trade Mark of the Office of Government Commerce, and is registered in the U.S. Patent and Trademark Office.

Sunday, May 16, 2010

IT GOVERNANCE: Battle of Giants

Battle of Giants

Preface
Yeah, it’s time for yet another article. I’ve just consumed my daily doses of caffeine and somewhere in the background the wonderful harp music of Andreas Vollenweider is doing its magic. Magic, a curious thing – I wonder how that applies to something like service management (and “yes” I’m still dropping the IT). Can magic be found in frameworks, standards and methods? I believe the answer to be positive; it all depends on how one observes the world. I ‘recently’ stumbled upon (which is also a fantastic tool: stumble upon) the world of IT governance (feel free to drop the IT again), and jeepers creepers I felt like walking into Ali Babi’s cave filled with unspeakable treasures. Join me; enter the cave and who knows we might even find some magic lamps.

Introduction
The reason this article is called “Battle of Giants” is twofold. Firstly it sounds pretty groovy and hopefully visualises battles like the ones you find in “Return of the King” where the good guys are fighting the bad guys with enormous battle-axes, lances, and catapults. Secondly, because I’m thinking a bloody battle between the following giants: OGC and ISACA/PMI. Yeah, call me weird and join the crowd. For those that still don’t have a clue: OGC owns ITIL and Prince2, ISACA owns CobiT and Val IT, and PMI owns PMBOK. OGC is based in the UK, and both ISACA and PMI are based in the US. Did I just see you raise your eyebrows, or at least one, like Mr. Spock?

  • OGC, ITIL and Prince2

  • ISACA, CobiT and Val IT

  • PMI, PMBOK


Yes, Father, I have sinned, as I no longer believe ITIL and Prince2 are the only truth, and feel tempted to join these other religions called ISACA and PMI, as they have more structure and seem to make a Hell lot of more sense as frameworks. Please guide me, for I have lost my way and need your advice.

Well, in this article we won’t be assessing all these frameworks, but will be focusing on ISACA’s cave of treasures. Surely, I need to give myself some space for sequels, prequels, and those that fall somewhere in between (the sneaquels, as they seem to sneak in between episodes).

ISACA’s Cave of Credits
I used to be a member of the itSMF for many years, but recently decided to swap my membership to some other organisations including ISACA and PMI. Sure, the itSMF can claim until the end of time that they’re not fully ITIL and OGC aligned, but “hey presto” they’re doing a lot of ITIL, seem to backup a lot of OGC and aren’t really doing so much of the other stuff, and hence I felt it was necessary to step into the dark side’s territory and explore some new forces firsthand. To be honest I’m glad I did and not a moment too soon!

Admitted both ISACA’s and PMI’s websites are pretty crappy, although ISACA is about to launch their revamped website. They’re both ugly ducklings from the outside, but it’s funny because once you’re on the inside you get immediate access to all the prices, and the ugly duckling turns into a beautiful swan (like the lake Geneva (CH) swans). It’s like looking at a Citroën 2CV (deux chevaux) with a Ferrari engine under the bonnet. Everything you can’t find with (or would expect to come from) the itSMF or OGC you can find with ISACA and PMI and most importantly at a reasonable and affordable price, meaning you don’t have to pay ridiculous amounts like £5,000 per annum for something that’s basically all based on using your common sense and a teaspoon of yin-yang and logic. ISACA and PMI are not offering crappy 2-page newsletters (sorry itSMF) that are filled with advertisements of overpriced consultancy agencies and delivering-no-quality-whatsoever training organisations, but are offering real journals (magazines) with articles that provide sincere value and are actually interesting reading material too. I’m sure itSMF will become aware of this article at some time any maybe it will open their eyes, and maybe, just maybe, they will follow ISACA/PMI’s example and start publishing a real IT Service Management Journal without all those crappy advertisements. Ah well, it’s just a lone ranger’s thought! It’s funny as it’s all about providing value to customers – or isn’t it?

So, should you become a member of ISACA (IT Governance) and PMI (Project Management Institute)? I believe you should, and rather sooner than later, and hey I don’t have anything to gain by saying this, and merely am trying to share my experience with you my loyal readers out there.

Entering the Cave
ISACA offers a number of accessibility options to their materials. The easiest one is to hop on their website (http://www.isaca.org), register for absolutely zilch, nada, nothing and immediately get access to a number of their most important publications being CobiT v4.1 and Val IT 2nd edition – this is known as “basic subscriber” membership. The CobiT v4.1 and Val IT 2nd edition documents become available as downloadable PDFs, and it feels like downloading ITIL v3 for free. If you don’t like ITIL’s somewhat unorganised structure, then you’ll be most happily surprised with ISACA’s documents. I can safely and confidently say that CobiT v4.1 has exactly 34 processes that allow you to put more control and governance in place in those areas of IT where it is most needed. If you ask me how many processes ITIL v3 has, then honestly I can’t give you a clear answer, and that doesn’t make any sense as I’m allowed to call myself an ITIL v3 Expert, which at that moment seems to lose a lot of its intrinsic value. So, to make a long story short, there are heaps of ISACA resources available to those who take a couple of minutes filling out a form with their name and address, and Bob will be your uncle in no time at all.

ISACA also offers a “baseline” access model, which means you don’t’ even have to fill out a form and still get access to some documents, including CobiT v4.1. I guess for those taking the effort of typing in ISACA’s full URL in a browser, filling out a simple form to become a “basic subscriber” is probably valuable considering all the extras you get access to. For me, personally, I wouldn’t even consider the “baseline” access model, unless you don’t want your full name in their database, but in that case you probably shouldn’t be working in IT al all. Surely you’re aware that Big Brother is watching your every step.

So, at the lowest level we’ve got “baseline” access (casual website visitor), the next level up is known as “basic subscriber” access (filling out a form with your name), and the most complete type of access is granted when you become a “full subscriber” (paying an annual subscription fee). As a full subscriber you’ll get access to the full ISACA cave, except one small crevice that’s labelled “CobiT Online”, but by the time you decide to become a full member you’ll most likely also tick this box.

Here’s a small list you get access to when you become a “full subscriber”:

  • invitations to local seminars, conferences, and chapters
  • ISACA Journal (magazine both mailed to you, but also available electronically)
  • benchmarking capability
  • browse CobiT, including Control Practices and Quickstart entries
  • download all PDFs

    • CobiT Quickstart

    • CobiT v4.1

    • CobiT toolset (slides, maturity assessments, the works!)

    • CobiT Mappings

    • Search and create MyCobiT

    • Val IT 2nd edition

    • Board Briefing on IT Governance

    • IT Governance Implementation Guide

    • IT Assurance Guide

    • Access the discussion area




The list of files that can be downloaded just goes on, and on, and on. I can’t tell you how surprised I was when I compared this to “all” the resources made available by organisations like the itSMF and OGC, which is literally close to nothing – even if you’re a paying member. Ah well, one lesson learned for me; don’t judge on organisation by its appearances (website) only.

Exploring the Cave
Funny isn’t it – you walk into a cave, holding your flickering torch high in front of you, expecting to find nothing, as this is what happened to me on countless explorations before, and all of a sudden you start to see the shimmering reflections of rubies, emeralds, sapphires, and diamonds. Where do I start, and how much weight (treasures) can I carry, or am I allowed to carry with me?

Well, we’ll start by mentioning that ISACA and ITGI (IT Governance Institute) have a lot in common (and that’s a grand understatement) as they’re both about IT governance which is defined by them as:

“IT governance is the responsibility of executives and the board of directors, and consists of the leadership, organisational structures and processes that the enterprise’s IT sustains and extends the organisation’s strategies and objectives.”

You start wondering why all these organisations come up with these wonderfully artificially constructed sentences that in all reality no-one uses. They probably have a secret well hidden room where people (nope, I don’t want to go into stereotypes right now) spent most of their lives creating cryptic definitions, so we have something to decipher. I guess what I’m reading between the lines is this:

“IT Governance means that people need to be held accountable and responsible for their actions, need to understand why they are doing (IT) things the way they are doing them, and foremost keep doing the right (IT) things (now and in the future).”

Did that help? Probably not! Yeah, I’m laughing out loud! So, it’s roughly about ensuring that the right people are doing the right things for the right seasons (typically creating some type of value to the business) and whilst doing so managing risks adequately. No, it’s not always about minimising risks, because not all risks are negative, and some residual risk may well be accepted by the business. Some risks represent opportunities and can be extremely positive. Come on, those Google guys took some risk leaving University a bit too early, but no one is blaming or pointing the finger at them now!

Okay, I think we’re going a bit off track here and that’s something you don’t want to do when you’re wandering through the “IT governance” cave, as this cave is all about putting control in place, so you know exactly where you are and where you’re heading towards at every single moment in time. IT governance is the set of “minimum” internal and external rules, standards, policies, and guidelines you apply to the management of your IT (yeah, that too). IT is getting incredibly significant and business critical to an ever increasing number of organisations around this tiny blue planet, and without the right set of controls in place it will be virtually impossible to reap the full benefits of IT and its supporting infrastructure. Worse, without proper controls in place, IT may actually damage the business beyond repair, which reminds me of a list of credit-card numbers that was publicly published on the Internet not so long ago.

The Val IT Crevasse
It’s funny as many of ISACA’s resources seem to be in orbit (at least in my opinion) around CobiT, whereas maybe, just maybe, they should actually be in orbit around Val IT. I guess orbit and CobiT seem more related, in characters only, than orbit and Val IT. Nope, that can’t be right and it isn’t hence some things are about to get changed bit time (see Area 51).

Val IT is all about creating, monitoring and optimising value from IT investments with an acceptable level of risk. Val IT sets good practices for the ends: “This is what we need to achieve as a business – if we don’t then we’re in deep sh#@”! Well, please tell me, are we doing the right things and are we reaping the needed and expected benefits? Again, this is Val IT space! Its whole focus is aimed at strategic management levels so strategic value can be harvested.

Val IT covers three key domains:

  1. Value Governance [VG] (embeds the governance framework into the organisation)

  2. Portfolio Management [PM] (ensures the right programmes are selected to be added to the portfolio of products and services)

  3. Investment Management [IM] (ensures that selected programmes are funded, implemented and able to provide bang-for-the-buck)


Val IT is also about ensuring that any governance as applied to IT (wherever, whenever, whoever) is properly aligned with the broader Enterprise governance of IT (wherever, whenever, whoever). Val IT’s focus is on selecting and driving the right programmes that create value to the business. It provides three domains (see above), 22 processes and a whopping 69 management practices to help management get on their way and hit the ground running. Personally I absolutely adore this framework as it tells me exactly what needs to done in order to be able to answer the following two key questions:

  1. Are we doing the right things?

  2. Are we getting the benefits?


This framework doesn’t leave any ambiguity as where and how to start unlike the ITIL framework. Yeah, this needs to be said: ISACA answers the “what needs to be done!” question, whereas frameworks like ITIL, MOF and their brethren are more about filling in some of the “how to do” things. As such ISACA’s Val IT framework needs to be visualised as sitting on top of these other frameworks (and driving them), and I believe it makes sense to look at Val IT and CobiT before looking at frameworks like ITIL and MOF. We need to understand what needs to be controlled and protected, before we start to run around like headless chickens controlling and protecting the wrong stuff!


Figure 1 - Val IT and CobiT

The CobiT Crevasse
So, yeah, most of ISACA’s documents and resources seem to be in orbit around CobiT (I somehow seem to like using these two words close together: “CobiT Orbit”). So, what’s this CobiT thing all about? It’s probably easiest when you compare CobiT to Val IT. Whereas Val IT revolves around “strategy” and “value”, CobiT revolves around “architecture” and “delivery”. So basically CobiT sits one level below Val IT, and frameworks like ITIL and MOF are positioned below CobiT. I know, ITIL is trying to raise the bar into strategic spheres, but it’s not there as yet, and the current ITIL v3 volume “Service Strategy” needs a major rewrite before it even comes close to Val IT’s potential.
CobiT is basically about putting program results (as selected by Val IT) into the live environment so they (read the individual projects) start to deliver value and keep delivering value.

CobiT covers four key domains:

  1. Plan and Organise [PO] (Ensuring IT contributes to the achievement of business objectives by planning and organising the right solutions/projects)

  2. Acquire and Implement [AI] (Identifying, implementing and integrating solutions/projects)

  3. Deliver and Support [DS] (Delivering and supporting IT services)

  4. Monitor and Evaluate [ME] (Managing and monitoring performance, compliance and governance)


CobiT’s focus is twofold, but can be summarised as providing a business focus (linking business goals to IT goals) and process focus (being able to plan, build, run and monitor IT). CobiT fulfils the business need for assurance about the value of IT, the management of IT-related risks and increased requirements for control over information. Please realise that value, risk and control constitute the very core of IT governance.

CobiT provides four domains (see above), 34 processes and a whopping 210 control objectives. Please notice the subtle difference in terminology used here: Val IT refers to management practices, whereas CobiT refers to control objectives. In all reality both tell you what needs to be done, or reading between the lines: “get your lazy bum of the chair and start to take some action!”
CobiT rocks, as it tells me exactly what needs to done in order to be able to answer the following two key questions:

  1. Are we doing them (the right things) the right way?

  2. Are we getting them (the right things) done well?


It’s not easy, not easy at all, to write a final paragraph on this section that covers CobiT, as it merely provides you with a glimpse of its enormous potential.

Ask yourself the following questions:

  1. Do I really understand where I can gain optimal value from IT?

  2. Do I understand the financial impact and the risks that are inherently associated with IT changes?

  3. Am I able to deliver and support IT to a level that satisfies the business?

  4. Am I able to measure how, where and when IT adds value to the business and business strategy?

  5. Do I know how our business performs compared to similar organisations in my industry, and is that performance good enough?


After studying CobiT and Val IT for some time now, I’ve come to the conclusion that CobiT can actively assist you in answering the above mentioned questions, and that’s just scraping the tip of the iceberg!

Area 51
Anyone that knows me a little bit, knows I’m a huge fan of anything science fiction, and hence my interest for Area 51. Come on, who wouldn’t want to meet some three-headed green aliens, or an alien like Alf (I’m sure Alf’s producer didn’t like cats very much)? ISACA is a bit like Area 51, and those caves of Ali Baba, with all its treasures about to be unearthed. Oh, and yes, there’s another reason why I’ve called this section Area 51. At this moment of writing ISACA has announced that it will start working on the next release of CobiT – my guess is that it’s going to be called CobiT v5.0 (or ValCobiT v5.0). As CobiT v4.0 quickly got an update to CobiT v4.1, I assume the same will happen to CobiT v5.0, and voila we’ve landed in Area 5.1. It’s my understanding that the merger of CobiT and Val IT into one integrated framework will be a key feature of this new release. Maybe it’s time to apply some SOA (Service Oriented Architecture) principles to frameworks, and make them more flexible, modular and extensible. I recommend anyone to keep a close eye on the movements of this update, as with some of the how-s answered, this framework has all potential to make the gap with its competing brethren a lot wider, and you’d better make sure you’re on the right side!

Epilogue
The positive effects of my daily doses of caffeine are slowly but surely diminishing, so now is as good a time as ever to leave Area 51 and Ali Baba’s caves behind us. I hope some of my passion for CobiT and Val IT has come across to you. I believe these two frameworks have an enormous potential as yet undiscovered by many boards and senior executives who not unlike most other lemmings follow the ITIL scent. Make sure you understand and use the full potential of all these available frameworks. To those senior executives who may be reading this article I recommend having a look at the “CobiT Related Publications - Board Briefing on IT Governance, 2nd Edition” document as downloadable PDF from ISACA’s website. May the force be with you, and CobiT guard you on your path to extreme success and happiness.


Glossary of Terms










OGCOffice of Government Commerce
PMIProject Management Institute
PMBOKProject Management Body Of Knowledge
PRINCE2PRojects IN Controlled Environments 2
ITILInformation Technology Infrastructure Library
VAL ITEnterprise Value Governance of IT Investments
MOFMicrosoft Operations Framework
ITGIInformation Technology Governance Institute
CobiTControl Objectives for Information and related Technology


References
http://www.itgi.org
http://www.isaca.org
http://www.itsmfi.org
http://www.pmi.org

Live long and prosper

Nanoo... Nanoo...

IsleBeeBach

Wednesday, March 24, 2010

ITIL: H2I - Chapter the Third - Where some things are revealed and others have to wait a wee bit longer

The Hitchhiker’s Guide to ITIL (H2I) – EXAM Preparation Guide

Welcome back! I'm glad you've decided to follow more of my silly articles. In this article I'll be introducing ALICE. Yeah, I can hear some of you out there already: Alice, who is Alice? Alice is your buddy (Artificial Life-form Intelligent Cyberspace Entity) who introduces you with many small case studies and also has the nasty habit of asking questions, typically at the most inconvenient and inappropriate times.

As the author, I’m pretty sure ALICE wears a blue and white dress, is constantly chased by a fluffy, but extremely vicious rabbit (also referred to as CO-rabBIT), who for some unclear reason also lost its white gloves somewhere in this publication – maybe you can find it back! Poor rabbit!

Okay, enough now! Let’s start to look at ITIL v3 in more detail.

Service Management as a practice

Definition of Service Management: Service Management is a set of specialized organizational capabilities for providing value to customers in the form of services.

A traffic control officer actually provides a great service. Why? Well, first of all he/she has the knowledge, training, and understanding of traffic laws and traffic control. The value he/she provides is in a mostly intangible form, which is guiding you where to go and preventing you from ending up in accidents. That’s quite a positive outcome. So the traffic controller actually adds value to your existence.

In other words Service Management is all about having the ability to do (activities) something and being able to provide something (outputs) to someone (your customers/clients). Of course that something should add some value to that someone, otherwise it’s pretty much a waste of time and resources. Putting a traffic control officer in the middle of a dessert without any traffic seems pointless – the service will be short-lived.

Services have a number of special characteristics that typical products don’t seem to have:

  • Intangible nature of the output and intermediate products. You can't really pickup a service and drop it on someone's foot. Cinema theaters are providing a great service, but you don't walk out with a movie now do you? No, you walk out with an experience and hopefully this experience is perceived by you as valuable, because -hey- you did pay $15 for your ticket into the cinema.

  • Demand is tightly-coupled with customer’s assets. If you buy a new DVD-player and for some reason it doesn't play your favorite DVD ('Spirited Away'), then surely you would like to go back to the shop and get it exchanged or 'serviced'. You wouldn't ask for a DVD player to be serviced if you don't have one! So, services and assets often go hand-in-hand, or at least have a very tight relationship with each other.

  • High-level of contact for producers and consumers of services. If I work in an organization, and my PC breaks down, then guess what, I call the Service Desk. I'll need to explain and communicate my error to the Service Desk, because otherwise they won't be able to support me properly. They may not be able to fix it immediately and calls may go to-and-fro for some time, before a workaround or solution is provided, hence there's heaps of contact between me the consumer (PC-user) and them the producer (the IT organization).

  • Perishable nature of service output and service capacity. If the Service Desk is able to fix my PC's error, then surely that exact same call will never ever repeat itself. Even if my PC breaks down tomorrow with the same issue, then the support I may get from the new Service Desk Analyst will not be the same, even the same Analyst may be in a slightly different mood and the service won't be the same. In other words, the outputs don't last very long and are often created real-time, and "in-the-moment".

[ALICE:] Think of at least three services where you can find examples of all the service characteristics as explained above.

Concept of Good Practice

How do you become a millionaire? Well, some say that looking at someone who is successful and building up an understanding of how they became so successful is a giant step in the right direction. Learning from their success and avoiding their mistakes may well save you from being embarrassed down the track. Why reinvent wheels, if a full bullet-proof and well maintained design is there and available to everyone’s use?

That’s ITIL for you!

Periodically OGC (The Office of Government Commerce) captures good and world’s best practices, and documents these practices in a library of books, hence Information Technology Infrastructure Library. Why not adopt these good and best practices that are already widely in use, rather than investing and using your own resources, energy and capital developing them from scratch? Use ITIL or, for that matter, any other public framework, available standard, or your own organization's proprietary knowledge (IP: Intellectual Property) and leverage of the knowledge and skills already available. It just makes sense, doesn’t it?

[ALICE:] Why do people use maps to get from A to B?

[ALICE:] What would happen if all plugs worldwide would not be manufactured according to set standards?

[ALICE:] How can I play croquet without a set of clear rules? You know how bad tempered the queen of hearts can be!

Concept of a Service

A service is quite a strange thing! You can buy the same car from two different car dealers, but the service can be quite different. You can book the same holiday from two different travel agencies, and again the personal experience is most likely not quite the same. One offers you a nice cup of coffee while you’re waiting; the other seems to ignore you completely. Some schools and hospitals have a better “name” than others, whilst the products they are providing are still pretty much the same. It’s the services and their attitude towards delivering services that give some organizations a good, and others a bad reputation. As the author I even believe, no better I'm convinced, that a set of good services can make or break your organization!

Definition: A service is a means of delivering value to customers by facilitating outcomes customers want to achieve without the ownership of specific costs and risks.

Nowadays, services can make or break many organizations, and the importance of delivering high quality, consistent, repeatable, and measurable services hasn’t seen the light at the end of the tunnel as yet. Many organizations have finally come to the conclusion that delivering good, if not excellent, services is vital to their very existence and survival.

[ALICE:] Do you remember the worst and best service ever delivered to you? What organization pops up in your mind right now? One theory (coming from psychology) tells you that you’re most likely to remember your worst service and your last service, but not necessarily your best service! Think of the consequences this theory may have on your own organization!

A service has the following four characteristics:

  • Intangible nature of the output and intermediate products.

  • Demand is tightly-coupled with customer’s assets.

  • High-level of contact for producers and consumers of services.

  • Perishable nature of service output and service capacity.

Yeah, we've seen those already, and they are key to your understanding of what constitutes a service. Make sure you know these for your exam okay?

Concept of Service Management

So, what is Service Management, and why do I, the author, think that IT Service Management is 100% interchangeable with ITIL. Well, it’s already in the words, or isn’t it? Service Management is all about managing services, from cradle to grave, from inception to disposal, from idea to capability to deliver. The capabilities to deliver a service take the form of functions, processes and roles for managing the service over a well designed life-cycle: The Service Life-cycle!

So, basically IT Service Management is about creating the right mix of processes, functions and roles, supported by the right set of infrastructure to deliver quality (Specific, Measurable, Agreed, Realistic and Timely) services to customers.

Service Management is also a:

  • Professional practice supported by an extensive body of knowledge, experience and skills (also see http://www.itsmf.org).

  • Global community of individuals and organizations in the public and private, profit and not-for-profit sectors.

  • Career path with a plethora of training and worldwide recognized certifications available.

Definition: Service Management is a set of specialized organizational capabilities for providing value to customers in the form of services.

Traditionally Service Management has its roots in business environments like airlines, banks, hotels, and phone companies. As we have become, and are still becoming, more and more dependent on IT, it is exactly this industry “Information Technology (IT)” that is now adopting Service Management practices with an ever increasing speed and enthusiasm.

So, ITIL helps you to better understand, plan and manage your services, and that’s what Service Management is all about, just like the Microsoft Operational Framework (MOF), Control Objectives for Information and related Technology (CobiT), and all these other Service Management frameworks and methodologies. Remember that ITIL is not a methodology, but a flexible framework that should always be approached with an "IT DEPENDS" mindset and attitude.

ITIL IS NOT A METHOD, STANDARD, BIBLE OR KORAN - IT’S A FRAMEWORK!

As the author I use the terminology ITIL and Service Management (no, I don’t even refer to IT Service Management anymore) interchangeably, as I’m convinced we’re actually talking about the same thing. This book and its accompanying ‘mind boggling and fantastic’ interactive distance education subjects is not exclusively about ITIL, it’s about managing services, it's about Service Management, and in the end, it's all a form of applying common sense Total Quality Management (TQM) principles.

[ALICE:] Please use your favorite search engine and look for TQM and see if you can find the core principles on which TQM's philosophy is built.

Functions, Roles and Processes

Functions

Definition: Functions are units of organizations specialized to perform certain type work and responsible for specific outcomes.

The definition of a function is a bit of a strange one really. I guess what the authors were really trying to say is: “A function is a bunch of people roughly performing the same tasks, so why not put them together in a room somewhere!”
Functions build up their own skills and knowledge (and attitude as well). Functions also provide structure and stability to organizations. We people like to be labeled, and we also like to know what to do, and where to do it.

Examples of typical business functions:

  • Human Resources

  • Public Relations

  • Finance

  • Administration

  • Marketing

  • Sales

  • Manufacturing

  • Management

  • Legal

  • Shipping

  • Processing

  • Orders

  • Research and development

  • Logistics


Examples of typical IT functions:

  • Service Desk

  • Network support

  • Application support

  • Midrange

  • Desktop team

  • ERP

  • A pair of white gloves

  • CRM

  • Telecommunication

  • IT Operations

  • Facilities

  • Messaging

  • wIntel team

  • Blackberry team

  • Mainframe

[ALICE:] See if you can think of 7 more generic business functions, and 7 more specialised IT functions.

Roles

A role is roughly a description of tasks to be performed by a person, team or group. It’s the stuff that needs to be done by someone. Anyone with the right skills, knowledge and attitude that fits the role description should be able to step into the role.

Definition: A role refers to a set of connected behaviors or actions that are performed by a person, team or group in a specific context.

[ALICE:] Could you think of the various tasks performed by a nurse? Would you be able to step into the role of a nurse with your current skills, and knowledge? Would you also have the right attitude to perform the job (=role) of a nurse?

So the trick is to match the right individuals to the right roles, and that’s exactly what human resources is all about, and what job agencies do for a living.

Processes

The definition that’s provided in the ITIL v3 books is a lot of waffle! It’s not incorrect, but very academic, and too heavy for its purpose. The old definition as provided in ITIL v2 was actually more useful: “A process is a set of interrelated activities and/or sub-processes to achieve a common goal.” In other words it’s the stuff you do (or sometimes machines and/or computers do) to achieve, create or deliver something!

Definition: A process is an example of a closed-loop system because it provides change and transformation towards a goal and utilizes feedback for self-reinforcing and self-corrective action.

[ALICE:] Say you’re a large car and motorbike manufacturer, like Honda. What is transformed into what? What do you think are Honda’s goals? What type of feedback will Honda receive from its customers? What type of self-corrective actions do you think exist in Honda’s car and motorbike manufacturing plants?

The Process Model

The process model is an extremely useful and powerful, but highly underestimated and underutilized model. Many organizations make a huge and often very expensive mistake and start at the wrong level of the process model. They either start to perform many uncoordinated activities (level 2), or buy a fancy new tool (level 3) and make the wrong assumption that the new tool is going to resolve all their issues. When you automate non-existing and non-documented processes without clear ownership, objectives, roles and responsibilities, you get automated chaos! Please realize that a fool with a tool is still a fool.

The process model has three main levels. The first level is process control (level 1), and this is the level that should be looked at first. It’s at this level that a process owner will be assigned, and objectives agreed. This is also the level where process documentation (like process work-flow diagrams) is created and improved when and where applicable. The second level covers the inputs, the key process activities and sub-processes, and the outputs (level 2). It’s at this level that roles are assigned, and metrics are captured. The process enablers are located at the third and final level (level 3). This is where we find the resources and capabilities. That’s the stuff we need to perform our process, like tools, technology, budget, time, and people.



[ALICE:] Can you fill in all the balloons of the process model for our Honda car and motorbike manufacturer? What about filling in the balloons for a medium sized hotel? This exercise looks easier than it is in reality. How many process owners should you assign per process? What will happen if two process owners are both accountable for the same process, and the process fails?

Process Characteristics

Processes have the following four characteristics:

  • Measurable; we need to be able to measure the performance of the processes.

  • Specific results; the process results should be uniquely identifiable and countable.

  • Customers; processes deliver results to customers, either internal or external.

  • Trigger; Responds to a specific event; processes should be traceable to a specific trigger.

[ALICE:] When do we call something a function, and when do we call something a process? What factors will influence and determine this decision? Ultimately whether we call something a process or function, what’s even more important?

More chapters of H2I will be added shortly, but then again, I always seem to be saying that. The guide is roughly 400 pages, so I guess if you stay with me for a bit longer, you get all the benefits and it won't cost you a penny.

Live long and prosper

Nanoo... Nanoo...

IsleBeeBach

ITIL ® is a Registered Trade Mark, and a Registered Community Trade Mark of the Office of Government Commerce, and is registered in the U.S. Patent and Trademark Office.

Saturday, February 27, 2010

CHANGE MANAGEMENT: KISSED by change once again! (part 2 of 2)

KISSED by change once again!

Preface
Let’s face it, the world is changing at such an incredible pace that hardly anyone can predict where it’s all going. Maybe we’re slowly entering the next ice age, where all measured global warming effects are merely a precursor to a much colder climate, and maybe, just maybe, in some years and tears from now our (faulty) DNA will be rewritten, re-sequenced and genetically improved by little creepy robots working as a bunch of busy bees in their own dimension referred to as nanoworld (nano = one billionth [e.g. of a meter]) fully hidden from our sight, and who knows they could even “carry” their own intelligence and be fully sentient like smart engineered viruses. Yeah, I love science and science fiction, as I believe the two exist, and will always exist, in full symbiosis. Where was I, oh yes, indeed, the topic of change! This article is one in a series of many that describes change and change management in all its fame and glory. Why, I can hear some of you think? Well, firstly, because English is definitely not my first language and I need to practice my writing skills, secondly because I enjoy the topic, and last but not least I enjoy writing and I hope that some of you equally enjoy reading. Didn’t Isaac Newton say that “for every action there is an equal and opposite reaction”? Well, I guess for every author there’s an equal and opposite reader (or at least one may hope so in order to account for one’s own existence).

Introduction
It’s funny how my Nokia mobile phone just slit of my newly acquired “An Introduction to Modern Astrophysics, 2nd ed.” book – which I used to look up Newton’s 3rd law – into my always patiently, obediently, awaiting and serving plastic green transparent bin (fully brand-less) on top of a just emptied can of “V Double Hit Guarana Energy Drink 500ml”. It makes you wonder if the forces of the Universe were trying to tell you something, or whether I merely used this opportunity to do some unpaid unconscious marketing, very deep sigh.
Let’s reiterate the 10 commandments of change management, unravel change management’s most basic (is there a word that describes “less than basic”?) activities, and somewhere along the kerb come up with some sort of explanation and/or definition for a process, as most definitions I’ve seen to date are requiring at least 5 PHDs to decipher, let alone comprehend and make sense of. Again, take a deep breath, relax, buckle up, get your can of energy drink, read on, absorb, and most importantly have fun!

The 10 commandments of change management
I admit, it’s still not clear to me whether I should be using “thou shalt” or “you shall”, but the ears prefer “thou shalt”, and so it shall be. Close your eyes, slowly inhale and exhale (but not too slow, because when you experience signs of turning blue [Smurf/Avatar blue is most definitely too deep a hue] you may want to consider making the slow a wee bit faster) 30 times and then allow the 10 commandments to burn their message onto your retinas as to be preserved and used for at least your moral and mortal (I made a typo and then decided to leave moral in – think about this decision) existence.

  1. Thou shalt adhere to the rules and guidance of the change management policy

  2. Thou shalt provide the organisation with enough time to properly assess and plan each change (this time will be agreed for each change category)

  3. Thou shalt record all change (from miniscule to mega-sized)

  4. Thou shalt assess each change on added business value (monetary, but also soft factors), on complete lifecycle costs (implementation, maintenance/support, removal/disposal) and on risks (threats and opportunities)

  5. Thou shalt ask for change authorisation from the appropriate stakeholders and/or committees (the stakeholders/committees stamp)

  6. Thou shalt approve each change to continue/discontinue in the change management process (the change management process stamp)

  7. Thou shalt have a remediation/back-out plan in place for each change

  8. Thou shalt test each change

  9. Thou shalt review each change against success criteria

  10. Thou shalt communicate with all applicable stakeholders on the progress of change


Just visualise the 10 commandments to be rolling across your screen in the same format as the introduction used in Star Wars with the same background music, causing the same WOW factor when originally released in 1977. How cool would that be? Use the force Luke! I’m your father’s brother’s uncle’s auntie’s adopted niece’s twin sister’s long lost daughter’s son! Do you remember princess Leia’s hairstyle? Until today I’m convinced she was wearing old-style headphones under those hair Danishes (preferable raspberry) receiving instructions from Master Jedi Deity Lucas himself.

To be continued...

Neah, not yet! That only happens in trilogies that somehow turn into utterly boring quintilogy, sexilogy, and septilogy cash-cows. Please don’t give me a sequel to Avatar! One movie with giant Smurfs/Vulcan crossbreeds was more than enough for me. Whatever happened to Harry Potter? Are they still making those movies? I sincerely hope not, although I must say I’m really enjoying reading “Barry Trotter and the unnecessary sequel, the book nobody has been waiting for” from Michael Gerber.

Processes, systems, and the stuff we do
The person that came up with those academic definitions for a process should be facing the firing squad, or at least be prepared to face the basket looking down from the guillotine. The world would be a far better place without some of the new ITIL v3 definitions! Whatever happened to Miss Simplicity?

Get yourself a pair of shiny new shoes (come on my female readers out there, I know you love your shiny shoes) and make sure you ask for the shoebox, because once arrived home safely and well, you can chuck away those shoes and focus for a minute on that shoebox. That shoebox represents a process! Huh what, a process? Yes, a process! Be patient, all will be revealed for those continuing reading.

Ah, I can see you’re still here, isn’t the world full of surprises! Believe it or not, but little invisible pixies (most likely blue with pointy ears – or feel free to imagine “The Wee Free Men” as described by the somewhat eccentric Terry Pratchett, as they are absolutely mindboggling awesome creatures) are working inside that shoebox making things happen, unfortunately they can’t see anything right now, and more importantly they can’t breathe, so I’m going to ask you to cut two holes at the opposite short sides of the shoebox, and furthermore I’m going to ask you to connect a small doorbell next to one of the freshly cut holes. Are you still with me?

It’s rather funny; because if you stuff your dirty old shoes through the hole with the doorbell, and don’t forget to press the bell, then if you listen carefully you can hear many different noises and sometimes even voices coming from inside the box (don’t peek inside, well, at least not yet). If you hang around a bit longer, then before you know it, shiny polished shoes (as new) will be pushed out from the opposite hole; the hole on the other side of the shoebox.

That’s what processes are all about! There are process inputs (dirty shoes), there’s a process trigger (ringing the doorbell, so the pixies know there’s work coming their way), there are process activities (pixies working inside the shoebox), and last but not least there are process outputs (shiny shoes). The general idea is that the process outputs have a real or perceived increased value compared to the original process inputs. You don’t want those pixies to make shiny shoes dirty, now do you?

Where was I heading? The mind is a strange thing, and keeps circling around ideas like vultures do for their prey. Oh yes, a definition for a process. I guess it should be something like: “The stuff we do to increase stuff’s value!”, or a bit more formally: “The activities we perform to achieve a certain outcome”. Anyway, I guess any definition will do except the definition used by ITIL v3 which states: “A process is an example of a closed-loop system because it provides change and transformation towards a goal and utilises feedback for self-reinforcing and self-corrective action.” To this I can only say “crap squared” and “get a life”. I never said or promised I would be subtle, not with my Dutch background!

Lights, camera, sound, action!
Rewind and fast forward: “shoebox, holes, doorbell, blue pixies, Terry Pratchett, process, activities, stuff in, stuff out, added value, crappy definitions”. Are you with me again?

If a process is “The stuff we do to increase stuff’s value!” then what exactly is the part that says “stuff we do”? What are those busy blue pixies actually doing? Well, that all depends which shoebox you’re looking at, and in this case we’re looking at the shoebox that’s wearing a label on the outside that reads “Best Practice Change Management”. No, not necessarily ITIL v3 aligned, as this author doesn’t agree with some of the ‘changes’ made in this version compared to earlier versions, which were way more straightforward, easier to follow, and a lot less academic. Not all innovation equals improvement, I guess that’s why OGC (the Office of Government Commerce) is talking ITIL v3 Refresh-Refresh (no I’m not text-stuttering here!)

Let’s lift the shoebox’s lid and observe those Schrödinger pixies. I guess under the tune of “hi-ho, hi-ho, it’s change we do, ho-ho” they’re roughly performing the following activities:

  • Receiving submitted change requests

  • Recording change requests

  • Classifying change requests

  • Organising assessment of the change requests

  • Assessing change requests

  • Approving or rejecting change requests

  • Scheduling approved change requests

  • Coordinating change requests

  • Monitoring change requests

  • Reviewing change requests

  • Closing change requests

  • Reporting on change requests

  • Actioning on deviations from the agreed change management process

  • Improving the change management process


More to be added shortly :-) Sorry, February went a lot faster than expected! Details will be added for each of the activities.

Live long and prosper

Nanoo... Nanoo...

IsleBeeBach

Monday, January 25, 2010

CHANGE MANAGEMENT: The KISS of Change (part 1 of 2)

The KISS of Change (part 1 of 2)

Preface

In a world with an ever increasing numbers of frameworks being rewritten almost on a daily basis I think it’s time to put the “s” back in simplicity. Personally I’m getting sick and tired of all these “know-it-all-a-lot-better” individuals who rewrite something that isn’t broken, has always been and will always be best practice, and for which the language doesn’t need to be changed just because we’ve got the power to do so and as a side-effect it’s going to create more revenue for some greedy companies and individuals. What idiot came up with the idea of talking about a purpose, goal and objectives for a process? I have issues enough just agreeing on the goal, so I’m really not waiting for added complexity we don’t need (sorry ITIL v3) and isn’t going to help, or provide additional value to anyone or anything in our tiny Universe. Take that in with a teaspoon (or should that be a sledgehammer?)!

Maybe it doesn’t matter whether we call something “reviewing changes” or “filtering changes”, but I think it really does the moment “reviewing changes” is used twice in the same process description (sorry ITIL v3), but with a completely different connotation. I’m not even sure if I’m describing the following “simplified” change management process for you – my dearest readers – out there, or just to convince myself it’s possible to explain process-theory in a language we can all follow. This is my attempt to put the KISS back in change management. I believe that anyone not fully schooled in quantum mechanics and membrane theory should follow this golden law: “Keep it #$&* simple stupid!” I feel like putting some swear-words in, but won’t for the sake of my respected readers.

On a slightly different note – somehow it sounds better in French: "sur un autre sujet" – I absolutely positively most definitely ‘hate’ all these silly acronyms and that’s a huge understatement. I’ll try avoiding them in the remainder of this article, BNPM. (Oh sorry, BNPM = But No Promises Made)

Introduction

Change – it’s a curious thing! The certainties that come with live are death, taxes and never-ending change. Ever gone back to your home city after 30 years? Chances are pretty big that you didn’t recognise the place anymore. I compare the physical environment to playing SimCity (still one of my favourite games, especially when Godzilla is on the loose). So, what about IT? Well, go back thirty years – even better just go back five, and see the amount of astronomical change that’s happened in the wonderful world we call IT. I grew up with a Belgium produced DAI INDATA home computer running a whopping 8-bits 8080a processor, and amazing graphics of 512x244 pixels. Sure, I can still buy that computer today, but only from a museum. Gosh how that makes me feel prehistoric!

Some people believe that strategy, vision and mission drive everything, I tend to disagree with them, as in the end it is change – and the changes going on in our minds – that’s fuelling the decisions and ultimately the changes we make. In this article I would like to give you some deeper insight into the world of change, its definitions, its process, its rules, and its peculiarities. I don’t claim to be complete or 100% accurate, but I have all intention to present change to you on a plate called “plain and simple”, and hope some of you will actually read this article compared to most management bibles that people only seem to buy as paperweights. Come on – be honest with me – who has really read all those ITIL volumes back to front? People always give me the phrase “watching paint dry” when referring to ITIL – I guess ITIL’s authors may never learn, but then again, never say never.

The 10 commandments of change management

I’ve always enjoyed throwing people in the deep end of the pool - makes them learn to swim really fast! So, rather than giving you lots of process theory and all this other nonsense and gibberish to start with, I’ll start with the 10 commandments of change management.

  1. Thou shalt adhere to the rules and guidance of the change management policy

  2. Thou shalt provide the organisation with enough time to properly assess and plan each change (this time will be agreed for each change category)

  3. Thou shalt record all change (from miniscule to mega-sized)

  4. Thou shalt assess each change on added business value (monetary, but also soft factors), on complete lifecycle costs (implementation, maintenance/support, removal/disposal) and on risks (threats and opportunities)

  5. Thou shalt ask for change authorisation from the appropriate stakeholders and/or committees (the stakeholders/committees stamp)

  6. Thou shalt approve each change to continue/discontinue in the change management process (the change management process stamp)

  7. Thou shalt have a remediation/back-out plan in place for each change

  8. Thou shalt test each change

  9. Thou shalt review each change against success criteria

  10. Thou shalt communicate with all applicable stakeholders on the progress of change


Well, there you have it! Stick to these rules and you’ll end up with a more reliable, stable and trustworthy environment, be it IT or any other environment delivering products and/or services. There’s one thing I’ll need to clarify though, and that’s the subtle difference between authorising and approving, something that most change management descriptions don’t seem to talk about.

The change manager – managing the change management process – isn’t God, Allah, Om or Buddha! He or she can’t possible know all the ins and outs of every single change, and can’t possible implement all changes him or herself. In other words: “the change manager (process) doesn’t know anything (or needs to know a lot) and the change manager (process) doesn’t do anything (or needs to do a lot) “, the change manager (process) merely controls and coordinates all change, but if the change manager doesn’t know anything (specific details of a change) then who does? The answer is obvious: The change manager invites those that have enough knowledge on whether or not the change should be implemented or rejected. Those invited will authorise the change on things like financial impact, business impact, technical impact, and will literally be asked to sign their lives away. When the appropriate amount of authorisations from the various areas of business, IT, and suppliers are collected the change manager has only one thing left to do: either approve or reject the change (stamp it, seal it, and mail it). If the change manager can’t approve the change then escalation to more senior management levels needs to kick in, but ultimately the change manager should be able to hold back (defer) changes if he/she feels that the appropriate amount of authorisations and/or information is not yet available or clear.

So, although the change manager (process) doesn’t need to know a lot, and doesn’t seem to do a lot (not physically implements changes – that’s the job of release management), the process is absolutely 100% critical to business and IT success, as it either approves or rejects change, and guarantees (well, at least it’s supposed to) a level of stability within the organisation.
So what is the important message that you should be able to distil from the above text? Well, it’s two things:

  1. The change manager role is critical to the success of the process.

  2. The change management process needs to be clear, understood and followed by all involved.


Let’s discuss these two points in the next paragraphs, and hopefully we’ll end up with a better understanding of change management. Get yourself another cup of something stronger than tea, as you’ll probably need it.

Heil our Change Nazi!

It’s always about policies, processes and procedures... Bull, it’s as much about people as it’s about aforementioned documents, and I didn’t even bring up the technology, information, and suppliers part of the equation. Believe it or not, it’s your choice in the end, but the role of the change manager can make or break your business (correct, I didn’t write IT, I wrote business). The power the person that steps into the role of change manager has is enough to start at least 5 Big Bangs, and crunch another 7 Universes. Well, at least, I think that’s how much empowered this person should be.

The change manager is the ultimate gatekeeper of the live, controlled environment (be it an IT infrastructure environment or otherwise (e.g. nuclear power-plant)). If a change doesn’t look kosher in the eyes of the change manager then it simply should not go in! Of course there will be quite a number of rules to decide (read approve, not authorise) whether or not something is actually kosher, and no I’m not Jewish, but it’s such a cool word, just like mazel tov. If I ever find the time, then I’m going to study some etymology, as I keep wondering where all these words originate from.

So, what are the traits of a good (blah-blah efficient, blah-blah effective) change manager? I’ll start a list here, and have all intention to add more to it based on feedback I hope to receive from some of you – the readers. All my articles are actually darticles (dynamic articles) and hence they may change at any time, as new information becomes available. Sorry, I went slightly off track there (a mere 5.21 astronomical units) and we were talking, or at least starting on the topic of traits. Rather than just talking traits let’s become a bit more sophisticated and talk skills, knowledge, and attitude, as really that’s what you’re looking for when trying to fill a certain role. Fasten your seatbelt, take a deep breath, and relax:

Skills:

  1. Facilitation / hosting meetings

  2. Documenting / reporting

  3. Negotiation / conflict resolution

  4. Interpersonal / communication

  5. Resource / time management

  6. Organisation behaviour / leadership

  7. Administrative / industry specific (high-level)

  8. Program / project management

  9. Assessing / distilling information

  10. Listening / observing


Knowledge:

  1. Business processes / functions / roles

  2. IT processes / functions / roles

  3. IT Service Management processes / functions / roles (high level)

  4. IT Service Management change management, configuration management and release management (detailed)

  5. Knowledge management

  6. Industry specific (e.g. IT) (high level)

  7. Generic management (including organisational behaviour and cultural change)

  8. Program /project management

  9. Logistics and dynamics of hosting meetings

  10. Politics and power-plays


Attitude:

  1. Ability / confidence to say no

  2. Able to separate business and friends

  3. Objective and unbiased

  4. Team-player (even better a likable team-player)

  5. Charismatic, energetic and influential

  6. Perfectionist and improver

  7. Chaser of win-win situations

  8. Honest, reliable and trustworthy

  9. Motivated to do whatever it takes to keep change under control

  10. Someone that quickly earns respect within the business and IT


Well, there you have it, a list of 30 skills, knowledge and attitudinal traits you may be looking for when selecting your next change manager. Do you think it’s easy to find a person with all these traits? No way, my friend! By the time you find someone with all these features embedded in their personality they’re likely already president in a country somewhere, or enjoying a tequila at Sunset Boulevard. The only keynote I would like to make here is that it’s probably going to pay off big-time when focussing on those attitudinal factors, rather than skills and knowledge. Skills and knowledge are relatively easy to obtain (test) compared to changing someone’s attitude (observe), which may take more than a lifetime.

Uhm... I only have 350 words left before I hit my own limit for this article, so I guess I may have to chop it into bits. So, let’s hit the accelerator pedal and go turbo-mode. Does anyone remember those old PCs which actually had a turbo-button (I used to have one called a Pony)? Why would you run it in non-turbo mode anyway? Ah well, it looked pretty cool in those days. I would still like a Porsche 911 with “turbo” engine – anyone got a spare one for me?

Goal

A process without goal is like Cher without Sonny, Mickey without Minnie or night without day. I guess the last comparison probably works best. Basically a process is like a big black box, something goes in, and something goes out. Whatever you’re doing in that box, well hopefully, you’re doing it for a good reason, and you should be able to link that reason back to the process goal, otherwise you’re likely wasting your time, your life, and God/Allah/Om/Buddha knows what else! Yeah, I know, I’m only trying to stay fair to all religions (sorry for those I’ve missed).

I believe the goal for the change management process should be something like this:

“To manage all (product and service related) change as to ensure maximum business value, optimised costs, minimized risks, and a level of agreed stability.”

I really don’t know why organisations and people are all clinging, like baby-monkeys cling to the backs/bellies of their mothers, to the goals as defined by ITIL and other frameworks. These goals are not necessarily 100% aligned with your business, and although they are a good start, you should rewrite them until they fit your business, you all understand them, and more importantly, you all believe they are attainable, hence my statement “should be something like this”. Whatever the goal may look like, I sincerely think that “stability” is one of the key reasons why change management has validity for existence in the first place!

“Without a level of change management the world is likely to end up in complete and utter chaos, with change management we get a level of order, visibility and stability.”

Anyway, time to move on, as I’m pretty sure you get the message by now.

Please note that as the author I don’t believe in “pure” stable/static environments, as they stifle innovation, creativity and the very essence of our human imagination.

To be continued...

Live long and prosper

Nanoo... Nanoo...

IsleBeeBach

Monday, December 28, 2009

MOF: Are you another ITIL Lemming? Get MOFFED here!

Are you another ITIL Lemming? Get MOFFED here!

A subjective view on the Microsoft Operational Framework (MOF v4)

Preface

In a Universe filled with twinkling stars, new stars are born every second. Some literally shine for billions of years – including our own small yellow Sun – others only shine for a fraction of this time and go out with a gigantic bang, or die without a making a single sound. In an industry filled with frameworks, methods and best practices we seem to be able to observe a similar pattern. Some frameworks make it to the top and become accepted as the norm, other frameworks are struggling for a place of existence and may eventually get there, or just vanish from the stage altogether leaving not a single sound or trace of evidence behind. One framework that doesn’t seem willing to take either side of these extreme positions is the Microsoft Operational Framework, or in short “MOF”. It just sits there comfortably in the twilight zone not striving to shine, but also not twitching a single muscle telling us it’s going to leave the stage any time soon. I guess it’s time to put MOF in the spotlights, to understand its twilight position a bit better and gaining a better understanding and knowledge of its place and value amongst the plethora of frameworks, methods and best practices.

Introduction

The Microsoft Operational Framework (MOF) goes back quite a number of years, at least 10 that I personally have some knowledge of. MOF has seen quite a number of transformations in the last decade, and just like many other frameworks has adopted a flexible organic life-cycle approach to planning, delivering, operating and managing IT services and its supporting IT infrastructure.

The goal of MOF is: "To provide guidance to IT organizations to help them create, operate, and support IT services while ensuring that the investment in IT delivers expected business value at an acceptable level of risk." [1.0 MOF Overview].

I guess this goal should look pretty much ‘standard’ for those already familiar with frameworks like ITIL and CobiT. Like most other (IT) Service Management frameworks the words ‘guidance’, ‘value’, ‘expected’, and ‘risk’ also take pivotal positions in MOF’s overall architecture. So, does MOF make a difference, does it deserve a place in (IT) Service Management framework Universe? I believe the answer to be ‘yes’, otherwise I wouldn’t be spending my time and energy writing this article. Get yourself another cup of coffee, or tea, or something stronger (commonly known as energy drinks) and read on, as you’re about to enter the Doctor’s space/time machine!

TARDISMS

I’ll have to admit that Dr. Who’s TARDIS is a fantastic machine that somehow also got stuck in Service Management Space; hence we’re discussing “Time And Relative Dimensions In Service Management Space” – or short TARDISMS. A quick count of Service Management related frameworks and methods gave me the number 42 – okay maybe a little bit less, but 31 doesn’t seem to sound quite right and as much fun as the number 42. After all, 42 is the ‘only’ answer to Life, the Universe and everything else [The Hitchhiker’s Guide to the Galaxy by Douglas Adams]. Although Microsoft (read one of their operations consulting leads) seems to place frameworks like MOF, CobiT, and ITIL in the same dimension, I personally have to disagree with this picture. In my opinion CobiT is mainly about answering the question “what” needs to be done, MOF drifts in the twilight zone of “what/how” and as far as I’m concerned ITIL basically still dominates the “how” dimension. Sorry ITIL! Yeah, I know, a lot of you will disagree with me here, but I like heated discussions. Overarching it all sits ISO/IEC 20000 which simply says “thou shall” and takes a similar position as Star Trek’s famous ‘Q’ space.

You feel lost? That’s perfectly natural, as this is exactly what’s happening in (IT) Service Management space as we speak. Once upon a time (indeed a very long time ago) we all spoke the same language, and all followed the same framework called Total Quality Management (TQM), then this guy called Nimrod came along and spoiled the game for everyone. Doesn’t “Nimrod” sound exactly like some type of acronym or mnemonic dug up from a prehistoric opal mine? Well, with some imagination it does... to me... it does... it really does... really!

Simplicity and complexity

I keep saying to most people around me: “less is more” and this is precisely where I derive the main benefits from Microsoft’s Operational Framework. Whereas most frameworks and methods praise themselves on the high number of areas, clusters, processes, stages, functions, roles and God knows what else, MOF takes the easy route, and I like that – a lot! Surely everyone must agree with me that ITIL has become way too academic in its language, and any person with an IQ of more than your average baboon will either read some ITIL summaries or follow a distance education course. Not many sane people are going to read the full ITIL books or sit the new ITIL v3 classroom delivered courses, but some may pick up (or rather download for free) MOF as it’s relatively easy to follow, seems to make a lot of ‘practical’ sense and most importantly of all uses a nice and very consistent structure in all its documents. This is definitely an area where ITIL has dropped the ball. I still can’t make head nor tail of ITIL’s structure. It all seems a bit messy and incomplete. Maybe that’s why ITIL is talking ITIL v3 Refresh Refresh (no, I’m not stuttering). I guess they – read OGC/APMG – may get it right eventually, but some other frameworks and methods are currently in hot pursuit, so better get your act together and do it fast, because many professionals are getting tired of wasting 1000s of dollars on something that’s of a less than average quality.

It’s elementary my dear Watson!

So, what’s MOF? Well, basically it’s a collection of Word and Excel documents that are freely down-loadable from http://www.microsoft.com/mof. Microsoft has even made the job extremely easy for us as you can select the one-click download, after which Bob somehow seems to become your uncle again. Uncle-Bob-space seems to have an unlimited supply of Uncle Bobs! Anyway, the MOF documents are properly ordered in dot-zero versions (phase docs) and dot-sequence-number versions (service management functions).

Here’s the full list of phase docs and service management functions (SMF) docs:

1.0 MOF Overview
2.0 Plan Overview
2.1 Business IT Alignment SMF
2.2 Reliability SMF
2.3 Policy SMF
2.4 Financial Management SMF
3.0 Deliver Overview
3.1 Envision SMF
3.2 Project Planning SMF
3.3 Build SMF
3.4 Stabilize SMF
3.5 Deploy SMF
4.0 Operate Overview
4.1 Operations SMF
4.2 Service Monitoring and Control SMF
4.3 Customer Service SMF
4.4 Problem Management SMF
5.0 Manage Overview
5.1 GRC SMF
5.2 Change and Configuration SMF
5.3 Team SMF
6.0 MOF 4.0 Glossary
7.0 Mapping of MOF Versions (Excel spreadsheet)

The good thing about this structure is the alignment with for example the MOF Foundation Exam, in which you can basically get away with reading the MOF Overview and the four dot-zero phase documents. Furthermore this structure allows for separation of those stakeholders that only need a high level overview of MOF and its potential (dot-zero docs) and those that require more detailed insight and knowledge of MOF (dot-sequence number docs). Personally I believe this is a very strong feature of MOF as it supports an approach where you only have to read the documentation on a need-to-know basis. Have fun reading those 2,000 pages of ITIL v3, I rather read 100 pages of MOF thank you very much! Providing information on a need-to-know basis is definitely a factor that can help speeding up adoption, adaption and use of MOF within the business and IT environment.

After a 3-day public ITIL v3 Foundation course many students provide feedback in the form of “too much content for 3 days” and “my brains feel numb”. In contrast MOF provides feedback like “enlightening” and “seems quite practical and common sense”. You draw your own conclusion! Personally, I can only say that I’m glad I’m in a position where I have a lot more time to convey my ITIL v3 knowledge and skills using a system of distance education principles combined with academic resources (see http://www.csu.edu.au and http://www.itmasters.edu.au). I don’t like marketing, but distance education (in the right format) works so much better than public classroom “crammed” training!

Please note that the MOF v4 one-click-download is just one of the many resources that are currently part of MOF-download-space. If you’re after quick start guides, action plans, ISO/IEC 20000 integration documents, or other cross integration guides, then those are also available and – best of all – free!

Hyperspace, subspace, wormholes and travelers

In my humble opinion MOF consists of (thank you: “only”) four key parts, which are phases (hyperspace), service management functions (subspace), management reviews (wormholes) and roles (travelers). Yeah, I know, I’m a geek and love science fiction, but somehow making these silly analogies helps me to remember stuff, as the soggy brains aren’t getting any younger.

The four key phases have 3 tangible “real” dimensions known as “Plan”, “Deliver” and “Operate”. The 4th dimension behaves more like our dimension “time” and is tightly interwoven with these other three more tangible dimensions, and is known as the “Manage” phase.

MOF is like a game, and you’re only allowed to move from one dimension to the next using wormholes, oops, I meant to say “management reviews”. The picture below is mind-boggling simple, yet extremely powerful, as it makes you understand MOF in the wink of an eye. For example it’s telling me that I can’t start building stuff, as long as my project plan is not properly approved as part of a “project plan approved management review” exercise. Well hey, that makes sense, as we need to make sure out project objectives are adding value to the business, are cost-justifiable, and risk managed, hereby taking into consideration and evaluating items like functional specification, master project plan and master project schedule. Whereas ITIL v3 talks Service Transition, MOF simply talks Project Management. I believe MOF is on the right track here, as I’ve always considered ITIL’s Change and Release-and-Deployment Management as Project Management sub-processes/activities in disguise. Why make it complex if you can keep it simple? MOF keeps it simple!



Source: MOF v4 (http://www.microsoft.com/mof)

Where was I? Oh, yes, subspace and travelers. It may be clear from the picture above that MOF identifies a number of Service Management Functions (SMFs) for each of the MOF life-cycle phases. For example the phase “Operate” covers the Service Management Functions “Operations”, “Service Monitoring and Control”, “Customer Service”, and “Problem Management”. Each of the Service Management Functions is explained high-level in the dot-zero documents and in detail in the dot-sequence-number documents, and believe me there’s a lot of detail provided that’s missing in other – some say more popular – frameworks . All the work-flows that seem to be missing (lacking) in ITIL v3 are provided as part of MOF, so if you don’t know where to start with ITIL, then MOF provides a fantastic alternative framework or can (simply) be used as add-on/plug-in to ITIL, CobiT or any of the others. I rate MOF’s tangibility factor to be quite high, and surely that must be one of the weakest factors in most other service management frameworks. MOF seems to exist on a plane between framework and method, and hence takes more than one twilight position in the realm of service management space. It sits there, and for now, lonely, uniquely, and somewhat distantly (is distantly actually a word?).

MOF-space is filled with travelers, I mean people actually performing the various MOF related activities. Whereas most of these people actually travel, they move from one position to the next, MOF roles don’t. Roles describe packages of activities with related responsibilities, accountability, authorities and dependencies. So travelers with the right skills, knowledge and attitude can simply step into a role that fits them best – enjoy the scenery and all those touristic activities – perform a well registered hand-over (well, at least describe their journey on face book) and move on to better places. I guess I’m saying that roles create the basis for consistent high-level quality processes without the organization being fully dependent on so called “irreplaceable” individuals in the organization.

Everyone is replaceable, absolutely everyone! We all die one day, the world will keep spinning, the Universe will keep expanding and cooling down, so get your roles and processes in place, and the organization will live to see another day! Sorry for being so blunt – it’s my Dutch heritage – something I can’t seem to get rid of. MOF roles rock! They really do. Somehow I would like to combine CobiT’s ARCI (Who’s Accountable, Responsible, Consulted, and Informed) charts with MOF’s role descriptions and the world would become a far better – more organized – place. Surely functions and roles must be ITIL’s weakest point, if not the single point of failure. Most organizations that I’ve seen have no issues whatsoever developing ITIL processes; they have issues assigning the various activities to roles and functions. It’s often not what needs to be done, but who is actually doing it where a lot of ITIL implementation pain is felt. MOF creates a whole lot more clarity – approximately 2 Universes in size – when it comes to mapping roles to processes. That’s another chicken in the basket for MOF (I so like the Muppets: http://www.youtube.com/watch?v=tgbNymZ7vqY).

Inflation and deflation

It is dark matter and dark energy that will either keep the Universe in a state of never-ending inflation, or the whole thing will start collapsing again and we’ll all end up in the big-crunch – I mean really, really big – in which case you can say bye-bye to all your Bermuda holidays. I guess something similar applies to all service management frameworks, including MOF. Either the total mass of benefits outweighs the total mass of potential issues, in which case there’s enough reason for MOF to maintain its own unique position in service management space, or too many issues cause the framework to die a slow or less painful sudden death. MOF has definitely many strong benefits, of which ease of use, quick ROI and low TCO, its life-cycle approach, its great structure, its simplicity, its project focus, and its practical focus are just some of the main ones. So why is MOF still relatively unknown outside of Microsoft’s empire? I guess there are three main reasons that may explain this phenomenon. The first one is the perception that MOF is yet another go of Microsoft to rule this tiny world we all live on. I don’t believe this to be true, rather I believe that MOF is a sincere attempt of Microsoft to add needed structure and processes to the plethora of IT they’ve made and are still making available to the world. Managing complex IT environments needs a structured approach supported and surrounded with the right process and people. If IT fails, then who gets all the blame? MOF is a form of risk mitigation that Microsoft has put in place. With the right people (roles) and processes in place IT will fail less, and hence Microsoft gets a better name in the market! The second reason is ITIL’s dominant position in today’s IT environment, but it doesn’t mean it’s the best stuff around. They were the first to market and had a great marketing machine behind them, called Government. I guess it’s a bit like VHS and Beta-max, and we all know that Beta-max was quality-wise way ahead of VHS, and look what’s happening to all your VHS tapes right now. I believe the third and final reason to be the most challenging one and this is also related to our VHS analogy. Assuming we’re all taping on VHS (yeah sure...) then why would I invest in yet another technology? I already speak the VHS language and already have quite a lot of VHS (ITIL) skills and knowledge. This creates a real dilemma!

MOF has adopted a language that is very different from ITIL’s Esperanto, but that doesn’t make the ITIL Esperanto any better, or does it? I guess it’s always possible to map MOF’s peculiar language to ITIL’s peculiar language. Where MOF talks ‘Customer Service’ we can still talk ‘Service Desk’ in our organization, but use the plethora of processes and work-flows that MOF offers to us. Be aware that ITIL also keeps changing its language, so who is to say they are right and MOF is wrong. ITIL’s Help-desk is now a Service Desk, but MOF actually talks Customer Service, which is way better aligned with the core principles of Total Quality Management (TQM).

I guess MOF has more to offer than most organizations (read senior managers) are aware of. After breaking down the walls of perception, the garden that’s called MOF is actually quite a nice one and a lot easier (and cheaper) to maintain than ITIL’s garden.

So, what’s next?

This question is actually more difficult to answer than it seems. Assuming the organization is aware it needs to change, it needs more structure, it needs processes, and potentially has many more reasons to adopt and embrace a service management framework, be it MOF or framework X, I would visit two similar organizations – one using MOF, the other using framework X – and have an in-depth chat with management. Look at items like Return on Investment (ROI), Total Cost of Ownership (TCO), ease-of-implementation, ease-of-cultural adaption and adoption, transparency (business to IT and vice verse), and overall integration with other business-and-IT processes and systems. Sounds like quite a lot of work huh? I never promised it would be easy, but throwing away millions of dollars on a less than optimal framework ‘solution’ is also quite painful.

Anyway, you can always start to download the free MOF framework and start flicking through some of the pages, follow a 2 or 3 day course with a provider that actually knows what they’re talking about (make sure they’re ITIL, MOF, CobiT, and ISO20K certified so they actually understand the differences and benefits of each of these so called ‘solutions’) or best of all just visit an organization that actually uses MOF or uses framework X with MOF add-ons. As long as there’s a clear and valid reason to change, doing anything is better than sitting on your bum!

Epilogue

In a Universe filled with twinkling stars, new stars are born every second. Stars follow a life-cycle of which many span billions of years, some only last a few million. IT services also follow a life-cycle and move from planning to delivery through to operations. At some stage, when the IT service is no longer deemed valuable to the business – it also – reaches its end. The Microsoft Operational Framework (MOF) can be compared to a practical almost ‘turn-key’ IT service management solution which allows you to manage the life-cycle of your IT services so optimal benefits can be harvested, minimal investments have to made, and risk is managed to acceptable and agreed levels. It all sounds almost too good to be true! I challenge you: seriously consider the many valuable aspects of MOF and don’t become another ITIL lemming!

Live long and prosper

Nanoo... Nanoo...

IsleBeeBach