November 18, 2008

“But I don’t want to change”

Posted in Change Management, ITSM tagged at 1:22 pm by Molly

“Why?  change is exciting, its innovative, new techniques are used, its more efficient (definitely should be otherwise its a useless expensive exercise), less intensive with new technologies constantly changing the way we can automate things, they are doing it at our competitors, and we should keep up”

See, change is difficult to get across to people, never mind the whole organisation.  People don’t want to change, they are afraid of what may happen to their roles, their functions, their ways of working, their 9 to 5 mentality, their performance ratings and subsequent payrises.

Trouble is, when we wake up in the mornings, it’s a changed day, the weather has changed, our personality has changed, we are a day older than yesterday, we change our clothes, our surroundings have changed, and before you know it we have to adapt to that change.  So why are we so reluctant?

Change can be viewed as:

  • learning change
  • personality change
  • behavioural change
  • cognitive change
  • managing change
  • humanistic psychology change

In the early 90’s I loved my brand new Motorola brick mobile phone, the one that needed two hands to hold, clip it on your belt and you walked with a limp, battery life of an hour, phone bills to make you weep. Now I have a Nokia E71 smartphone, sleek and slim, with a camera, wifi, GPS, it plays my music for God’s sake.  I have adapted to a change in the mobile phone market.  I’d look pretty ridiculous walking around with that Motorola brick now, and it probably wouldn’t work anymore because of the frequency bands or network architectures of today.

Simple – we all adapt, maybe slowly at first, to the technological advances or maybe we are forced to adapt due to another change happening elsewhere upstream or downstream.

So how can we help change along?

We must all understand and reduce the anxiety that changes bring to ourselves and others, to our own and others teams, and to our and other organisations. (I say other organisations because there may be suppliers involved, and they would need to understand the tranistion too).

What would happen if your CEO today said to all employees “you must all work 12 hours per day, there will be no extra money paid to you”. (Maybe today isn’t a good example since we are in the midst of a financial crisis, deflation, recession) but let’s imagine all is happy in the world.  I bet you’d consider quitting your job, or at least looking around for a new job.  Why would you do that?  It’s because your CEO ‘bullied’ you and the other employees into a change without showing you any of the benefits or advantages that could be gained.  What if the CEO said “you must all work 12 hours a day, with no extra money, but you will have a percentage of the share price when we make our acquisition of ABC plc. I hope to give you all a 25% bonus at Christmas time after our acquisition transition period has settled”.  Now you see the whole picture, now you can relate the change in the circumstance as well as the added bonus of money at Christmas time for your efforts in the short term. So you should be feeling more empowered to make a better judgement about your own circumstances.

We sometimes want to see the physical success a change brings, for example, a new Service Desk with new processes brings with it efficient call logging, customer satisfaction, reduced outages and complaints, and after a while the Service Desk operator has more time to undertake training in some other areas.  BUT, let’s say the new successes can’t be visualised immediately because during the transition period where staff are being trained in the new process means there are less operators taking more calls per operator, there are more complaints coming through because efficiency has dropped.  It’s frustrating to say the least, because your team is not running at 100% efficiency – but it will.  This is the transition period that has the potential to make or break both morale and the benefits of the new change in your organisation. Everyone is alert to the fact that anything can go wrong in this timeframe, and there will be the cynics in your organisation who want to see failure because they are the ones who don’t have or understand the vision of change.

As a manager you must remain cool headed and focused throughout.  What would happen if a member of your team caught you bad mouthing the new functionality and process?  Bad news spreads faster than good news.  Weather the initial storm, and have the clear vision to see calmer waters and clearer skies ahead. Pass your vision onto your staff and if need be pull the ‘cynics’ aside and ask them why they think the change is not beneficial, maybe they haven’t understood the process.  Mentor them either individually or in a small group, get feedback from them, its not a one sided communication exercise, spend time calmly explaining what the corporate or department vision is until its clear to them.  Customer surveys are great exercise tools, but use them wisely and understand why you are collecting the data and for what means.  In some cases, organisations promote changes in their organisations with corporate gifts, pens, mugs, flags etc … this highlights to other people and departments that something new is afoot and that it is still ‘business as usual’ but that a change also brings a few teething problems.  Keep those teething problems to a minimum though.  Produce a small leaflet or news article in the company newsletter or intranet site, make people aware.

