Tag Archives: Change Management

Flipping the ESM Switch: Pressure Off, Ease On

Share twitterlinkedinmail

There’s a buzz around Enterprise Service Management (ESM) these days and with good reason! I see Enterprise Service Management as the future of Service Management. With the ever-increasing business reliance on the use of technology, more organizations will need to adopt Enterprise Service Management.

But what exactly does ESM do for your business and, more importantly, how can you start to implement it without complicating it?

At its core, ESM is applying IT Service Management concepts to the entire enterprise. It makes it easier to provide solutions to colleagues within your organization and to deliver value to customers outside of your organization.

While ESM is not about reinventing the wheel, it’s certainly not about force-fitting every department into established ITSM processes and workflows.

Implementing ESM is about leveraging what you have to make your tools, processes, and teams work better so that you can drive the same business value across the organization. It should flip the switch from pressure to ease.

Let’s look at some areas where ESM will ease the pressure within your organization.

Pressure:
“Other teams will insist on having it their way and using their tools and processes.”

Every department has its own defined set of processes, tools, and workflows. This can create a power struggle where each department is certain that their way is the best option. This can create difficulties during ESM implementation as each department could try to force others into adopting their processes or tools.

Ease:
“We are all working toward a common goal so there is no longer ‘my way’ and ‘your way’ – it’s now ‘our way’. “

The fundamental shift that must occur for ESM to be successful is to let go of the notion of independent goals and objectives. Every department, every team, every individual must be aligned with the overall goals of the organization. No matter your role in the organization: HR, accounting, marketing or IT, everyone is working to serve the customer. Department leaders and the C-suite must coach their teams to stay focused on these goals. If the organization is aligned on shared, common goals, it will be easier to adjust processes and workflows that work best to meet customer demands.

Pressure:
“My department is unappreciated and burnt out.”

Contrary to popular belief, it is not only members of the IT organization who often feel burnt out and unappreciated. In many organizations, every team member can feel as if their work goes unnoticed and unappreciated. When teams are focused on internal goals and not on organizational goals, teams fall into working in their own silo. One of the results of this silo mentality is that no one is clear on who is accomplishing what within the organization, which makes it difficult to understand how everyone contributes to organizational goals.

Ease:
“ESM results in clearly defined end-to-end processes, which means every part of the team will understand who contributes and how.”

Good ESM makes it easier to assign and see responsibility and accountability across each service or product. Not only does this hold everyone accountable for completing their piece of the process, but every team will be able to clearly be recognized for how they contribute. This can be the motivation that many team members need to keep contributing and to respect the other departments also involved in the delivery of services and products.

Pressure:
“Our department does its job and meets our part of the process – it’s other departments that drop the ball.”

Ease:
“Enterprise Service Management provides increased visibility and performance and helps management understand what has been achieved.”

Good ESM processes help provide insight into the value that each business function provides and communicates that value to customers and other business stakeholders. With Enterprise Service Management, no one can drop the ball because everyone knows who is in charge of what aspect of the process. There are clear communication channels and a high degree of visibility and transparency. Leaders must encourage their teams to embrace this as it will identify gaps, provide clear insight into contributions, and eliminates “blame” culture.

If you feel any of these pressures, then it may be time to introduce the ease of Enterprise Service Management. How can you start implementing it in your organization with ease instead of friction?

1. Justify Enterprise Service Management in business terms

ESM doesn’t always sell itself. Just like any change in an organization, the benefits need to be articulated in business terms. Explain the actual business benefits including revenue, competitive advantage or enhanced customer experience. Look at how many hours ESM can save from eliminating inefficiencies and miscommunications and how it can bring even more value to the organization.

2. Don’t treat ESM as ITSM

ESM cannot be an IT project. ESM is not about simply extending ITSM into the enterprise. It’s an organizational change that impacts every member of the team. Remember, ESM is about leveraging what you already have in place — and that includes every process and perhaps tools other departments use, as well. It must feel collaborative and inclusive to everyone in the organization

3. Respect the holdouts

It’s natural for some departments in your organization to fully embrace ESM and for others to be more resistant to this change. Instead of marginalizing the departments who are holding out on ESM, work with them to show how ESM can benefit their team. If ESM is going to be successful, every team needs to be willing to accept and try it. Forcing Enterprise Service Management on a department will only cause problems down the road. By continuing to emphasize the collaborative nature of ESM and the ability for every team member to be heard, you will be able to win over those holdouts.

4. IT- Focus on yourself first

