Deep Creek Center home.

Category: Featured

Post to be featured in the third row of home page where there are three “featured” posts.

The Great Convergence

One of the spectacles of the past 20 or so years has been the competing approaches and frameworks for improving governance, streamlining workflows, and delivering services. Practices like LEAN, Agile, ITIL, DevOps, and even governance frameworks like CObIT all competed for attention in promising adopting organizations more efficient and more effective teams, better results, and improved quality and consistency.

Well, the winner is in…it is…drumroll…all of the above!

Each of these approaches brings with it native practices and capabilities, yet most organizations are by now seeing that the most appropriate approach was never an “either-or”, but of course a “both-and.” LEAN brought us a focus on value streams, waste identification, and creating continual improvement cultures. Agile practice like Scrum introduced lightweight approaches to requirements (focused on user experience through user stories, a core idea in design thinking), prioritization through the use of backlogs, and acknowledging the reality that we just don’t know what we don’t know, and that being adaptive as learning occurs creates better solutions and higher customer delight. ITIL established the focus on service delivery and value creation, over mere execution of processes, and encompasses how cross-functional we must act to support the collaboration models we need to operate as end-to-end service teams. DevOps leveraged many of the above practices to drive a focus on the value stream of delivery and deployment of IT applications, and improves the velocity of solutions while improving the overall risk management of IT through rigorous testing and validation, environment controls through infrastructure as code, and improving flow with feedback. Even in the updated version of CObIT, the focus is on integrating new sets of best practices into an overall IT governance and management framework that acknowledges the profound changes in how IT operates.

Implications: There’s a lot to learn…and real upside for organizations that make the effort.

Most IT organizations are trying to adopt some number of these core practices, but often without an integrated vision of how they will work together to gain efficiencies and improve overall quality of service. In our consulting practices, we often see siloed thinking from development or operations organizations, with concomitant inefficiencies and poor results. Rationalizing these practices together is critical to get the value you seek from any of them.

The good news: there are many successful approaches to making this work. Over the next few weeks we will be sharing a number of success stories from organizations that have successfully adopted and adapted these practices to improve their organizations. 

ITIL® Capacity Management – As Easy as 1-2-3

In the ITIL guidance, Capacity Management is broken down into three related sub-processes. In this blog we will look at the three subprocesses and how they help us have better visibility into customer needs.
The first of the subprocesses is Component Capacity Management. For this subprocess we could easily substitute the word Utilization, for the purpose of this subprocess is to maximize the effective utilization of the components we have. Whether we’re discussing disk space, bandwidth, processors, memory allocations, or any other use of our physical and virtual components, the goal is to extract the most value we can from the components that we have. All of the capacity management processes have a financial management link, so here clearly the goal is to be able to defer expenditures until needed, and to balance the cost of provisioning to the resource requirements.
The second of the subprocesses is Service Capacity Management. For this subprocess we could substitute the phrase “End-to-end Performance.” The purpose here is to ensure that services have the right level of end-to end throughput and response time to meet customer requirements. Again, the goal is “enough,” enough performance to meet the need without gold-plating or what in the Lean world we would call “overprocessing,” or over-delivery (and overspending) relative to the business need.
The third subprocess is Business Capacity Management. Here would could substitute the phrase “future planning,” and there is a straight line between business capacity management and budget planning. Here we look at both the existing component and service capacity needs AND the future ones; next week, next month, next year, what is happening based on the business plan and what are the implications for the capacity plan. In short, everything in capacity management is demand-driven. Business Processes drive business activity drive consumption of service. As business use increases (demand), provisioning must scale to support it (supply). This of course has implications for budgeting and spending patterns, with the rule of thumb that we wish to plan for what is needed, and defer expenditures until the need is realized. These could be for new services, or changes in the use patterns of existing services.
Techniques used in Capacity Management include application sizing, simulation or analytical modeling, and the use of a tactical capacity plan to maintain visibility across your services. Half the point of having a process defined like this is to establish this as a focus area, where the Capacity Manager can look across technical/functional disciplines to ensure that capacity provisioning is optimized over time.
How well does your organization do capacity management? Is the focus too technical, looking at the component level in detail but perhaps missing the end-to-end? Do you have the right interactions with your business customers to get a decent forecast of future needs and patterns of use so that your planning and budgeting is properly aligned? Do you have alignment with the members of your team looking at new technologies and their implications for capacity and service improvement?