Communication is the only tool you have to highlight the benefits of the change, use it wisely and carefully.  Make sure that the organisation’s management highlight the transition during board meetings, it shouldn’t be a ‘ram down your throat’ exercise.

After a period of 3 months, conduct a survey and see how your change has been received within your organisation.  Also, has the change been beneficial to the business – should be your very first question.  Identify where you can make small improvements. Avoid another large change immediately after roll-out, this will cause more confusion, but certainly tweaks here and there should be seen as improvements.  Remember continual improvement is a process too, not a daily process but a process that will improve individual and team efficiency, and benefit the organisation on the whole.


IF YOU DON’T UNDERSTAND WHY THE CHANGE IS REQUIRED, HOW CAN YOU EXPECT YOUR STAFF AND ORGANISATION TO UNDERSTAND THE BENEFITS !

I shall write more on this subject at a later date.

Advertisements

November 13, 2008

Service Catalogue

Posted in ITIL, Service Catalogue tagged at 5:36 pm by Molly

A database or structured document with information about all live IT services, including those available for deployment.  The Service Catalogue is the only part of the Service Portfolio published to the customer(s), and is used to support the sale and delivery of IT services.  The Service Catalogue includes information about deliverables, prices, contact points, ordering and request processes. [ITIL v3 – Glossary]

  • What does the customer require from the Service Catalogue?
  • what is available (definition)
  • when its available (availability)
  • how they access it (access)
  • timeframe around the service (service level)
  • success measures for the service (KPIs)

Let each IT group create their internal IT portfolio that lists specific IT services they offer, accompanying operation level agreements (OLAs) and available technology product devices.

MAKE IT DYNAMIC
Keep the information contained within the SC as up to date as possible, allocate each of the services to their IT Owner if appropriate, or otherwise have an administrator modify, create or retire this DB. It’s not going to be a static DB that in 6 months time you come back to for review, keep it alive!

WHAT DO YOU WANT FROM THE SERVICE CATALOGUE BEFORE YOU EVEN START PLANNING FOR IT?
You will want to know the following details:

Service Name
Unique Reference for the Service
Service Owner (IT owner, business owner and maybe financial owner)
Date Created
Date Purchased
Status
Relationships to other Services, other CIs (Config Items) or Assets (include link statuses & hierachy)
Monitoring status
Review date

You may want to link in agreements, contracts, diagrams, processes, procedures, policies, other artefacts for the Service

WHAT IS THE IMPACT YOU WANT TO HAVE AND HOW IT WILL BE USED?

CI table attributes

Posted in CMDB, Configuration Management tagged at 5:06 pm by Molly

Physically capturing CIs is a separate task all by itself, but we shall look at the attributes you can consider for your CMDB.

In no particular order:

  • name
  • description
  • location
  • system
  • sub-class
  • owner
  • team allocated
  • financial allocation
  • catalogue #
  • network name
  • supplier model
  • serial #
  • maintenance method
  • updated

Added 20th November 2008:

Depending on the granularity of your CI selection, you may want to include the following:-

  • location
  • responsible owner
  • IP address*

* you should consider wheather you want a fixed or variable definition of the CI data within your CMDB.

I shall explain ‘fixed’ and ‘variable’ in another article shortly.

Primary reasons for separate CIs

Posted in CMDB, Configuration Management tagged , , at 5:03 pm by Molly

  • critical, new or modified designs;
  • independent end use functions;
  • need for separate configuration control;
  • components common to several systems;
  • interfaces to other systems, equipment or software;
  • level at which interchangeability must be maintained;
  • separate delivery or installation requirement
  • separate definition of performance and test requirements;
  • high risk and critical components.

Typical Configuration Management activity model

Posted in CMDB, ITIL tagged , , , at 4:52 pm by Molly

For those of you with the ITIL v3 Service Transition book open at page 71, I have some extra lines that I have drawn onto my activity model.  On the whole the diagram is good at depicting the activities within Configuration Management.

My additions include:

LINE # 1

  • drawing a dotted line from the box labelled “Configuration Control”, left and back up to the box labelled “Configuration Identification”;
  • Line description: “approved changes”;
  • Reason: for new CIs, you may want to have them approved before they are implemented within the CMDB, this could also be true for renaming CIs during an update/restructuring exercise.