IT can drive ESM, but there is no point extending sub-optimal service management practices outside of IT. If your ITSM processes are not meeting your needs, or if your own team is struggling with certain aspects of ITSM, focus on cleaning up in-house before trying to extend service management into the enterprise. If you are having successes from ITSM efforts, then your argument for ESM will be more impactful and you’ll have an easier time extending it throughout the enterprise.

ESM is not a passing fad. As more customers expect more personalization and self-service, the need for ESM is only going to increase. The best way to maintain a competitive advantage and keep your customers happy is to start implementing ESM in your organization today.

Share twitterlinkedinmail

The CAB is Dead. Long Live the CAB.

Share twitterlinkedinmail

Can today’s IT organizations balance agility with stability?  Is IT capable of responding to ever-changing business needs in a timely, dependable, and appropriate manner?  Can IT have an intelligent discussion with its business colleagues about developing and delivering solutions, with appropriate management of risk? Can IT provide demonstrable business value at the right cost?

These are the big questions for many IT organizations.

Can business rely on IT? Is IT even relevant?

These are the bigger questions that the business is asking.

Much of the answers to these questions depend upon IT’s ability to effectively manage changes. To remain relevant, the ability for IT to manage change is critical.   Why then are so many IT organizations so resistant to change management?

When IT people hear “Change Management”, many think “CAB”

One of the core constructs of most ITSM change management implementations based on ITIL®[1] is the Change Advisory Board, or CAB.  In many organizations, the CAB has historically been a source of frustration, not only for the people directly involved with the CAB, but also for the business.

A CAB is just a group of qualified people who are to provide advice regarding a proposed change.  The idea is to have the appropriate people review the appropriate requests for change and make recommendations.

Honestly, I think the intention of a CAB is a good idea.  The primary intention is to prevent the organization from shooting itself in its metaphorical foot – and provide an objective evaluation of a request for change.

But in many change management implementations, the CAB is being used, abused, and otherwise mistreated.

The reason why most CABs are in such bad shape is that the change management process design and implementation is incomplete.   What I frequently find with underperforming CABs are the following issues:

  • There is no transparency – requests for change go into the “black box”, and (maybe) reappear sometime later.  Change Schedules are not published outside of the CAB.
  • Every request for change – large, small, trivial, ginormous – is dumped onto the CAB. Or worse, the CAB gets ignored.
  • Roles are not clearly defined, and as a result, no one really understands what they should be doing.
  • CAB meetings are conducted with few, if any, prepared to have a productive meeting.
  • Requests for change are haphazardly prepared, omitting critical information that would be helpful in the evaluation of the request.

Many CAB meetings have turned into exercises in bureaucracy, frustration, and ineffectiveness.  As a result, some within IT organizations have looked to other approaches for managing changes.

The CAB is Dead – Or is it?

First, the CAB is not the end-all, be-all for managing changes.  The CAB is just one type of change authority that ITIL discusses.  Furthermore, ITIL isn’t the only methodology that utilizes a change authority to manage work.   Other methodologies also employ similar constructs to control, authorize, and publicize changes.

Scrum

Scrum uses a “task board” or “day board” to depict the “backlog”, or work needing to be done but not yet assigned.  A Scrum Team conducts a daily stand-up meeting to review the day board.  The function of the day board is to facilitate the identification of and agreement on what work (changes) is going to be done, who is going to do that work, and ensure that all stakeholders are aware of the work that is being done by whom.

In an effort to scale, many organizations that leverage scrum have implemented a ”Scrum of Scrums” or a meta Scrum[2] , but the basic concept is still the same. The meta Scrum consists of representatives from each scrum team.  Like the Scrum Team, the meta Scrum uses a day board to depict a backlog and gain commitment of what work is being done that day and by which scrum team.

Lean

A core Lean concept is visualization of work.  To ensure the visualization of work, Lean uses a Kanban – similar to a scrum “day board”, but with an emphasis on limiting work-in-process by pulling (not pushing) work through a process.  Like Scrum, many teams using a Kanban conduct daily stand up meetings to discuss work and any blockers that the team may be encountering.

As such, Lean may view a weekly CAB meeting as “waste”, in the form of non-value-added wait time.   Having said that, many factors would have to be considered before coming to that conclusion.

Think about it

I’m not here to defend ITIL – just like with any methodology, ITIL has its faults.  But it’s not ITIL’s fault that a CAB isn’t as efficient and as effective as it could be.

