First NHS IT Service Desk In England To Secure 3-star Accreditation – Informatics Merseyside has become the first NHS service desk in England to be accredited with 3-star certification from the Service Desk Institute (SDI) Read more here
Is The BIS Growth Accelerator Scheme Worthwhile For Technology Startups? – Caroline Baldwin reports on why few technology companies are taking advantage of the additional financial and growth support available. Read more here
Do You Have A Service Management “House Plan”? – Matt Hooper explains why one process at a time isn’t going to cut it. Read more here
Problem Management – The Value In Not Knowing– Ryan Ogilvie celebrates the opportunity of unrealized value. Read more here
FBI Warns: Criminals Could Walk Free If Tech Companies Encrypt User Data – As tech companies try to outdo one another in the battle to address user privacy concerns, the FBI is warning that new encryption methods might hinder investigations. Read more here
Should I Upgrade to Mac OS X Yosemite? – Golden delicious or bad apple? Read more here
How Microsoft Appointed Itself Sheriff Of The Internet – Cyber criminals, digital crime fighters and collateral damage. Read more here
It’s inevitable that we will encounter change throughout our personal and professional lives. New products are launched by businesses; people move house and football teams get promoted (but sadly not my beloved Derby County this season).
Many organisations will have some sort of Change process, but in my experience, that process is often applied rigidly to police implementations to the production environment; constrained by our ITSM tool; and is mired in bureaucracy leaving people to get bogged down – and sadly – miss its true value.
As IT professionals, we must be able to understand, plan for, adapt to, and deliver our customers’ needs whilst balancing quality, control, and conduct effective operation of our services. This is no mean feat.
What I want to share with you in this article is how you can build on your existing change process or processes and bring them together to help develop an end-to-end solution that works for you.
Meet the people
When I started looking at our existing change process, I quickly became concerned (and bored) reading a lot of documents ranging from lengthy procedural documents to copious meeting minutes. As a Change Manager, if you struggle to make it most of the way through the documentation, you can’t expect everyone to follow and appreciate it.
I quickly realised that the best way to learn about – and gauge opinion on – the subject was to meet the people that carried it out – the IT professionals of the organisation. The easiest way to meet vast majority of people was by arranging informal 1:1 meetings; have impromptu chats over the water cooler and buying the odd coffee or two.
Additionally, be sure to meet your customers to understand their perception of how the IT department delivered their change-related needs.
Very quickly, you can get different pictures and interpretations of how a process works in practice just by talking to people. Equally, I was able to draw some common themes by getting responses along the lines of:
“We’re good at big projects but not at the smaller stuff”
“There is little or no documentation or communication”
“It’s quicker to code a solution than get anything done in our tool”
“There’s so many obstacles and bits paper to fill in”
“We only hear about a change when it’s about to go live or after the event”
“It’s just a box ticking exercise”
Quick Wins – Work with what you have
Against a backdrop of varied opinions, unwieldy documentation and difficulties with the tool, it’s easy to think there’s a mountain to climb!
So I looked at what low hanging fruit we could work on and developed a short term plan focusing on what small improvements I could make with the tools I had. Quick wins included:
Developing a few “Standard Change Templates” with a couple of teams for changes that were routine, repeatable and had known risk and impact.
Introducing a series of questions on the change records for people to complete – effectively giving them a script to follow covering the risk, impact and implementation surrounding the change.
Attending team meetings to demonstrate how to raise a change in the tool.
Sending out a fortnightly newsletter giving advice on how to complete change tickets, inviting people to make suggestions and so on.
Get Everyone Involved – Revolution by Evolution
As much as the quick wins helped, for the longer term, it was apparent we needed to not only improve on our Change Control Process but push the understanding that change starts a lot earlier than being simply ready to ‘go-live’.
In order to achieve this, I needed resource and senior management support to make it happen. That is when I developed the idea for a “Change Away Day” which included:
Representatives of all teams within the IT department with a variety of experience in the change process
A proposal to Senior Management outlining the issues, setting objectives for workshop and providing a timeline of not only the day – but the next 3-6 months.
A basic introduction to Change Management replacing the jargon with a theme people can relate to. We used the idea of building or moving house:
“What” (are my requirements) i.e. where do I want to live?
“How” (am I going to design it) i.e. architects will to design it with me before any trenches are dug by the builders
“Why” (do I want to live there) i.e. assess and evaluate things that you like and dislike; the local schools; getting a mortgage and so on
“When” (is it going to happen) and “Who” (is involved in delivering it) i.e. you can’t move overnight and will need some help to do it
“Quality” (is it fit for purpose) i.e. do we have a safety certificate, are the utilities working and so on?
“Approval” i.e. those final checks like exchanging contracts, moving van ready and packing your bags
Guest speakers from department covering other processes and how they interact with Change Management – in this case, Testing and Solution Design Assurance.
A range of activities that:
helped with the learning;
reviewed the current change control process
developed principles to incorporate Change Management into the earlier lifecycle of development and projects
As away-days can be expensive from a time, resource and cost perspective, a series of follow up meetings – lasting no more than an hour -were held over the next couple of months to review, improve and ratify specific changes to the process.
From Change Control to Change Governance
After the workshops were complete, the main principle was that Change had a start point, a delivery mechanism and an end point. From this, we developed a Framework to incorporate processes that were involved with these principles, namely:
The Start Point
RFC Review – a mechanism to initially capture customer demand and suggest its feasibility, size and so on
For large changes requiring effort this could become a formal project following the established Project Management process
For smaller changes, we would look to group these together as releases.
It is possible for projects and releases to overlap for delivery – but this is a subject for another time
The End Point
Before implementation of any change to the live environment, the existing Change Control process had to be followed to obtain final approval.
We also use the opportunity to realise the following improvements including:A new CAB structure with specifically invited attendees and a new agenda format
A Risk & Impact Calculator to help score changes in terms of “Technical Risk” and “Service Impact”
The increased use of Standard Change Templates
Underpinning Strategies & Processes
A broad summary of the areas that need to be engaged or considered as part of any Change-related delivery.
Sealing (and documenting) the Deal
This is arguably the most important point, without engaging people; the re-launch was never going to get out of the starting blocks. The key points and activities to consider were:
Presenting back to Senior and Middle Management the key points and what they have gotten for committing time and resource
It’s important to treat changes to processes like any other change – I took this to CAB for review and approval before implementing and communicating the framework. After all, you cannot expect people to follow processes if you do not lead by example!
Tailor the communication to your audience – for me, I identified three types and the level of information they needed:
Partnering and Project Management – a group consisting of Business Relationship people – received a strategic overview of the Framework that incorporated their processes
Implementers – typically technical staff involved in developing, raising, assessing and implementing changes – received an overview the framework, their responsibilities within the process and the changes to Change Control
Impacted teams – (teams impacted by change implementation e.g. Service Desk) –received a high level overview of the framework, how/where to find information about upcoming changes and why it matters
Documentation needs to be succinct and will have varying levels of detail, specifically for us, we produced:
Change Policy – the overarching document covering the Framework, the processes and the “rules of engagement”
Processes that were straightforward documents combining the high level process flows with simple procedures for each step required. Areas included:
RFC Review – an initiation process owned by the IT Business Partners to bring customer’s request for change to receive a quick review or ‘first pass’ by Technology experts in terms of strategy, estimates and being worthwhile.
Project Management – the formal methodology for delivering projects
Release Management – for combining and scheduling the build, test and deployment of changes
Change Control – to implement a change to the production environment.
Training Guide – short and to the point – these were given as small A5 hand-outs to staff involved at different levels of the process.
Don’t let Change Management become restricted to ONLY the production environment. It’s important to protect it, but it’s even more important to help plan and facilitate change at the beginning rather than the end.
There is more than one “CAB” – keep in mind that throughout the lifecycle of a change it will be reviewed, rejected and approved many times at the Business, Project and Technology levels before it is ready for implementation.
Play the game – as a Change Manager, you will be expecting people to follow the rules for technology, and it’s only fair you do the same for process.
Make sure you baseline – be pragmatic about what you can achieve and be transparent about what is in scope. For example, we started off with formal Change Control for a couple of years, then brought in the Framework and are now working on linking it to Release Management.
Get everyone involved – by engaging people at the beginning, it makes the improvement process a lot easier – especially when’s “for them, by them”
Let’s face it, processes are boring at best necessary yes, but not something that gets people out of bed in the morning.
Maybe it is the control it tries to exert on the masses like an authoritarian adult trying to keep the kids under control. We are all a rebellious lot and the same goes for our rocky relationship with processes. Unfortunately, we can’t really live without them. The best and brightest might, because they will do the right thing in spite of process, but for the other 90% of us and for the sake of scalability, there needs to be clear guidelines.
Common process pitfalls
There are some common pitfalls for business around processes.
1. People need to feel that it ‘works’ for them. In other words, they have to see that a process makes a difference, for the better, to their day-to-day operations. There is no point in creating elaborate, complex processes just for the sake of it, or to make you feel that you’ve earned that ITIL badge, or justify that expensive BPM course.
The whole purpose of a process is to break down something complex, into manageable steps for everyone to understand and follow, thereby ensuring consistent work practice.
2. If you cannot measure whether process is being followed, there is no point in having it. You won’t be able to confirm that it is working, and you won’t be able to improve, because you won’t have any baseline. Without continually refining and improving your processes based on real world feedback they will become obsolete, because people will either not follow them at all, or create their own ‘parallel process universe’.
3. People need to understand how a process supports the organization’s policies. If the process doesn’t enable compliance to company policy it is doing more harm than good this is pretty obvious, but it is surprising how many times this happens, especially at micro or team level. People do what they consider to ‘work’ for them, but in the process they have cut the oxygen cord to the mothership…
So, what are some strategies and practical tips to ensure processes become stepping-stones instead of stumbling blocks for your organization?
Below I will briefly outline each of the components, with a common example to clarify the concepts from a practical/real world perspective.
Company Policy & Process
Start with your company policy; make sure that your process 100% supports it. The next step is to outline and briefly describe each step in the process so that people can see how and what each individual step is about and how it supports the company’s policies. Without this as a starting point your process is not worth the paper it is printed on…please don’t laminate it and stick it next to someone’s cubicle. It won’t make any difference.
Example: Company policy specifies that customers can raise a major incident or outage, and that the company will respond within 30 minutes of the incident being logged.
To reflect this policy, a major incident process step must exist in the company’s incident management process.
Once you have described the steps in your process you should be able to easily identify the different work Instructions you could create to guide and educate staff on the process. Work instructions are critical for training and reference in case someone doesn’t understand how to put something into practice. Work instructions will potentially drive back towards fueling your continual improvement.
People will often not question high level process, or make suggestions at a high or abstract level about how they can improve their day to day operations. However, put something practical and lower level that they deal with every day in front of them, and they will very quickly tell you why it doesn’t work. You can then simply ask them what should be done differently with the work instruction as a practical reference, which then feeds back to process improvement. This takes continual improvement to the people, instead of leaving it with the analysts.
Example: A work instruction exists that outlines the steps a Support Consultant will follow in order to manage a major incident to completion, including escalation and communication channels within the business.
And, finally, for each step, document the business rules. Why is this important? To make sure you can map your processes to technology, and to ensure technology (ITSM software and tools), supports your business. This is a critical success factor, especially when choosing a new or improving an existing ITSM solution.
Example: A business rule specifies that an email alert is triggered to an executive email group when a major incident is logged, and again 15 minutes prior to the SLA of 30 minutes being breach if no contact has been made to the customer.
Tip: Be careful not to document the business rule in too technical terms, i.e. how it relates to the technical aspects of the ITSM tool make sure it is independent from how it is implemented in the tool. For example, don’t document the triggers and tool configurations you need to deliver the rule, otherwise your process documentation will have to be revised should your ITSM tool be updated or changed.
As the saying goes, a picture is worth a thousand words, so let’s summarize with a diagram:
Make sure your process backs your policies.
Describe your process steps.
From the process step’s description, derive work instructions for each step.
Document the business rules related to each step.
And, finally, give your most important asset in continual improvement (yes, people), something practical to chew on, namely work instructions, thereby providing them with easily identifiable building blocks in your continual improvement framework.
We all know that as we get older we lose some of our faculties and our usefulness changes. One interesting aspect of ageing workers is that it isn’t just about being good, bad, better or worse. In many jobs – and jobs as diverse as consultancy and bricklaying come to my mind – the actual deliverable usefulness changes as our strength and endurance fade but knowledge and experience grow to compensate and allow us to deliver continued, albeit different, value.
I suspect this feature, seen in the human species, is widely applicable, and extends even to best practice frameworks.
Let me try and explain what I mean.
For those of us who are parents, the first step to accepting the inevitable path to obsolescence and replacement is when we find ourselves asking our children to get something for us – because bending down or going upstairs is easier for them than us. Once past that point you have accepted not only aging but your progeny being better at things than you are. Inevitably that superior ability will spread from minor physical capability, like getting upstairs quickly, through to intellectual and perceptive ability such as understanding the world and innovation. For professional footballers, this tends to happen around 30, after which experience and positional understanding need to compensate for sheer speed and strength. For non-manual workers it is much later, but it happens just the same. The positioning of senility in best practice frameworks is less precise and perhaps still open to discussion.
Like parents, ITIL was originally young and fancy-free, and the only go-to place for building ITSM processes and practices. But in due course, ITIL spawned progeny (like COBIT, MOF and ISO2000) – or alternatives if you prefer to see it that way. And some of those newcomers have now matured, as children do, to offer stronger options than ITIL for some aspects of the ITSM best practice world.
So, maybe ITIL has started to show its age, the joints are creaking a bit and we see some really interesting challenges from the next generation who understand the new environment a little better and maybe still have the flexibility to adapt more. More crucially, we see initiatives that don’t have to be bolted on to a historical behemoth of existing products and commitments.
Of course ITIL still has massive value. Like experience in craftsmen, the years of refinement, the market pervasiveness, global understanding and more mean ITIL still leads and delivers real value to those who use it to help them get better at service management. But like the aging craftsman with good apprentices, have we reached the point where ITIL has something to learn from the newcomers, rather than trying to stick to the idea that age and longevity equals right and correct and form the only way to go on?
Certainly it seems to me that some of the new ideas being floated challenge established ITIL detail in many ways but not ITIL’s experience, position and reputation. Preserving that (for want of a better word) authority in the industry will rely, to some degree, on accepting where others might now be better. Most of what originally went into ITIL came from elsewhere. Quite deliberately there was very little original put into ITIL guidance – the whole point of best practice is that it is out there working in the best organisations. Since ITIL’s launch we have seen, in turn, ITIL’s ideas instigate and invigorate new best practice ideas. That’s the good part of getting older, seeing your children be successes, perhaps even seeing them outdo your own efforts.
In practice, I wonder about ITIL in two ways.
It should be no surprise that in terms of basic mechanics and core strengths – like process details – ITIL is falling behind its younger children, friends or competitors. But the breadth and broader strategic focus that came with the later versions still sets it apart and gives it value – but perhaps a different kind and less exclusive value – experience taking over from strength? It is encouraging to hear Axelos talk about new white papers discussing the integration of ITIL and others best practices. But where does ITIL go? Should it compete head on with other process approaches, seek an overarching integration role, or simply claim it is the original and best?
Is ITIL flexible enough to take on new ideas, or should those ideas look to younger backs to carry them and just point out to them? As just one example, recent discussions questioning the merits in retaining a separation between incident and problem make real sense. But where will they get properly documented to gain broad acceptance? Because, for sure, we need a well documented alternative approach for any degree of acceptance. (Interestingly much of that idea has come from old human heads rather than young upstarts. I suspect that once the young upstarts do get going in our industry then the degree of challenge to established idea might go up by a few orders of magnitude. I’m rather looking forward to it all!)
As an ageing parent myself, I know the best chance of contentment lies in accepting my children’s now superior abilities, and in letting them do things for me. Certainly they now solve more challenges for me than I do for them. There is satisfaction that your genes – and lots of work – are actually firmly embedded into the future – the quickest route to immortality may indeed be via your children?
Of course, analogies should not be pushed too far and we need to see best practice use in its own right. We should expect much more overlap, some competition and hopefully a bit of mutual support. Oh, hang on; maybe they are like families after all?
The golden rule
But the golden rule for using best practices – be they for ITSM, cooking or anything else – has always been to look at all the relevant ideas and build what is best for you. In ITSM now we are both lucky and challenged to have a wider range of ideas than ever before. That might actually lead to diversity of ITSM approaches rather than the convergence to one (ITL based) view as we have seen in the last 20 years.
ITIL is the product in charge still, its market position makes it well placed to lead and inspire. Integration would be wonderful, but unlikely, coordination would be helpful, competition would be disappointing. Whichever way things go, ITIL made this happen, and should be proud of that. Learning from your children is a good trait, I’m learning a lot and enjoying the experience, hope ITIL will too.
 All of these acknowledged their basis on ITIL in their early versions
