I’ve started a new contract – one that looks like being a long term one – and it’s taken pretty much all of my attention. I’ve ignored LinkedIn, industry news, other blogs and so on, let alone my own blog.

More than one person has described what we are doing as organised chaos – and part of my role is to create structure (architecture, specifically) out of this chaos. Currently the chaos is winning! – new bits of it arrive faster than I can structure whichever bit I’m thinking about. But the potential, when the solution is built, is huge: a large-scale multi-sourced IT service, with ITIL in a rather pure form, service catalogues, the works.

As my boss says, you learn the most in your career in the jobs that bring the most pressure.

But for me, I only feel that I’ve learnt it when I’ve reflect on, analysed and synthesised the experiences. And that’s what blogging should be for.

There’s no one correct answer to this. It depends on what’s hurting you now, and where efforts will give the greatest return. In practice, a lot of companies start with customer-facing processes such as request handling and incident management (and this can work well) or service level agreements (not so much). Getting control of changes is another area of high potential return, as badly controlled changes in turn cause many of the incidents and service level failures that customers experience.

But look at the words I’ve used: “to improve your service management”; “what’s hurting you now”.

I’d like to suggest that companies embarking on an ITIL journey – and companies regrouping their ITIL-based efforts – look first at Continual Service Improvement (both the ITIL v3 book, specifically the seven step improvement process, and the concept in general) and establish a basic improvement process.

• By starting with a philosophy of identifying issues against a defined desired state, we can focus our efforts on the most valuable areas.
• By starting with a purpose of addressing the overall value of the IT services and the effectiveness of the ITSM capability for business needs, we can support alignment and integration with the business – or perhaps, avoid putting effort into areas that reduce integration!
• By starting with an expectation of measurement we promote an expectation of tangible results. (It’s reasonable if there is not much actual measurement initially; measurement requires planning and costs money.)

Measure now, gather data now, analyse now, begin reviews of lessons learned now, make incremental improvements now. Don’t wait! Start improving now!

- Continual Service Improvement, OGC, p24. The diagram on that page is good too.

It doesn’t need to be the full 7-Step Improvement Process (section 4.1), especially if “measurements” are initially done just via customer and internal meetings. But you should cater for all steps of the CSI Model (section 2.4, figure 2.3) – from vision, through assessments, targets, plans and implementation, measurement and keeping the momentum going.

Furthermore, don’t view the 7-Step Improvement Process and the CSI Model as cycles where you only do one of the steps at a time. There could be hundreds of issues identified from discussions, from automated service measurements, from process workflow tools, etc. These cycles do not mean that you pick one or a few issues, and take them through the cycle only to get to the next issue a few months later. Instead, view it as a production line on which many issues may be at different stages – of visioning, assessing, planning, and so on.

The list of identified issues can be seen as a statement of needs or (when qualified) requirements, functioning very much as a backlog in various Agile Software Development methods and so facilitating Agile Service Management. The issues can be prioritised jointly with customers, not by guesswork inside IT – another valuable principle from Agile methods.

Given measurement of where we are now, definition of where we want to be, and integrated planning, the list or log of issues provides a powerful means of seeing where ITIL can best be used first to improve service management, and maintaining focus and control throughout subsequent improvements.

Vinod:

I am in a focused drive of differentiating between confused terms

The Skeptic:

I think ITIL V3 muddies the definition of Incident, and of Incident Management.

As I commented on Vinod’s blog, I think these discussions are not likely to be concluded with everyone agreeing, and it may be useless to expect agreement. But it’s still important to have the discussion – and vital for any given team or organisation to have clear common understanding. There are dangers in labelling two distinct concepts with one word: it becomes harder to work with them (e.g. to define workflow) if you’re at least aware of the multiple meanings or if different team members interpret them differently. Equally, if some important concepts are overlooked because there’s no term for them, the ITSM capability will not be engineered to cope with them.

People hope that ITIL, or other applicable sources of best practice, have already provided clear unarguable definitions. But no matter how confidently you restate those definitions, they are simply not precise enough to classify and distinguish the important concepts. See the above links for examples, or look at your favourite ITSM forum for questions like “is this an incident or a service request?”