LINE # 2

  • drawing a dotted line from the box labelled “Status Accounting and Reporting”, left and back up to the box labelled “Management and Planning”
  • line description: “performance measures”;
  • reason: it joins the dotted line that exists to the “Management and Planning” box, which in my mind is a Continual Service Improvement activity which is labelled ‘feedback’, but I think it just needs to be made somewhat clearer.

ITIL v2 to v3 – a toe dipping exercise

Posted in ITIL tagged , , , at 4:28 pm by Molly

As you may have read in another article I wrote on my ITIL v3 bridge course which I had recently completed, I’m going to be discussing some of the differences between v2 and v3 of ITIL that you may well know about and somethings you may not.  This article will not go into the fine details but rather give you an overview of what you can expect out of v3.

First of all let’s have a summary of ITIL:

  • ITIL core is (still) structured around a service lifecycle;
  • There are 5 new core books that ‘replace’ v2’s Service Support (blue book) and Service Delivery (red book);
  • New books: Service Strategy, Service Design, Service Transition, Service Operation & Continual Service Improvement with snazzy front covers of x-rayed fauna;
  • The 5 new v3 books describe: “How to develop a business driven strategy”, “How to design a system to support the strategy”, “How to transition a system to production”, “How to support operations” & “How to continue improving processes and operations”;
  • The key concepts have been preserved with v3;
  • There are 12 new processes;
  • There are 3 new functions: (technical management, IT operations management & application management) along side the existing Service Desk function;
  • Within v3 there is more emphasis on business value and process improvement, after all continual service improvement has it’s own dedicated book for you CSI Managers out there;

Note: There are a few diagrams I’ve come across within the v3 books, that on further investigation, as well as looking at them for long periods of time, you’re still none the wiser at what they are supposed to be depicting, and the paragraph relating to them, well it’s probably like reading the Russian translation, you’re none the wiser, unless you speak Russian (hmm wondering if the OGC does translate into Russian – could be an IT pub quiz question).  I’ll come up with some examples in other articles about this, maybe someone can enlighten me and I think some of the other ITIL experts out there.

Determining the CMDB span (part 2 of 3)

Posted in CMDB tagged , , at 3:36 pm by Molly

In part one of this series, we discussed the CMDB scope and how you can accomplish what the required categories and relationships you would include to start to plan your CMDB.  Let us look at the SPAN criteria for the CMDB.

What does the dictionary say about SPAN – “distance, full extent, the reach of anything“.  In our case, we shall describe span as an indication of the specific groups that will be tracked for each of your objects that you have already defined in the SCOPE, in other words the boundaries of our definitions.  So I hope by now that you have some idea of your scope.

Your boss: “forget span, can you just gather all the data you can find and we shall use this in the CMDB”

You: “but … where shall I start?”

As you see from this conversation that is very typical in our IT environments.  Where do you start?  What are your boundaries?

IDENTIFY WHICH CIs WILL BE STORED IN YOUR CMDB AND WHICH WILL NOT is always a good starting point in my opinion.

Example: an online news broadcaster may decide that the editorial team and the web development teams’ iMacs are more critical than those from the HR office.  They would be right to some degree, but don’t go asking the HR manager!  So define your critical CIs correctly to begin with will reap benefits later on in the architecture of your CMDB.

Span important facts:-

  • Span your projects – you’ll never populate your CMDB in one single swoop, so phase it out, split it into stages;
  • Dictated by tools;
  • Understand the risks;
  • Document it;

CMDB quick notes

Posted in CMDB tagged at 11:29 am by Molly

  • define schema (track)
  • register CIs (track)
  • track changes (track)
  • build relationships (relate)
  • link business to IT (relate)
  • detailed operational overview (relate)
  • integrate processes (optimize)
  • grow your data (optimize)
  • make decisions (leverage)
  • programmes and projects use CIs (leverage)
  • value (leverage)

DON’T OVERLOOK RELATIONSHIPS/ASSOCIATIONS

ONE CMDB OR SUB-CMDBs?  THINK CAREFULLY ABOUT CROSS-CMDB RELATIONSHIPS AND THE RELATIONSHIPS THAT FIT NEATLY WITHIN A SINGLE SUB-CMDB (IF THIS IS YOUR PATH) BECAUSE THIS REQUIRES ELABORATE SCOPE DEFINITION.