Authorities today announced the addition of new processes to the IT service management frameworks. It’s long been recognized that many common practices have thus far been shunned in the popular ITSM frameworks. Early reports indicate numerous new processes, functions and roles are being added to the guidance. Long ignored, these newly accepted processes have been quietly slipped into the best practices. Officials have downplayed the inclusion as little more than “minor corrections”.
The newly-included processes are outlined below.
The process for determining who’s at fault when things fail. Most people think this is part of service operations, but it is actually part of the service design lifecycle phase. You should always know who to blame when things go wrong.
“Proactive indictment management reduces the time and effort required to place blame during and after major incidents, and is part of a healthy service management program” says Jeremy L, who declined to identify his company. “I’ve seen way too much effort spent in reactive blaming, when simple, best-practice planning can streamline the process”
Refuse and Diversion Management
The process of telling IT customers ‘no’ by either direct refusal or diverting their attention to another “shiny object” to placate them until they forget about their true need. Common practice is to include this informally as part of relationship management or capacity management, this newly recognized process brings focus to the practice.
The process for managing wounds gathered over the years. Seasoned ITSM professionals know how quick customers are to forget about significant service outages. This process ensures that decision-support information about each and every IT failing is available to customers at all times.
Knowledge is power. Knowledge manglement describes how to maximize the benefit to one’s self and minimize the value to others in an effort to exert superiority. The new process includes best practices for withholding, modifying, misdirection, omission, and otherwise limiting the value of information to others, especially in other departments.
Change Adverse Board (function)
The newly included function causing the most international stir is the Change Adverse Board. This board has long existed in many organizations, meeting informally in break rooms, cafeterias and coffee shops. The function of the group is to discuss pending changes and to formally compare and contrast them against “how we’ve always done it.” The board provides a great deal of organizational inertia, and effectively undermines all efforts to change.
Problem Manager (Role)
The definition of problem manager has been supplemented to include it’s more common connotation – that of an IT manager focused on IT Transformation who “makes a lot of waves.” Jessica L from ITishell said: “I once worked for a problem manager. She was always talking about how we can improve service delivery and better align with the customer. Thank goodness they finally got rid of her.”
How has the news been received?
Nigel Geil of TrainWreck, a global training company, welcomes the new additions. “TrainWreck was the first training company to include these emerging trends in our ITSM training programs. Our clients are working professionals who need and expect the very latest in ITSM practices.”
The global ITSM community is mixed on the announcement. There is far from universal acceptance. Numerous practitioners took to social media to celebrate what they see as recognition of the daily realities they face. Said one: “we’re just keeping it real.”
A consultant who asked to remain anonymous had this to say: “this announcement reflects a disturbing trend of framework owners’ to rapidly update best-practices without the traditional decades of dialog, committees, and international involvement.”
Framework owners expect full community buy-in, and are anticipating additional changes in the near future. They are seeking industry input.
Get your ideas for new processes heard by submitting in the comments area below. Please include the process name and a brief overview.
Lather, Rinse and Repeat (LRR). Straightforward instructions. Hard to mess up. Or is it? If you follow these instructions, when do you stop?
The phrase has come to be indicative of two things; a) a way of pointing out instructions, if taken literally, would never end (or would continue at least until you run out of shampoo), or b) “a sarcastic metaphor for following instructions without critical thought”.
The author Benjamin Cheever wrote about these words in his book “The Plagiarist” (SPOILER ALERT – in the book, a marketing executive becomes an overnight legend by simply adding the word REPEAT to the instructions. Of course, sales of shampoo skyrocket).
The point is this, this is a process and the process has not changed or been updated in a long while.
Are you sure it’s a process?
Yep. Here is how I know.
The base statement of “Wash Hair” does not cover the steps needed to complete the activity. LRR fulfills the steps. LRR is not a procedure, as the activities do not provide instruction on how to complete the steps.
So what is the problem?
On the positive side, the process is simple and easy to understand. However, the biggest issue with it is “Do I really need to repeat”? “What happens if I don’t”?
So what’s the point with regards to ITSM?
Let’s first look at the positive to LRR, it’s a simple process to follow, it isn’t complicated. Do we work to make ITSM process as simple as possible? My experience shows that we, as IT people, tend to grab Visio, graph every possibility without question, and produce a monster swim lane diagram. Do we add complexity because the customer requires it or because we have cool systems that do cool things? Or can we learn from the simplicity of LRR?
Another plus point to LRR, the process is universal and aimed at the end-user. Regardless of why or where you have bought your shampoo, you know what to do with it when you are ready to use it. You can execute the LRR process with little training and/or thought. With regards to ITSM do we design processes to help our customers or to help IT? Can customers execute IT processes with little training and/or thought? It is always interesting to ask why we (IT) do something. It is shocking to see how many times the reason focuses on making things better for IT and not for customers.
Then there is the negative, is the process a) even necessary, b) actually adhered to (I can’t say that I lather my hair twice, do you?). Lauren Goldstine takes on the need for LRR in a 1999 article entitled “Lather, Rinse, Repeat: Hygiene Tip or Marketing Ploy” In her article, Ms. Goldstine indicates that Repeat is probably no longer necessary due to the advances in shampoo tech, yet most shampoo bottles you look at will have the process. In ITSM do we spend time looking at how to make a process better?
Ok but seriously, what can ITSM learn from a shampoo process?
As ITSM practitioners, do we take the time to think about the processes we ask others to adopt? Do we work to remove obfuscation? Or do we trot out big ideas/opinions regarding how IT should work? To me, LRR is a reminder to design processes that can be easily executed and deliver desired results. With that in mind, here are my tips for process design.
Tips for process design
Keep it simple – look for redundant steps. Remove points of “distraction” from the process flow. Ask frequently, “do we really need this step?” AND “what value does the customer get from it?”. If you cannot answer the value question, most likely, you do not need this step of the process. Other tests to verify your process is simple – can people easily explain and discuss the process? The more complex the process is the greater the chance that people will not internalize it and probably will not discuss it with colleagues and customers. If the team is not willing and/or capable of talking about the process, how will you get continual improvement to happen?
Make it elegant – keeping it simple should not translate into “skimp on feature”. You should design processes to meet the needs of the business and to be easy enough to execute. The context of your situation should drive how elegant your process needs to be.
Customer first – design every process with the mantra of “Customer First”. Take the time to learn who the customer is, why they need the process, and what they expect from the process. If you determine that there is a gap between expectation and delivered value, determine how to close the gap.
Borrow liberally – don’t keep “reinventing the wheel”. Look at other processes (both inside and outside of your organization) and determine if the process/steps fit the context. If so, use them! The benefit is that IT teams should not need to undergo additional training since they already know how to execute specific steps. In fact, if I am in a service owner role, I would ensure that I look at the processes of my fellow service/process owners, and when I find a process that will work for my situation, I would simply declare “I follow team x process”. Doing this would alleviate me from the ownership and management of the process and documentation, but would also mean that I must work to build/maintain a partnership with the other service/process owners.
Test – verify what you think will actually work. Get feedback from the folks who will execute the process (in fact, do this all the way through your design). Ensure the process will meet the expected business outcomes. Do not launch a process that will not meet needs or is not ready. At the same time, do not try to make the process perfect. Doing so means you will never launch simply because “it just needs a little more tweaking.”
Spend time in the design phase determine what constitutes “success” for the process and make sure you measure as you test.
Then, with all of the steps above: Plan, Build, Test. Lather, Rinse, Repeat.
It really is that simple. And yes, the idea for this article came to me in the shower.
We had spent a lot of time designing and tweaking.
And so I went into my meeting excited to explain the new process. Alas, I was not ready for what was about to happen. Barely ten minutes into the explanation of the process, the first salvo was fired:
“This is not what we do. That will not work.”
The exchange over the process escalated from kind explanation, to defending work steps, to questioning professional ability, to name-calling, and it didn’t end there. Trust eroded and partnerships dissolved. After the meeting (and several antacids), I tried to regroup and figure out what went wrong.
I didn’t realise that I just had the opportunity for a “crucial conversation”.
What is a “crucial conversation”?
The entire meeting interaction bothered me so I did a little soul searching to determine why I felt so bad. In my search for answers, I came across the book “Crucial Conversations”. The liner notes quickly described my meeting. Intrigued, and somewhat skeptical, I bought a copy and started reading.
A crucial conversation (as defined by the book) is “a discussion between two or more people where (1) stakes are high, (2) opinions vary, and (3) emotions run strong.
Any journey undertaken to adopt ITSM has many perils. One of the toughest perils is communication. No matter how well you communicate, there always remains an opportunity for somebody to misinterpret, misunderstand, or change the information provided. When I discuss tough challenges of ITSM adoption with other practitioners, communication issues always rank in the top three. The truly toughest conversations not only exist when talking with the C-level, but in the day-to-day conversations with the teams who convert the vision to reality.
Why are they crucial? Simple, they are the day-to-day conversations that affect your life. Crucial conversations are crucial because a) opinions vary; b) stakes are high; and c) emotions run strong. Crucial conversations can be a service desk agent assisting a customer, a CAB discussing a change request, a service owner discussing a process with operation teams, or DevOps teams planning a release.
The Power of Dialogue
Di•a•logue (dìʹ ð-lôǵʹ)n – the free flow of meaning between two or more people.
We each have opinions, feelings, theories and experiences that shape how we view a topic. As we discuss a given topic, we do not necessarily share the same views as others. We do not have a “shared pool of meaning”. People who have mastered the skill of dialogue make it safe for others to add their meaning to the shared pool and having a shared pool of meaning is a key deliverable for any ITSM project. A shared pool of meeting leads to better discussions, better debate, and better decisions. If we position people to purposefully withhold meaning from the shared pool, individually smart people can do very stupid things. Shared meaning helps teams build synergy.
Time to look in the mirror
The key to good dialogue is heart, specifically your heart. We’ve all grown up with various forms of poor communication during crucial moments in life and/or work – debate, silent treatment, manipulation. Not the best role models or behaviors for important conversations, which is why you must work on your changing your own communication first. While we may want, wish, and desire others to change, the only person you can consistently inspire, prod, and shape is the person looking back at you in the mirror.
What do you want?
When I ask other practitioners what they most want in an ITSM relationship with a teammate, the answer is usually “good partnerships”. Successful ITSM adoption only occurs when everyone believes others are working to help improve the state of their situation (a shared pool of meaning).
In all likelihood, you are going to have moments (both in life and in ITSM) where someone completely disagrees with you. You present a change, like a new process for example, and the person counters with:
“We’ve been doing well for the past x years…this change will just confuse things and make it more difficult to do our jobs.”
You know the change is the right thing for the organization, but how do you make those reluctant to change understand this? In the past, when confronted with this type of situation, I have been defensive, offended, and even arrogant. Of course, those qualities led to failure in getting the change adopted and damaged any future efforts for collaborations with the person.
After reading the book “Crucial Conversations”, I changed how I approach these situations. I now take a step back and ask myself the following questions:
What do I really want?
What are my motives and are my motives changing as the conversation moves forward?
What do I really want for others?
What do I really want for the relationship?
How do I behave if I really want my desired results?
By asking these questions, we affect our psychology and physiology. We can think differently, look teammates in the eyes, and become genuinely interested in what others have to say. We get away from the old (bad?) habits, which we have been exposed to over the years and instead ask ourselves questions that remind us of our goal(s). This helps our brains stay on a path to focus on achieving said goal(s).
Winning and Losing
We often talk ourselves into the idea that we must win or lose, choose between peace and honesty, or try to find a way to make “everyone happy.” The idea behind Crucial Conversations is that we all need to win. We need to help everyone on our team, in our company, in our family, and in our circle of influence reach the results that make us successful. Crucial conversations are necessary to help people find ways to hold emotional and risky conversations safely and with purpose.
Don’t expect to read the book and then be beautifully successful in all your conversations moving forward. You won’t be perfect on your first attempt, but don’t worry about it. Just like ITSM, your ability to hold crucial conversation is a continuous improvement process. Just be persistent. Doing so should help lead you to better relationships and collaborations.
During my time in IT Service Management I’ve read my fair share of process and policy documentation. In fact, I think I’ve had the misfortune to read more than my fair share.
Process documentation is important, don’t get me wrong. Without someone taking the time to write down the intention, expected steps, outcome and quality checks within a module of work you don’t really have a process at all.
I was having a conversation this week with someone that was sure they had a process for something. It transpired that what they had was an unwritten set of best practices that everyone understood and followed. The outcome was actually fairly good and repeatable but by no sensible definition was this a process.
In fact the moment of realisation came when I asked if the best practices had changed over time. Of course they had as the team had learned and improved itself. But without proper documentation outlining the new steps to take nothing was truly repeatable. There was no real process.
Lean Process Documentation?
So, I am an advocate of writing documentation to support a process. But does it have to be so verbose, heavy in language, formal… and lets be honest. Boring?
Lean principles teach us how to identify “waste”. Any more than the responsible minimum is waste. Do we actually need to include difficult to read text in our process documentation? If they don’t add value to the reader surely they are wasteful and can be removed?
There are some practices that I use in my role in product development that I think would be really useful to IT Service Management professionals that are willing to take a fresh look at their process documentation.
User Personas in Action
A user persona is a method of representing an individual that is involved in a process. For example in your Change Management process you will have a number of different people to think about:
The person requesting the change
The person that peer reviews
The person implementing the change
The person who does a post implementation review
Each of these people have different requirements, concerns and objectives when working within the Change Management process. Does your process documentation accurately represent these people?
Each user persona should fit on a single side of A4 – An example, ‘Angie – Change Manager’ is below.
User personas represent real people within the process and I’d recommend using photos of your actual users. It’s a powerful thing in design meetings to have a set of personas pinned up on the wall and to actually see the faces of the people you are making decisions on behalf of.
Each persona has a short summary and then four sections.
What she’s thinking
What she’s hearing
What she’s saying
What she’s doing
The sections show the users concerns (“thinking”), the conversations that other people would start with her (“hearing”), the conversations she would start with others (“saying”) and her day-to- day actions within the process.
A persona should be a “caricature” of the different people that act the part within your process. You might seek out these people and interview them to discover what they are thinking, saying, hearing and doing. If you interview 4 different Change Managers and discover that they all have different concerns your “Angie the Change Persona” would be a representation of a person that has ALL of the concerns. You are aiming to discover the extreme points of view that these people exhibit and document them.
We try and use personas throughout our product development process – when we design a process defining these is a critical early step and we rely on them during Acceptance Testing to ensure we are getting feedback from all people.
A few months ago I mentioned personas in the Back2ITSM Facebook group and got a good response. As a community resource I’d love to see a set of User Personas that cover all the roles in common ITSM processes. Imagine knowing that you need to write a new process for Configuration Management. Heading over to Back2ITSM to download a set of user personas for each role in the process would be a huge head start.
I’d love to see process documentation move away from mimicking legal documents with reams of dense text and move towards a more user centric representation of users requirements and concerns.
After all – your process affects real people. Lets find out who they are at the design stage and make the process more suitable for their needs.
After years of experience deploying ITSM solutions in a variety of customers, and in the midst of a major soccer tournament here in Europe which brings out the managerial expert in football-watching folk, I found myself musing on what would be my “Fantasy” ITSM team.
What is that seemingly mythical combination of team members that brings about either an aura of calm or a maelstrom of chaos.
The ITSM Solution Architect
Quite often with fingers in various pies – a little project management here, a touch of subject-matter-expert (SME) there and a healthy dose of OCD in terms of getting Visio lines to snap to geometry.
You will typically work directly with customers, to understand what magic is required to get this Service Management tool malarkey to work.
And then – you find yourself stuck in the middle of a team trying to get processes and tools to live in harmony, so maybe add the role “politican” to your skill-set.
Size does NOT matter
No really – believe me, it does not where ITSM projects are concerned.
My most recent deployments have been as part of outsourcing projects – and even within those beasts of burden, the projects have ranged from the Service Management work-stream being a small part of a large outsourcing project, or a small group running as jacks-of-all-trades.
But there is one common denominator in all this – the need to dovetail the team’s efforts into reworking of the process with the development/customisation of the tool.
1) Don’t Make Me a Liar…
Process Implementation and Solution rests in two camps. If you are lucky, the project will have a work-stream specifically for Service Management and the two areas can advance in lock step with each other.
And they NEED to.
The Process team has to know what the capabilities, and at times limitations, of the tool as they are redefining processes.
The worst case scenario here is that the earth is promised, yet for whatever reason the tool simply cannot deliver, leaving everyone looking a little foolish.
2) You can Have it all…
Of course the flip side of the coin is that you twist the tool to do anything you want, and add anything to the process.
That tends not to help much either, (see above re: foolish)
3) So Happy Together…
There are several ways, in my opinion, to bring the Process and Tool together, without uber-educating one individual to be a complete Service Manager, Process Implementation Manager, and Tool Subject Matter Expert!
(Mind you, just think what you could ask as a daily rate!)
A single work-stream which brings together the Service Management Processes and the tool implementation team together.
It requires a strong, knowledgeable Project Manager who can understand the technical, and process elements, but steps back and manages the project using those resources.
Collaboration between the members of the team – there is absolutely nothing wrong with a little skills cross-pollination.
It doesn’t hurt to herd Process folk towards the tool – yes I know, it’s horrible and it involves clicking and things, but it does bring to life those lovely diagrams you make!
Actually – it also doesn’t hurt for Solution Architects to perhaps get up closer and personal with some of the administration of a system so that they can combine brain-power with the Subject Matter Experts/developers from time to time
Is it ever possible to do things “turnkey”?
Now that IS a good question.
“Turnkey” is a phrase I heard all the live-long day on one project, where it was assumed that customers would just sign on the dotted line, leaving us to go and pretty much do what we wanted.
Once upon a time, maybe that could have been true, but not in the 20 odd years I have worked in the industry!
1) Requirements Gathering
No two customers ever have exactly the same business requirements. But most companies will have developed decent sets of templates to drive out specific requirements – standardised questions and a repeatable approach helps here.
2) ITSM Solution
Ah, we architects LOVE our solution templates – plug in requirements and it might be useful to work out what belongs to Process, what are Organisational and whatever left is Tool.
THEN figure out what the tool does easily, what the contract says, and work out where your implementation headaches will b
Here’s where we start to overlap. Whether your tool solutions are high or detailed level, it is likely to start to cross some boundaries especially if the definitions for elements like Impact and Urgency need to be configured in the tool.
The solution needs to reflect the way the process has been written and the process needs to be implementable.
This cannot be done in isolation and also is likely to involve SMEs or developers for more fine tuning of the tool – do not leave them out of the equation.
4) Tool Implementation
The magic area where it all miraculously comes together!
Priorities, urgency, impact, fields, workflows, data loading… need I go on?
People wonder why Service Management deployments take a while!
Some things, of course, can be standardised, for example supplying standard data loading templates, but sources of information will differ, and it is worth remembering that often the project will have to interact with groups who are maybe not directly involved with the ITSM project.
A fool with a tool… how to avoid that scenario!
There can never be a single person who possesses all the tools to make a Service Management Deployment a success – it has to be a team effort.
The best project managers have a degree of technical skill in Service Management, but can remove themselves from interfering in the technical detail.
The best process managers are actively involved with working alongside the implementation team and perhaps involved in developing testing material to aid that familiarisation.
The best teams have engaged service managers who have a vested interest in what is coming their way – all too often they are either the last people to be informed, or worse they feel they are too busy to give it the time – a recipe for disaster, every time.
The best architects understand at the very least the ITIL basics to hold their own in process/solution design discussions, and it is better still if they can hold their own in the more heated debates of “the book says” vs. “the tool does, in alignment with ITIL Best Practice”
The best implementation teams have a good bond between architect and SME; often two heads can be better than one in getting darned pesky tickets to go where you want them to.
The nature of the deployment beast is that you may have some, but probably not all of your perfect team attributes but if enough of balance can be struck between the vital roles Process Implementation and Tool Implementation play during a deployment – then I think you are half way there.
The ITIL® Request Fulfilment process exists to fulfil Service Requests – for the most part minor changes or requests for information.
Request Fulfilment landed on us in ITIL v3 when there was now a clear distinction between service interruptions (Incidents) and requests from users (Service Requests for example password resets)
And what does ITIL 2011 give us?
ITIL 2011 sees a hefty revision for the Request Fulfilment process. There are more detailed sub-processes involved with steps broken down logically.
Now, I like me a good diagram and finally Request Fulfilment gets a decent flow and most importantly the linkages to other interfaces to the other lifecycle stages are included in a lot more detail.
Perhaps the most impressive thing is far more detail in the section about the Critical Success Factors (CSFs) and Key Performance Indicators (KPIs) that have been included. Having experienced the hilarity of definitions of over-complex metrics – this is a good starter for 10, straight off the bat and of course can be added to suit an organisation’s needs.
But what does all this REALLY mean?
It means nothing if the best practices cannot be applied and adapted into real life.
Now we all know that at the back of a Service Request is a process that will step through authorisation, any interfaces to other processes etc., but the business value is to provide a quick and easy way for end users to get new services.
A mechanism to reduce costs through centralising functions.
Understand what other stages of the lifecycles are needed alongside Request Fulfilment – this does not happen in glorious isolation.
Is there such a magic bullet?
The simple answer? NO!
But there are a few things that should be taken into consideration when looking at implementing Request Fulfilment (often as part of an integrated solution).
Let’s look at the easy stuff first:
Look at starting nice and easily with simple Request Models that will happen often, and can be met with a consistently repeatable solution.
Look at what kind of options you are going to put in front of the user. Most people are now familiar with the type of shopping basket type approach through the internet so offer them a familiar interface, with as many options that can be pre-defined
Make sure that the different stages of the request can be tracked – the purpose is two-fold:
End users don’t get (as) ratty
Reporting and routing can be made simpler and more accurate with meaningful status definitions
Getting the hang of this…
Give some thought to how you want to prioritise and escalate requests depending on their complexity to fulfil, and again pre-define where possible.
Let’s do the whole shebang…
Eventually there will be a need to include financial approval(s) which in turn means sticky things like deputies and budget limits
There may also be external interactions with fulfilment groups dealing with procurement
Back up a second – who now?
Give some thought to which groups are going to be involved. In my experience it is sometimes easier to work backwards, from the outcome to the selection and fill out all the bits you need in between.
Easy stuff is most likely taken care of by a single, often centralised group – typically the Service Desk, or in some cases specific co-ordinators who work at that Level One tier.
Decide if your existing resolver groups are appropriate for some fulfilment tasks or where you need specialised groups and build your workflows to suit. Typically the first-line support group handling the request always has the ability to track the progress of the request, and is the point of contact for the end users.
Is that it?
Whether your request is a simple How Do I to a Hand craft me a personally engraved and gift wrapped iPad the request needs a defined closure procedure. There has to be a mechanism to validate that the request has been fulfilled satisfactorily before it is closed.
How do we go about deciding what works and what doesn’t?
There is something I will state, use and promote constantly, and that is the use of scenarios. These are invaluable whether you are testing a deployment, performing user-acceptance testing with a client, or whether you are just evaluating products.
Decide on what criteria you need to establish your end goal
Break them down to manageable steps, and here the ITIL 2011 activities and points are very nicely presented to give a starter for ten
For a product review, for example, look at how easy it is to configure – can I do this myself using demos on the web, or do I need a proper demo on site/webinar with a tool administrator
As an aside, what kind of administrative skill is required for your tool of choice?
This is a doddle, no?
A number of things can kill an otherwise promising and/or straightforward deployment:
Poorly defined scope – People wanting the process to do too much or not really grasping the idea that Service Request models should be pre-definable, and consistently repeatable.
Poorly Designed User Interfaces – The best back end workflows in the world will not help you if the user interface makes no sense to an end user. Too often I have banged my head against a desk with developers who love how THEY understand what is being asked, so who cares if some desk jockey can’t – they can ring the help desk, right? WRONG! Missing the entire point of the business benefits for removing the need to drive everything through 1-2-1 service desk interaction.
What is worse than a front end you need a degree in programming to work through? Haphazard back end workflow that twists and turns like a snake with a stomach upset. Just keep it simple. Once it starts to get super-complex, then really ask yourself is this a minor request or something that requires specific change planning.
Make sure your tool of choice is capable of measuring meaningful metrics. Remember, there are lies, damned lies and statistics. What are you looking to improve, why, what is the benefit, and what can it lead to in terms of Continual Service Improvement