There is nothing from ITIL that says that CAB meetings are only to be conducted once a week (If you find that somewhere, please let me know in the comments below).

Isn’t a daily stand up meeting functionally similar to a CAB meeting?

Doesn’t a task board or Kanban function like what ITIL would call a “change schedule”?

Good Change Management starts at the top

Change management is not just an “IT issue”.

Regardless of the methodology, no amount of velocity, flow, visualization, agility, or efficiency improvements can help without having strong leadership from senior managers.  Senior managers must develop and communicate the vision for the organization.  Goals and objectives must be clearly defined to provide the broad, overarching guidance for the company. For change management to be effective, everyone must know what is important to the business.

Senior management must seek out and break down organizational siloes. So many change management issues are cause by people refusing to collaborate.  For change management to be effective, everyone must be involved and collaborate.

IT must be part of, not separate from, corporate governance.  No differently than any other part of an organization, there must be a plan for managing the demand on IT that will result from business goals and objectives, as IT is neither an infinite or an inexpensive resource.  There must be an objective evaluation of organizational capacity – how much can be done given the resources within an organization.  Just trying to drive “more work, but faster” through an organization with insufficient capacity to meet demand is futile.

Having the above three things in place will enable change management.  But IT then must execute. Having a modern CAB is critical for that execution.

The Modern CAB

Regardless of framework or methodology, the modern CAB must have the following attributes:

  • All work must be visible – everyone must be able to view what work is being done and the demand being placed on the IT organization
  • Team members must be empowered and self-governing – this is one area where strong management support is critical.  But then those doing the work must take personal accountability for changes being done right the first time.
  • The authority for implementing a change must be delegated as close as possible to those making the change.  This means having clearly defined evaluation criteria, and identifying who approves what kinds of changes.
  • The CAB must be inclusive, with appropriate representation from all involved – not just developers or IT operations, but also colleagues outside of IT.  In some cases, this means getting suppliers involved too.   But most of all, the right people are involved at the right time.
  • Trust – When people who work together trust one another, it enables an atmosphere of collaboration instead of blame.

The relevance of IT is at stake.  IT must work as a single team.   It’s time for the modern CAB.

For more pragmatic advice and service management insight, click here to subscribe to my newsletter!

Photo credit:  www.pexels.com

[1] ITIL® is a registered trademark of AXELOS Limited.

[2] From www.agilealliancce.org , retrieved 6/3/2017.

Share twitterlinkedinmail

5 Ways to introduce DevOps to your ITSM World

Share twitterlinkedinmail

Is your IT organization feeling some “heat” from your business partners? Is your IT organization keeping up with business demand? Are you able to respond to business changes in a timely fashion? Do you spend more time “fixing” and less time “innovating”?

Is your management asking you to look at DevOps?

The days of monolithic IT processes are numbered. The message is clear – businesses are demanding faster results and better quality from IT.

Modern businesses are often multi-faceted, with variations in regulations and geographies. The interactions between businesses and customers are rapidly moving away from ‘pipelines’ to ecosystems.   As a result, the interactions between IT and its business partners must change. Businesses are demanding that IT become more agile and quicker to bring solutions and services to market, but at the same time, remain reliable and consistent. And – do not let the business become the next “data breach” headline in the news.

Monolithic processes are not the answer for agility and speed to market. But that may be how your ITSM processes are being viewed.

But you’ve done some great ITSM work

You’ve done some great work implementing ITSM processes – and frankly – they do work! What does DevOps mean for your ITSM investment? Do you just scrap what you have?

Well, no – don’t throw away your investment in ITSM processes. The fact is that as you introduce DevOps into your organization, you’re going to need and use principles and processes from your ITSM implementation.

Rather, consider DevOps as another tool in your ITSM toolbox, because much of what DevOps is about requires defined processes.

The bottom line is that you can’t ignore the ever-increasing business demand for agility and responsiveness. Perhaps the mismatch is that your current ITSM processes do not adequately cover the complete business value stream. Or perhaps, unintentionally, your current ITSM processes have become stale as business demands on IT have changed.

What is “DevOps”?

According to The DevOps Handbook[1], DevOps is “…the outcome of applying…principles from…manufacturing and leadership to the IT value stream. DevOps relies on bodies of knowledge from Lean, Theory of Constraints, the Toyota Production System, resilience engineering, learning organization, safety culture, human factors, and many others”.