DO YOU REALLY WANT THE COMPLICATION AND THE EXPENSE OF TRACKING EACH AND EVERY CI THROUGHOUT YOUR ORGANISATION? YOU MAY WANT TO PERFORM A QUICK COST ANALYSIS EXERCISE HERE.

REMEMBER THE COST OF MANAGING A CI OVER ITS LIFETIME IT IS ALMOST ALWAYS MORE THAN THE COST OF GATHERING INFORMATION ABOUT IT IN THE FIRST PLACE.

THINK CAREFULLY ABOUT THE ISSUES SURROUNDING THE SCOPE OF DOCUMENTS AND ESPECIALLY THE RELATIONSHIPS YOU WANT TO DEFINE FOR THE DOCUMENTS.

NEVER LOSS SIGHT OF YOUR BUSINESS VALUE.

IN EVERY INSTANCE – REDUCE YOUR RISK BY PLANNING AHEAD.

My Golden Rule:  IF YOU CAN’T TRACK IT – DON’T MANAGE IT!

November 12, 2008

Welcome

Posted in Welcome Note tagged at 4:45 pm by Molly

The Blogger

This blog hopefully will enlighten you in the specialist field of ITSM, IT Governance and respective frameworks and Project Management topics, as well as any other categories that come to mind during the course of writing.

I want to keep this blog as professional and focused on the subject matters described, therefore all comments go through an approval process before being published.  Feedback is most welcome here, and constructive criticism is never frowned upon, after all we learn from eachother and our own mistakes.

I hope you enjoy the blog …

Determining the CMDB scope (part 1 of 3)

Posted in CMDB tagged at 4:26 pm by Molly

Review the previous article I wrote about the definition of SCOPE to refresh yourself what scope actually means.

What does it mean to the CMDB?  The most important aspect of your CMDB is that information stored within it is accurate and up to date.  The second most important aspect is that you have relationships between your CIs. After all what is the point in just holding static information, you want your information to be related in someway so that you can either find out what the fault is or other investigation works like future planned upgrades or project works in your organisation.

Scope includes:-

  • What the potential contents of the CMDB will be;
  • Categories of objects and what kinds of relationships you will be able to capture between these categories;
  • Your database schema;
  • Some indication of the object classes that will be included in the CMDB.


Don’t overlook the CMDB relationships and associations. I would personally keep those separated out and review them again at a later stage.

We’ve just discussed what will be IN SCOPE for your CMDB, let’s have a look at what will be OUT OF SCOPE.

To give you a chance to think about the scope for yourselves, I’m not going to be writing long lists of what NEEDS to be included and excluded here, after all, each organisation is different, therefore each scope will be different in turn.  What I shall be jotting down for you are notes with question marks for you to go away and consider for yourselves, after all this is your project and I’m not getting paid to do your work:

Incident reports and change records – do they offer up any benefits for relationship modelling within your CMDB?  They are stored in the physical CMDB but are they going to be CIs?

Business continuity plans, DR plans, change back-out plans, roll-back plans? They are not CIs are they?

What about procedural documentation like how to perform a change in our organisation or a list of all software installed on a server or installation guides and technical specifications? Are they good CIs?  What does ITIL say?  Will these documents substantively help define your IT environment?

What about the relationship between a printer and a workstation, should you be making a relationship within our CMDB for this?  What if it is a network printer, or a roaming laptop or a pool laptop for that matter, are these items really going to be IN SCOPE for your CMDB?  What did I say about associations?

NOTE:  THINK CAREFULLY ABOUT THE ISSUES SURROUNDING THE SCOPE FOR DOCUMENTATION AND PAY CLOSE ATTENTION TO THE RELATIONSHIPS YOU WANT TO DEFINE IN YOUR SCOPE!

  • KEEP IT SIMPLE
  • PAY CLOSE CONSIDERATION TO THE COST OR COSTS
  • SCORE SOME EASY AND EARLY VICTORIES
  • DOES THE SCOPE CONTAIN BUSINESS VALUE
  • REDUCE YOUR RISKS
  • CONTINUOUS IMPROVEMENT
  • DOCUMENT THE CMDB SCOPE

Next page