3 Critical Factors in Successful ITSM Adoption (and one to grow on)

Many organizations are working to adopt ITIL practices and improve the quality of services they provide to their customers. Yet many organization, especially larger ones with a broad array of potential areas of opportunity, struggle to identify the key critical success factors that make ITIL adoptions successful. We’ve had the privilege of working with hundreds of different companies to “get past talking” and begin to make meaningful adoptions that drive real results, both in improved efficiencies and effectiveness. In this white paper we will talk through three of the most critical we’ve see in our consulting and mentoring experiences.

CSF #1 – Management Commitment (and how would one measure that?)

Literally every publication that talks about successful ITSM adoption begins with the need for “Management Commitment.” Unfortunately, that’s often where it ends, too.  That begs some obvious questions. What is management commitment, and how would I know if I have it?

We have seen common traits in successful ITIL adoptions around demonstrable management commitment. Here are a few we see in the most successful ones.

Creation and Funding of a Formal ITSM Program – In most IT organizations, commitment is seen in investment and commitment of resources and time, and a willingness and commitment to effective measurement of the efficacy of the program.

Visible presence – Successful ITSM programs have highly visible executive Champions, who understand the value proposition and advocate for the program and for the achievement of the benefits. Unsuccessful programs often have executives with poor awareness of what ITIL is, but have a general “wish” to be perceived as using best practices. Phrases you might hear include things like “we want to be an ITIL organization.” These executives require substantial consulting and mentoring to understand and prioritize the benefits of an ITSM adoption, or they will go in circles.

Adoption of Owner roles –ITIL and other frameworks like COBIT emphasize the need for effective governance and management of processes, and clear alignment on services, service value, and service delivery. ITIL supports these through the establishment of Service and Process Owners, whose job is to work in cross-functional ways to support delivery of whole end-to-end services and ensure effective role alignment in coordinating process activities. An unambiguous sign of real progress in an ITSM Adoption is the definition of and assignment of these critical roles to appropriate (and often very senior) IT management.

Celebration of achievement milestones a.k.a. support for CSI  – Wise managers are well aware that ITSM adoption happens at different levels of maturity in different parts of the organization. Establishing good core practices and intensely focusing on continual improvement , what we often call the ‘Win a little to win a lot” attitude, is critical to keeping the team focused and engaged.

CSF #2 – Define Processes before Tooling

In many organizations that are challenged with their ITSM adoption, there wasn’t in fact much of a strategy, but there had been a substantial commitment: to purchasing one of the major integrated ITSM toolsets.

Our general commentary on tooling is pretty simple: virtually all of the major tool families do a good job with implementing supporting tooling for the core ITIL Service Operation and Transition processes. Unfortunately, even when organizations plan to adopt entire tooling families, individual module implementations tend to take a siloed approach, down to retrofitting poor customizations from previous tooling implementations that would be much better off discarded outright.

A better approach is to lead with the processes first. Establish your core processes (many templates are generally available that would get you 80-85% of the way to where you want to go), and then tailor these to fit your needs. A proper process document will establish your objectives, governance, activity workflow, metrics, roles and responsibilities, and a RACI matrix at a bare minimum. Once you’ve done your due diligence on the process, it becomes an easy activity to look at how to use the tooling to automate the process activities and to create reusable models. Remember that automation is neutral by design; it allows you to do things quickly and with fewer resources. If it’s automating the right activities, it will dramatically improve quality and productivity. Conversely, if we don’t have clarity on our processes and procedures first, it simply allows us to “do bad things fast.”

CSF #3 – High Quality Incident Management Information