DevOps builds on Agile, Lean, and (yes) ITIL®[2], but it’s more than just IT methodologies. DevOps is really an approach that features smaller units of work, automation of tasks, and pushing the authorization for changes closer to those who are actually making the change. DevOps is about having Developers, Operations, Quality Assurance, and Info Security together from the start. The overarching goal of DevOps is to create and sustain a culture of trust, teamwork, continual learning, and continual improvement.

DevOps is not a “Silver Bullet”

There are some fantastic DevOps success stories from which we can learn. The DevOps Handbook highlights companies that are executing from hundreds to thousands of tests, integrations, and deployments per day. But it took most of these companies several years of trial, error, learning, and improving to get to this level of success.

DevOps also means having sufficient resources for testing and experimentation – making sure that there is a “safe place” or way to learn and experiment. This may mean significant investments in non-production computing environments, or in transforming existing solutions to a loosely-coupled architecture.

Having the ability to measure everything – a key DevOps principle – may require investments in tools. Further investments may be required for shared version control repositories that not only manage application code, but database schemas, project artifacts, configuration information, scripts, environment creation tools and artifacts, containers, and other assets.

Many IT organizations talk about themselves in terms of activities, products, and tools instead of services. IT must define, enable and deliver value and outcomes based on services…it isn’t just about “doing things”. DevOps doesn’t change that.

Finally, as with any transformation, changing the culture of an organization is easier said than done. Changing culture takes leadership, reinforcement of desired behavior, dealing with undesired behavior, consistency in actions, and vigilantly communicating.

Five Ways to introduce DevOps to your ITSM world

How can you start to bring in some DevOps thinking into your ITSM world?

  1. Define Change Models – Really. As models relate to changes, the more that is predefined and (pre) approved, the more changes can (and should be) automated. As you design change models in anticipation of DevOps, those designs must also include automated testing and automated remediation of failed changes.
  2. Use a Kanban as your change schedule. By using a Kanban as the change schedule, all of the work involved with changes becomes visualized. Everyone can see work in progress as well as the demand on the IT organization. It also highlights capacity constraints within IT. Also, using a Kanban as a change schedule encourages compliance with the change process. If someone isn’t following the process, their actions or non-compliance becomes visible – quickly.
  3. Formalize (design?) Release and Deployment management. Too many change management implementations have been over-burdened with aspects of what should be part of a Release and Deployment (RDM) process. By pulling those aspects (design, testing, deployment) out of change management and into a formal RDM process, change management becomes a facilitator and orchestrator of changes – not a barrier. Secondly, release packages should be analogous with “sprints”, characterized as small units of work, developed and delivered more frequently – just what a DevOps approach wants to do.
  4. Go the Gemba and ask these two questions. One of the most powerful Lean concepts is that of “the Gemba” – the place where work is being done. To become more agile and faster to market, processes must minimize waste – and this is where Lean can help. Ask these two questions:  “Why are you waiting?” and “Does each process step add value?”   Waiting and non-value added work is waste; eliminating waste helps IT become m ore responsive to business demand.
  5. Get serious about Continual Improvement.  Good practices as illustrated in The DevOps Handbook indicate that 20% of an IT organization’s time is devoted to what is described as eliminating “technical debt”. Another way to view this is continual improvement. The point is that continual improvement must become ingrained into the thinking of an IT organization, and time and effort must be regularly invested to identify and implement improvements.

What do you think?  Do you have other ideas for introducing DevOps?  I’d enjoy getting your feedback – so post a comment below!  Or you can subscribe to my monthly newsletter by clicking here .

Need  a Kanban template to use as a Change Schedule?  Download one by filling out the form below!

[lab_subscriber_download_form download_id=2]

[1] Kim, Gene et al.   “The DevOps Handbook”, IT Revolution Press, Portland, OR 2016.

[2] ITIL® is a registered trademark of AXELOS Limited.

Photo credit:  Shutterstock

 

Share twitterlinkedinmail

Doug Tedder earns Change Management Foundation certification

January 18, 2016:  Doug Tedder, principal of Tedder Consulting LLC,   has earned the Change Management Foundation certificate from APMG-International.

Dealing with change, and the impact of change, is a topic all organizations are facing. The Foundation certification is based on the professional body of knowledge for the discipline of Change Management developed by APMG and the Change Management Institute (CMI).   The Foundation course covers fundamental aspects of a organizational change management  initiative, such as stakeholder identification, tools and techniques for communicating change, and approaches for embedding a change initiative as the new ‘business as usual’.

Tedder Consulting is incorporating OCM principles and constructs into its ITSM process design workshops.