Deconstructing Terminology

The “Deconstructing ITSM” approach would be this: first, try to define what are the important concepts. The concepts are more real than the words used by various speakers, however authoritative. Humpty-Dumpty fashion, words mean only what they are used to mean, and not all speakers are able to say what they mean by a word as precisely as Mr Dumpty. Also, the concepts are more real in your organisation for your business needs than in some global consensus.

• Make sure you know your purpose. Things can only be important in a context, like drafting a specific process, customising a tool for a workflow, etc.
• Identify what things can happen, or exist, or need to be managed, or recorded, etc
  • Since we’re talking about abstract concepts not physical objects you can drop on your toe, deciding what is one thing – when is a thing the same as another thing – isn’t easy. An incident logged on a Tuesday vs an incident logged on a Wednesday – there’s no significant difference. What is important is to distinguish details that matter, that make a difference for our purpose. Things that have affected user services are clearly different from things that haven’t (yet).
  • Some distinctions or ways of dividing up concepts seem universal and powerful: the Skeptic calls these natural fault-lines. Some won’t seem so natural, but don’t lump them together until you’ve properly tested them from various angles. It will be easy to group them together later.
• Define the things as well as you can, without of course using the words we’re trying to define. This can get hairy. We are making a list of concepts that have lost their names (didn’t that happen to Alice, too?) and may not ever have had good names. The important thing is to capture the significant differences between your concepts, and if possible to capture everything that matters about them for your current purpose.
  • In case this is making no sense at all, here is the list of things that might be incidents or problems or something close, which I posted on the Skeptic’s blog:
    • Disruption of the current value of service to user (this is the undisputed part of ITIL’s Incident)
    • An abnormal condition in some part of the managed environment (infrastructure, applications, their configuration, …) (I think this is close to “Known Error”)
    • An abnormal symptom not yet identified (fuzzily worded, but I think it’s a concrete concept – close to “Problem”)
    • An identified risk of an abnormal condition emerging in the future (a “Problem”? or is this where ITIL fails to cover Risk? It doesn’t properly match ITIL’s definition “cause of one or more incidents)
    • An identified risk to the future value of service to the user (a disputed part of “Incident”? a “Problem”?)
    • [By abnormal I mean different from what it's supposed to be.]
  • In fact I think even this list isn’t fine-grained enough. There’s a significant difference between “an abnormal condition” that has only been reported (perhaps an “Event”) from one which we’ve decided has a real risk or impact.
  • It’s not shown in this list, but you can group the various concepts into a hierarchy or taxonomy, again using the significant distinctions between concepts.
• Now, map your concepts to useful terms. The more confusion there is in external sources, the more careful you will have to be. And you might have to change it later, or explain it at length to colleagues. Do not throw away your scrap paper. Show your working. Write your name at the top of every page. Do not attempt to write on more than both sides of the paper.
• Publish this to your team and make sure the definitions are clear enough that people can understand them while working.

Incident / Problem Definitions

Right, I suppose I ought to show what I’d do with the above concepts.

The important distinctions identified are: whether it affects user service or not (and that can be ‘no’, ‘yes but still within SLA’, ‘SLA breached’, but let’s ignore that for now); whether it has occurred or is a risk for the future; whether the effect (symptom, I wrote above) is linked to a known cause (condition). The risk fault-line is the one that ITIL terminology doesn’t help us with.

These are my definitions, for my current purpose (which is writing a blog article!):

• Incident: a disruption of the current value of the service to the user, breaching SLA
• Potential Incident: an identified risk of specific disruption to value of service to user
• Problem: a group of one or more Incidents or Potential Incidents with measurable symptoms, but without a Known Error causing it
• Event: an abnormal condition in the managed environment (infrastructure, applications, configuration), i.e. a value of some attribute of some component or components is outside a normal range (including failure!)
• Known Error: an abnormal condition that has been identified as the cause of one or more Incidents and/or the potential cause of one or more Potential Incidents (wordy, but actually I think this is pretty precise. Fault could work as the term for this)
• Potential Error: an identified risk of a Known Error emerging in the future (where there is no “abnormal condition” at the moment, but perhaps a trend indicates it, or a technical risk analysis indicates it)

Having identified the “fault-lines” we can see that some concepts don’t have terms: potential problem? Between potential incident and potential error, I don’t think there is a use for distinct “potential x” concept. And “potential event” – it would have a clear meaning, any attribute of any component going outside normal range – but these are not manageable entities. You could list them by listing the components, the attributes, and the normal ranges, but you couldn’t do anything with the list.

Process / Procedure

To shift ground to Vinod’s work, I refuse to get drawn into the “goals” vs “objectives” debate, but I have a few fault-lines in the process/procedure discussion that I feel strongly about.

• Processes must be capable of being broken down (decomposed) to any number of levels, and you can’t have a different term for each. So the terms “macro process” and “sub-process” only describe relationships of a process to a higher-level or lower-level process.
• A “value chain” is the top-level thing. It may or may not be a “process”.
• There is a concept of event-driven, single input, single output things with defined flows within them. In BPM talk, these are necessary characteristics of a “process“. Anything that doesn’t have these characteristics isn’t process – it could be a “process area” or a “function” – but if an organisation wants to use the term process more loosely it can do. It just has to make the definition clear.
• If both terms “process” and “procedure” are used, a procedure is lower level than a process.
• There is a concept of a process that falls entirely within one department (many valuable processes are cross-departmental). You could call this a “procedure“.
• There is a concept of a process performed entirely by one person, without time delays or message passing during the process, and described prescriptively. You could call this a “work instruction“.

In summary, existing definitions, ITIL or other, are not perfect, not robust and not comprehensive. You have to be prepared to build your own terminology and taxonomies.

It’s usually invoked to back a claim that there’s more to consider than just [whatever it is that is already being considered - often a technical product]. And this is nearly always a good thing. Obviously each of the three words embraces a number of related concepts – for example, a consideration of people requirements should bring in questions of skills and motivation as well as sheer numbers of people. But can the triumvirate of People, Process and Technology claim to be everything there is to consider?

.

Information

One thing I think is missing is the dimension of information or data. (Information and data are not the same thing, but we can understand them living on the same dimension, along with knowledge and wisdom. As does content, the term favoured in web-enabled business-to-consumer areas.)

Some people seem to regard information as a detail of technology, but I believe this view leads to incomplete solutions – in other words, information is very definitely something more to consider.

Consider first that people and technology are independent dimensions: if you change your systems, you don’t expect to have to change all your people. (If a change in people is required, it’s an undesirable cost of the new systems.) People and process, similarly.

Now: if you migrate to a new tool, be it service desk, procurement, access management, or any other “IT for IT” system, do you expect to have to replace all your information? No. And yet this is precisely what organisations are often forced into: costly and incomplete migrations of data, via difficult imports etc. Conversely, if you have information critical to the operation of IT – like your access rights directory – do you expect it to be accessible only through one tool? No. At least we shouldn’t put up with that any more.

Thus, information and technology are separate dimensions.

In Organisation X, a hypothetical but representative company built up of many that I’ve worked with, the People dimension is well considered. You can quickly find out who’s there (actual). You can find out who’s supposed to be there (plan) and how they’re organised. You can even get hold of a register of skills and there’s an audit of what skills are needed that don’t exist (except the audit was last done in 2007). The Technology dimension is well managed. You can kick the servers, you can drop a printer on your toe, you can log in to the applications. They’re relatively tangible. There is a technical architecture and an architecture team although no one’s quite sure what they do. They’re not so good on process management, as they still see processes only as sequences of activities and don’t properly manage outputs, but the issues are at least understood. But if you ask about information, the question can only be understood within each application or system; it’s only tangible if you log in; there is no way of determining what’s supposed to be there. As a result, new technology is procured with no more consideration of information needs than the vendor saying “we can import data” and “open SQL interface”. There are silos of information all over the place, even though People, Process and Technology are considered in every project and every management meeting.

I’m not even going to get started on Configuration Management in this post – but that is precisely information management for “IT for IT”.

For more on data management, look up The Data Administration Newsletter, or the dm-discuss list at Yahoo!. There are many other good sites too.

.

Architecture

Another aspect of IT planning and management that could be introduced is architecture, or Enterprise Architecture. In fact I don’t think this is a separate dimension – instead, it’s part of all the above dimensions. Enterprise Architecture (whatever Wikipedia says) covers the frameworks and structure for each of those dimensions – principally systems and processes, you might say, but very much information architecture as well, and often organisation architecture. (Systems architecture is sometimes divided into technology and applications architectures. Process architecture is sometimes subsumed under business architecture, with some of organisation architecture.)

(Some add “partners” as another dimension, but I’ve always been happy to see internal organisation management as an aspect of people management, and further along the scale, management of partners as a further aspect.)

We can therefore view architecture in each dimension as one end of a scale:

For more on architecture and data management as they relate to ITSM, see ERP for IT.

.

So, People Process Technology and Information, everyone. Remember these four things and consider them in all your planning and review activities. It won’t catch on, of course, because lists of three are far more memorable – and because tetrahedrons can’t be drawn in proposals as easily as triangles.

Now, I agree with every one of his ten reasons, but I immediately thought of some different angles on the approaches he recommends …

• “Insufficiently detailed requirements – This may be pretty self evident, but the rush to get started on a tactical basis often overpowers better intentions. Take a little more time and make adequate, detailed plans.”
  • Rushing into initiatives with no planning is obviously a bad thing, yet all too common. But more planning does not always help, unless you have a fairly stable business environment (who has?) and excellent business analysts.
  • A bigger reason for failure is believing that initially defined requirements are accurate; adding more time and detail to plans is unlikely to fix this. Better solution: understanding that requirements have to evolve.
• “Insufficient attention to process – While almost everyone recognizes the need to pay attention to best practices, such as ITIL, in a very large number of strategic initiatives, process education is dealt with in an ad-hoc manner; often after the initial planning is done. On the other hand, problems can arise when a religious approach is taken and ITIL, for instance, is treated as more gospel than departure point.”
  • … Can’t disagree there. ITIL is not gospel – but on the other process culture is not ad ad hoc thing.
  • There are often reasons other than ignorance for not paying attention to process … like wanting quick results. IT leaders should feed desire for quick results by implementing in short iterations, while paying attention to quality and management of process by, for example, refactoring out the inefficiencies, and continued training. These are some of the Agile Software Development principles that I think are more widely applicable.
• “Executive support – Just in case you didn’t realize it, you’re all important in the success of strategic initiatives. The lack of firm commitment from executives can seriously disrupt strategic initiatives.”
  • Very true.
  • “… Our rule of thumb is that you, as executives, will need to see documented results no less frequently than every six-month. This can put constraints on project planning, but it can and should be achievable with the right detailed approach.“
  • Wait. Every six months? In Agile initiatives, that would be for ever. Can we aim for working results every month?
• “Inadequate or waffling budgets”
  • OK, budgets are hard (guesswork is easy but pretending it’s real is hard). I would rather see departments building as much of the budget as possible against an agile “backlog”, with costs earmarked against features. After operational / core budgets, tied to already-established services, that just leaves the “waffle” for requirements that haven’t emerged yet (not yet on the backlog).
• “Staff buy-in” – nothing to add
• “Resistance to change” – it’s a major issue; but requiring small amounts of change at a time for tangible benefit (through agile iterations) has got to help.
• “Managing expectations” – also important. And delivering change in small, frequent packages helps. In fact, user expectations become your friend: by discovering them more quickly and in more detail, and by including users in the development teams, you’re going to get better long-term value.
• “Lack of follow through”
  • A culture of frequent iterations helps enormously in creating a culture of momentum. ITIL’s emphasis on continual improvement can become a reality!
• “Lack of integration and Lack of automation”
  • Again, it’s a major issue. Continued attention is important to streamlining the systems and support. And this seems to me exactly like the Agile principle of refactoring.

It may sound like I’m just promoting short iterations, but other Agile principles have to be included as well: open communication, including the customer throughout the cycle; unit testing / acceptance testing to prove quality.

Big Requirements Up Front is not the only approach.

• I have not been active very much on LinkedIn until recently, so I can’t judge the discussion groups there. But there are a great many ITSM or ITIL groups, some with willing experts. Some, admittedly, are dominated by job ads or requests. I’ve yet to find one that shows a good level of activity and content, but the groups are evolving.My impression of the software capability is not good though: yes, it lists recent discussions, but it doesn’t provide a way to jump to the most recent post in a discussion; it doesn’t flag which discussions you’ve participated in, and doesn’t provide any way to subscribe to a discussion or flag it as interesting – all of which are standard features of discussion board software like phpBB, vBulletin (which is not free), or SMF.
• I like the ITIL Community forum: it has plenty of willing experts, and the software base is OK. It suffers from a large number of beginner’s ITIL exam-related questions (which are in scope; there’s a big need) and very basic questions from people who show no signs of having done any research and don’t give details of what they really need. I don’t think that’s a bad reflection on the board, just a bad reflection on humanity. (Look at Java and other programming boards for exactly the same problem.) Note – when I say “willing experts” I don’t mean people willing to answer basic questions. In fact, the ITIL Community has “grumpy experts” and when I grow up I’d like to be one.I do take issue with some of the ITIL Community’s admin policies, e.g. requiring you to post a verification code with every new thread or reply you preview or submit, and disallowing any links posted in messages (see this post, for example). Even for long-term registered users. There are better ways of dealing with off-topic and commercial spam than treating everyone as a bot.There are some excellent discussions and insights, and that’s ultimately what matters most.

• The itSMF international has a discussion forum. Like most, you have to register to post (a very good practice); it looks like you even have to register to read posts (I don’t see the need for that).I’m new to this group so I can’t judge it, but naturally it has many of the principal figures there, and carries authority in the publications and qualifications areas. The best practices area is moderately active and the quality of discussions is good, but I think the board could grow a bit.
• Addition: I forgot to mention Yahoo Groups. As with LinkedIn, there are a large number of groups related to ITSM here, but the largest and most active is ITIL Service. Good discussions here. I don’t care much for Yahoo Groups’ web interface, but you can participate via email, which is effective.
• The enticingly named ITIL Forum: this has been pretty active in the past, but seems to be overrun with spam in the past month or so. I’ve sent a message to the administrators to see if it’s still actively managed.
• The ITSM Portal forum: about 5 threads a year, many not answered. ITSM Portal also has a number of groups at LinkedIn.
• Datamation‘s boards have an IT Service Management forum, but it’s really not very active – a couple of threads a month

A year or so ago, the Skeptic posted a list of forums. I have nothing to add about the ones I haven’t mentioned above.

Are there any other good ones?

A good community, with experts and experienced people (which isn’t quite the same thing!) willing to contribute, and getting something out of it; and a minimum of commercial promotion and of noise-level questions … and an absolute minimum of off-topic “longest thread on the internet” trivia!

This is not directly controllable by the hosts or sponsors.

Good discussion board software, with good controls for identifying read and unread threads and posts, and for subscription and email notifications, and a search facility. There’s no excuse for not having this in place. And there should be a clear way to get help or ask questions about the board itself. I think it’s funny that people can set up boards discussing Service Desks without offering one.

1. I am not a professional software developer or data architect, but I’m very interested in these disciplines through ITSM contact with practitioners and teams. (I often feel there’s a great loss of value in the lack of mutual familiarity between service management and development/data communities.) One of the approaches I have been particularly interested over the past year or so is Agile Software Development, the Agile philosophy – see the Agile Manifesto, and some of the key practices associated with Agile development like test-driven development, refactoring and design patterns.
2. I observe that many ITSM projects (“implementations” or improvements) suffer from issues with long timescales, inability to cope with changing requirements, lack of user acceptance, and so on. Not all, but those that do suffer tend to be blind to the causes and show resigned acceptance to such issues – or even to be blind to these issues.

Those issues, and others I haven’t listed, are very like the kind of things the authors of the Agile Manifesto were experiencing. Agile development is very successful in certain environments (though not all – and more traditional “big requirements up front”, “big design up front” methods have strong defenders). Could Agile principles be applied usefully to IT Service Management problems?

Agile Service Management

I’ll admit I don’t think that agile methods can address all ITSM needs. For example, a high-volume Service Desk probably should not be run as a self-organising team that values individuals and interactions over processes and tools. Large parts of day-to-day service management are repeatable activities that need process standardisation – and the ITSM profession has been struggling to promote process control for decades. And there should be enough commonality in request handling and configuration management needs that in-house tool development is not the right option for most companies.

But everyone requires process development. You can’t just take the processes from the ITIL books and use them. And most commercial toolsets require substantial amounts of customisation for an effective implementation. In these areas, practices like frequent iterations and focused teams including users and specialists can surely have value.

There’s something worth investigating here, and I propose to examine principles and practices, see where they can be applicable, and what kind of coherent approach we can build.

Scope

Just as software and database development build capabilities that support business processes, I think Agile Service Management will be most applicable for the disciplines and teams building capabilities that support IT Service Management. That is, developing IT for IT rather than IT for business.

Secondly, I’ll focus on modular self-contained improvements rather than building the entire ITSM capability. There is a need for architecture, massive engineering and “big design up front” in large-scale ITSM systems. (Some of the best thinking on this issue can be found at Charles T. Betz’s blog erp4it.) But every environment, even the largest and best-planned, needs continual improvement; and many organisations can get greater value, and closer alignments to requirements, by implementing in smaller steps of proven value. It’s the other end of the scale.

Compared to Agile Software Development, ITSM development usually needs to develop or improve the IT processes much more than IT develops business processes (although there’s probably a useful debate to be had on that!). In fact, there’s more emphasis on process and less on developing software. These topics need to be explored more, though.

Key Practices

In future posts I need to look at the Agile Manifesto principles, and other Agile practices, but for now I just want to touch on the key practices that I think offer potential value.

• Short, frequent iterations (of a few weeks), each delivering a self-contained (package of) requirements. Yes, this could help with budget control and management commitment – things that ITSM teams often struggle with. But the main reason I like the idea is to support alignment with customer requirements. A six-month project developing Service Operations processes and organisational change addresses the requirements as they were understood at the beginning of the six months. A set of one-month iterations, delivering functional operating processes and business value in each iteration, not only gets value to customers more quickly, it also makes it much more likely that the changes are what the users need and that emerging requirements can be swiftly handled – and it helps with user and management buy-in.
• Dedicated team including customer participation. Agile methods promote a team working together from beginning to end of an iteration, communicating face-to-face (including formal daily meetings), rather than separate teams communicating through formal requirements documents. I see the ‘customers’ of a service management development being primarily any IT staff, including those involved in day-to-day support (who would be users of a service desk tool, and an incident management process) and software developers (who would be users of a release and deployment process among other things). There’s a case for having the customers’ customers – ie the business end-users of IT – included as well. Having representatives of these customers in the dedicated team, continuously, would bring the same benefits as it does in Agile Software Development: aligning the delivered solution to real requirements, not to the shadow of requirements captured in some document, or the process developer’s (or tool vendor’s) assumptions as to those requirements.
• Refactoring: Instead of treating delivered ITSM processes as cast in stone, or difficult to update, teams should focus aggressively on optimising them. The philosophy of continual improvement embodied in ITIL practically demands this; Agile principles will enable it. Continuous attention to excellence and design matter. (I need to be careful about the terminology. Strictly, refactoring is changing code to make it cleaner and more maintainable without changing the functionality. When I think of refactoring an ITSM process it will of course change the job of the user (the IT staff member) – but without changing the business objective achieved.)
• Design patterns: I’d like to interpret ITIL as a set of design patterns: good reusable solutions to specific common problems. There is a vast amount of good material in ITIL, but not every organisation can benefit from every piece of it; a design pattern structure might help to clarify. With ITIL V2, we saw a lot of companies overlooking valuable guidance because they’d “done the basics” and were not clear on where a specific piece of guidance could help. A pattern interpretation could unlock this value. With ITIL V3, many companies are concerned that it’s too big or too complex to grasp. They are looking for modular, incremental ways of adopting best practice: presenting best practice as design patterns, stating what problem it solves (do we need this yet?) and what pre-conditions it has (are we ready for this?), is almost essential.

More to follow.

Closing thought

There are many different software development methodologies, on both the agile and the “waterfall” sides, all “best practice” and having passionate advocates. But there is only one ITIL. Why? Is ITSM simpler? Not much. Is ITSM less professionally and thoroughly addressed in most organisations? Is it because everyone does in fact develop ITSM with different approaches (all using ITIL as guidance) but it’s not treated seriously enough or understood well enough for us to promote different approaches?

What good, specific objectives or contract terms are there for a CMDB, or more accurately a configuration management improvement project?

Here’s one.

Poll around for definitions of a CMDB/CMS/etc. Among the answers, you’re bound to get things along the lines of “a central database for managing IT” or “the one source of the truth for ITSM processes” – and this concept is an important one. ITIL version 3, and many tool vendors, help out by recognising that this “central database” is not (can almost never be) a single database, but a collection of (“federated”) systems. Nevertheless, principles of Master Data Management still apply, and there needs to be some central management of what data exists where and which point is the master source.

By counter-example, consider an organisation with a good central database of CIs, which drives an auto-discovery system. Devices discovered but not in the CMDB are flagged for action. Devices not on the network can be flagged as “in stores”. The user department charge-back is calculated on number of devices in use (not in stores – obviously) – all good so far – but the guy who prepares the charge-back bills checks the auto-discovery system and charges for devices flagged as “in stores” but which were in fact active on the network. Logical – but no one else in IT knows this detail and lots of effort is wasted debating with user department heads why they are being billed for the wrong count of devices.

This example does not represent any one organisation – but it’s not fictitious.

In this case the billing person has created and managed his own data on what gets billed, and this data is not visible or auditable by the IT department as a whole. He gets his job done, and in fact gets a bonus for increasing IT department cost recovery. But configuration management has become weaker.

In another example (of not having a single source of ITSM data), consider a company with comprehensive registers of desktop and server hardware, and comprehensive records of software licences and internally-released software – but no correlation of which applications run on which servers. Again, this is not a fictitious case!

Analyst A gets on with her own mapping of applications to servers, because one of her projects demands it. She builds it in a spreadsheet based on weekly extracts from the server and software registers. Meanwhile, Specialist B is doing exactly the same thing, in a Microsoft Access database, correlating server element management system reports with software modules discovered on those servers. Both are working on the best tools they know. Both are doing the right thing according to their job objectives. But they are duplicating work, wasting a certain amount of effort – and by not communicating their results across the IT organisation, losing value that other teams could get.

Now, everyone needs to record their own data to get work done at some time or other. It’s possible that every ITSM tool out there started off as somebody’s private tool for doing something useful.

But, without stifling innovation or creating bureaucracy, what a configuration management project needs to do is set up the policy that all data records are known about and managed in the context of common goals. This doesn’t mean official registration of pilot or prototype efforts. It does mean official registration, and alignment of best master data sources, for all efforts that are then used as part of delivering IT services. Silo data should not be tolerated.

And to make it happen, some central role will be required – a Configuration Authority, perhaps. An ideal person to fill this role would be have some exposure to data modelling, and be good at communicating – selling, negotiating and facilitating.

I would even make the case that setting up such a policy and role is the first thing that a configuration management project should do – not mapping CI types, not going out and discovering data sources.

And not procuring, building or implementing a CMDB.

Here are some things I suggest will be the greatest focus for companies in 2009:

• Change and configuration management – although not configuration management on its own. I’m passionate about configuration management, and will write more on this in the future – but no one should do configuration management for its own sake.
  • Organisations will have to be more responsive to change if business prospects become less certain. Change quality must be high to minimise business risk – indeed, to preserve confidence in the IT service provider.
  • And by change management I don’t just mean change control for the operational infrastructure, I mean lifecycle change management all the way from business requirements analysis, which I touched on here.
• Service Desk, Request Management and Incident Management – let’s ensure that users’ productivity is maximised.
• Automation has always been a hot issue, but now more than ever it’s vital to ensure that companies know what they are automating – yes, I mean process, but also data flows – and that results can be achieved quickly.
• It hasn’t come to the forefront yet, but Capacity Management could become very important if infrastructure budgets are cut but business volumes need to be maintained. Let’s hope that business volumes are maintained.
• Vendor management and service level management have their place, but I see little appetite for concentrated focus on these areas.

But most of all, something which still seems to be difficult, at least in South Africa: continual improvement of ITSM capability, that is, being responsive to ITSM needs; and getting business value quickly in short controllable iterations not long risky projects. I think this should be achieved by … but that would be a subject for another post!

Don’t agree with my views? Let me know in the comments.

-

In the land of ITSM Continual Improvement, near the city of Process Development, there once lived three little pigs. Now the three little pigs weren’t as happy as the proverbial pigs in strategic, holistic information technology. They were continually being attacked by the wolves. They’d trying calling the wolves “customers”, and it didn’t help. So they got together and agreed that they needed to build stronger, best practice, houses made of brick. But they couldn’t agree on how they should do this.

One process at a time

The first little pig said to himself, “Well I have a house made of straw, and it’s basically working, although I do keep having to repair it after the wolves have visited. All I need is gradual improvement.” So he called in a consultant and the consultant told him what walls to build. The little pig was taken aback at the proposed cost, however, and decided to build it in stages. The consultant and he agreed that “Service Desk” was the most important wall, so they built that first. And – after six months – it was a very fine wall, with large windows complete with shutters on the outside and blinds on the inside, and an ornate door with a smart brass knocker and an electric bell and a post box, all aimed at providing a good interface with the customers.

The wolves huffed and puffed and blew down the Change Management wall (still made of straw), and the Service Level Management wall, and the don’t talk directly to specialists wall. And the first little pig was outsourced and had to run off and try and get a job with the other little pigs.

Cut “unnecessary” cost

Meanwhile, the second little pig had watched the beginning of the first little pig’s project and saw that it wasn’t going well. He called in a consultant and explained what he wanted. The little pig was even more taken aback at the proposed cost than his brother had been, but he was determined to build all the walls at once. So he asked the consultant to trim as much cost as possible from the project. And it got under way. The first thing they did was to knock down the little pig’s existing wooden house. After three months there were four walls in place.

The wolves came in through the empty window holes and door holes.

After another three months there were windows and doors and a roof. It didn’t look very pretty but it got the job done.

Until the wolves got really angry and huffed and puffed against one wall. It fell down. The little pig ran off in fright, realising that he had trimmed the costs too far and there was no integration between the walls.

Deliver value quickly

The third little pig had watched his brothers’ negotiations and projects and saw that they weren’t going very well. He called in a consultant and asked the consultant to mediate a discussion with the wolves. (“Mediate” is a grown-up word meaning “stop them from eating me” and “please don’t use that line about chickens being involved and pigs being committed”.) Together with the wolves, he outlined a minimum structure that could be delivered quickly and be of value. Yes, there were some ugly scenes with the wolves demanding the little pig’s backside and complaining that it wasn’t their job to define requirements, but I won’t scare you, dear reader, with the details. The consultant and the building contractor reluctantly agreed to work in short stages. After two months, they’d built a service counter and a change control window. The wolves huffed and puffed but mostly got on with their work. After another two months, they’d filled in a leather-bound Book of Configurations (but not coloured it in yet), and added another service counter and a status display. After another two months, the walls were up (but not plastered) and the wolves were not huffing and puffing very hard and everything was fine.

Sadly, there was no headcount available to give his brothers jobs, but the third little pig lived happily for the rest of the financial year.