Many organizations begin the ITIL journey unhappy with the state of their service desk and their incident management processes overall. In many cases, these issues begin with fundamental aspects of process immaturity: lack of clarity in role definitions, poor or no business awareness training, lack of proper process governance and oversight (or lack of a single process owner and/or process managers with responsibility across technical/functional silos), bad process compliance, and poor metrics definition. While virtually every organization has “incident management,” shockingly few really have a single enterprise process with meaningful end-to-end governance and management. This is especially troubling, because good quality incident data is fundamental to the success of many of our other core process areas: problem management, availability management, capacity management, SLM, change management, configuration management, and we could go on. So job one in any adoption is to ensure the quality of your incident data, and to do this, you must focus on establishing and stabilizing your incident management process. Do you

  • Have consistent and appropriate practice for when incidents are detected and logged so the “clock” starts
  • Have coherent categorization schema that produce effective assignment and searching as well as a rich source of effective and targeted reporting.
  • Have rigorous rules for priority based on business impact and urgency with highly consistent scoring based on established procedures and work instructions
  • Have defined incident models for the majority of “routine” incidents
  • Have a knowledge base that is usable and effective to support first-level incident resolution
  • Have clear rules for resolution of incidents and when the clock stops
  • Have clear rules for closure, final categorization, and enforcement of incident resolution documentation

And one to grow on…Service Level Management

Not every organization with successful ITIL adoption activities has formalized Service Level Management. It is entirely possible to establish and improve other process areas without it.

However, the organizations that really get the big wins always do.

Why? It’s really very simple…it’s possible to have processes without services, but it’s very hard to deliver better outcomes for customers without a meaningful process to ensure alignment between IT services and the business workflow and outcomes they support. SLM establishes IT’s “reason for being;” ensuring that what we do delivers the right benefits for the business, and that we have a dynamic way to maintain awareness of business need changes (internally or externally driven) so that we can appropriately evolve services to meet the changing landscape. It ensures that we emphasize end-to-end service metrics and their contribution to business metrics (like revenue, profit, and mission achievement) over technology and raw uptime. It also provides a regular communications vehicle to more proactively identify improvements and potential issues. If you have spent a lot of time (and money) on ITSM adoption with limited buy-in from your business partners, this is almost certainly the “missing link” that will help you get your activities back on track.

 

Patrick von Schlag is President and Chief ITSM Consultant for Deep Creek Center, a service management consultancy and accredited training organization based in Highland, MD.

 

 

Agile as a Business Transformation Practice

Agile as a Business Transformation Practice

One of the deeply fundamental problems with how people wrestle with the adoption of Agile practices is that the “point” of using Agile is often lost on most of the participants. They often hear Agile and think

  • New meetings
  • Continuous Deployment
  • No changes during sprints
  • Visual Task Boards

While some of these are true, they’re not “the point.” WHY does thinking and acting in an Agile way help us?

Agile helps us focus on business value

In any endeavor, the temptation is to focus on the “to-do list.” What do I have to build/buy? What do we have to operate? But the bigger question is always “so what?” How does this help customers get the results they need? Who exactly uses this and when/where/why? The big idea in Agile is moving our teams from thinking about tool features (what it can do) to customer benefits (what I can do). Using User Stories as a fundamental organizing principle of our Product Backlog reminds us to focus on use and value, not on the system itself. Using a prioritized backlog ensures we are doing the most important things first, all the time.

We don’t know what we don’t know

Agile also acknowledges some fundamental challenges in how we work. Most methodologies acknowledge that work should begin with the customer’s requirements, but the real challenge here is that the customer’s understanding of their own requirements is often very fuzzy. Not that people aren’t trying to give IT good information, but everyone learns through the process, and then the customer will likely change their minds about certain things, adding certain pieces, changing others, and removing ones that turned out to be bad ideas. THIS IS GOOD! Agile practices simply acknowledge the truth of continuous learning and improvement, and make it possible to be need and priority driven instead of plan driven.

Risk Mitigation begins with early delivery of the highest value pieces

All services, whether formalized into projects or not, are valuable because they support outcomes for customers (enable them to get things they want) while managing costs and risks. Risk mitigation is never the most fun part of a service, but it is deeply fundamental to the value proposition. Agile practices support risk mitigation in many ways, but the greatest risk in my judgement is not getting enough engagement, input, and “fingerprints” from the customer in how we create solutions. By supporting team models that actively engage the customer throughout the process of developing solutions, Agile practices can course correct earlier, save rework, deliver solutions earlier, and improve solution stability.

Digital Transformation means thinking less about departments and divisions (IT vs business) and much more about teaming; how different business capabilities collaborate to automate and improve business processes and workflows. In upcoming blogs we will investigate how some of our customers are using Agile practices to transform how their organizations are creating new value and new business opportunities for their stakeholders.