Making IT Work Archives - Page 4 of 5

Filling the ITIL void

As many of you know, I’ve been intimately involved with ITIL practice for more than 10 years. I am launching this Lessons Learned, user-consortium-driven blog to document good practices based on the ITIL and other frameworks.

My hope is that this will be a great place to get facts and support for making ITIL work in your organization. Your moderator does not claim omniscience, and so I hope that each of you will share your own wisdom as well.

This is a great place to ask questions, share success stories and get the support and tools you need to make ITIL work in your organization.

Blocking and tackling — establishing a culture of CSI

The more I read, and the older I get, the more focused I become on results. At the end of the day, people care about outcomes, and are less picky about the path we take to achieve them.

Many of the success stories about ITIL are really success stories about the culture of CSI. You’ll see a common thread among them.

Establish clarity around goals and objectives first…do tools later (perhaps MUCH later)
Get quick wins to build momentum
Focus as much on the organizational change as on the tools
Be willing to win a little at a time to win a lot in the long run.
Get better every day…not every 6-month review

As I counsel my clients, resist the temptation for large-scale CMMI Level 1 – 3 moonshots and focus on establish real commitment to CSI.

Do you have established processes, including written policies, procedures, and process owners?
If not, what are the 2-3 most important things to get started?

Clear goals and objectives
Accountable, empowered owners
Reliable Metrics

Don’t try to implement all the processes at once. Focus on processes and services that will optimize the value and help you achieve quick wins…Incident, Change, and Request Fulfillment come to mind as great places to start.

BTW, RF is consistently underrated (maybe because it doesn’t make any vendors rich)…spending time making “routine service requests” really routine, for you and your users, is enormously beneficial.

Start small to win big!

PM and ITIL

I have been thinking about Carol’s and IT Skeptic’s comments about PM (and have read the thread he pointed me to, and an awful lot more) and I still think this comes down to a simpler notion. We have a yawning, enormous gap in most IT organizations between Design and Operations, in many cases cast in stone through outsourcing deals to different entities with no aligned targets or shared accountability. This creates the hot potato issue with which so many of us are familiar, and which really drives my interest in service transition, and particularly in placing Early Life Support (ELS) firmly in the hands of Release and Deployment Management. It is in fact the job of PM to manage the SUCCESSFUL transition of their project deliverables (which we’ll assume to be a new or changed service) into the live environment, and to support it until

1) The service is accepted by the customer AND
2) The service is meeting its designated service levels (this implies successful event mgmt, operational monitoring and reporting, and other operational readiness capabilities that really should be flushed out more as part of testing and validation activities).

Project Management (and Software Development Lifecycle Mgmt, but that’s another article) need to be able to coordinate service design and transition activities, and I would liken it to the approach ITIL takes with functions. PM necessarily coordinates across all the activities in service design and transition…based on the scope of their project. Process team leads perform activities across multiple projects in support of process goals and objectives (which should map to project goals around, for example, functional and non-functional (or warranty!) requirements).

The actual ITIL books don’t in fact describe exactly how to run projects (and rightfully leave this for the complementary guidance), but like a similar discussion currently on one of the LinkedIn threads about how ITIL leaves appropriate space for governance models (can anyone say CObIT), it really does so for PM as well, leaving flexibility needed to encompass large programs and small projects alike, while still providing a core set of building blocks needed to build a good service.

I’d like to hear from all of you…where do you see the big gaps, and what are your recommendations for addressing them? If you were writing ITIL 4.0, what would you add/remove/change to improve the efficacy of the guidance?

Engagement

If you look at the descriptions of Critical Success Factors associated with ITSM adoptions, the first one on almost any list is Management Commitment.

Sounds good…until you try to figure out exactly what that means…

Management Commitment is more than just the willingness to train people, or buy software, or even have big Communications strategies about how important ITIL is…it’s the willingness to BE committed. The best way to actually measure this is willingness to sign up for roles like process and service owners. In order to ask for accountability from IT teams and to employ meaningful governance and oversight of Service Management, the senior managers (with enough authority to enforce commitments) must be willing to commit themselves as well. IT staff notice when senior teams make real commitments, and will align their efforts accordingly.

I recently watched a short promotional video from one of the major ITSM vendors (I’ll protect the guilty, but you can find it quickly if you look). It depicts a CIO describing the value of Business Service Management, and includes a roundtable with his senior IT staff. Ironically, the copy from the video is more typical than ever.

“I think we should tell the IT staff about the commitments I made on their behalf, so they know what I need them to do.”

Can’t get buy-in that way!

If you want IT organizations to commit to Service Management, IT leadership has to commit itself to processes like Service Level Management, which prevent “free lunch” behaviors and encourage the business to work cooperatively with its customers to evaluate evolving requirements against achievable targets. This involves listening to both clients and IT teams, and working to establish collaboration that focuses on the business value of the outcome, not only “do more with less.”

CIOs need to focus on business outcomes, and then work closely with their teams to support the optimal level of service to meet those needs, balancing cost/value. Taking specific service ownership of a key business service (perhaps, say, an online marketplace critical to sales growth) and taking specific accountability for service outcomes related to that service will raise the game a great deal, and drive the interest in metrics, continual service improvement, and ultimately business results. Once a CIO signs up for the most mission-critical one him- or herself, it’s a lot easier to get other senior managers to sign up for other services, and really establish cross-functional “service views” of the world.

Management Commitment is good talk, but, most of the time, talk is cheap. If you want to see results, demand real commitment, and real action. It will help you dramatically improve your results!

Training vs learning?

Like many other ITIL instructors, I spend a fair amount of my time teaching certification classes. That said, keep in mind that for ITIL implementations to work, it requires the right combination of people, process, and technology. Can your teams effectively leverage your tools and processes to support a workflow that delivers sustained, aligned services? Most of the skills gaps I see are around bridging process silos…making sure inputs, outputs, and triggers are understood, managed, and automated where possible to facilitate incident and problem identification and diagnosis, coordinate transition activities, or align customer service requirements to achievable performance targets.

ITIL implies choices

A mistake many people make trying to use ITIL guidance is expecting it to be explicitly prescriptive (in other words, a step by step procedural how-to). That’s not what it’s intended to do. ITIL at its most useful describes a way of thinking about the work we do (from the point of view of our customers and how, or whether, our services are delivering the optimal value). At each level of detail, legitimate people will raise questions. For example, given the notion of Service Portfolio Management, the strategic decision to build an organizational capability prefaces the arrival of actual customers with explicit Service Level Requirements. Seldom is the real world quite so neat. For that matter, processes we associate with managing transition activities are often supporting strategic planning and prioritization of effort, processes we associate with operation are often providing explicit design and architecture support, and so on. In short, even ideas like the Service Lifecycle are nice models, but that’s what they are – models, and not even simple linear ones.

So what?

Service Management guidance provides a good jumping off point for thinking about implementing processes, services, and considering underpinning tools. In particular, it allows us to begin to define the key activities (and then it’s on us to describe more explicit procedures and work instructions), roles and responsibilities (which then need to be mapped to actual people and governance), and metrics (which then need to be turned into actual measurements with actual feedback, reporting, and oversight). Most of the time the academic arguments that find their way into discussion boards (is a reboot a change?) can be answered for a particular organization based on usefulness (Are we tracking reboot events? Are we logging incidents for which the reboot is a workaround? Are we tracking reboots as part of a change/release implementation? Are we tracking reboots for standard MTBF maintenance activities?)

The answer of course is clear – it depends on organizational need. Remember, the tools (and processes, and guidance) are supposed to work for you, not the other way around!

ITIL implementation — the big picture

I’m currently helping to support a large scale introduction of the ITIL processes (at least some of them) to a large military organization. While there is a lot of focus on the blocking and tacking around processes, supporting tools, and the like, it never seems to amaze me how every one of these adoptions are really exercises in managing organizational change. Perhaps the most important role on your ITSM team is the role of the Communications Manager, because they have to really drive both the client organization and the project team through Kotter’s 8 steps to Organizational Change,

The fundamental reality of life is that people resist change for survival reasons. I know how to survive today. If you change something, I might not know how to survive tomorrow. So I resist. If change is forced upon me, I will adapt, lessening the pain (by not complying) where possible.

In an organizational context, this is a recipe for disaster. If you wish to be successful in your project, you must be successful in creating buy-in and real commitment from the customer. This is very simply a game of WIIFM (What’s In It for Me?). For every stakeholder, you MUST understand the WIIFM, and communicate (again, and again, and again) and get buy-in to that to gain the trust and commitment of that stakeholder. Many times, this isn’t a process issue, or a tool issue, but a political one. What are they winning? What are they perceived to be losing? How do we maximize the benefits and minimize the risks of the change (sound familiar?)

Certification training vs tools

A number of our customers are struggling with how to implement training programs to support their service management initiative. Many approach the training need from a tools point-of-view. In other words, train them on using the Change management tools, not on the process itself. While understanding how to effectively leverage and use your tools is critical, understanding the context of the work in supporting your services is the critical link. What are the proper triggers, inputs, and outputs of the process? What are the dependency relationships between your process activities and that of other processes? How does what is happening in your functional group impact other groups?

We recommend at a minimum some core understanding of the Service Lifecycle and the role the different processes play in modeling, planning, transitioning, supporting, and improving services BEFORE the tools training. Otherwise, people will “fill in the boxes” to “get the work done” without the right level of quality or value capture in their documentation. Ultimately you are at risk of reduce quality and service availability without this core understanding.

Making sense of cloud computing – Part 1

One of our customers asked us to produce a short course on Cloud Computing. While it’s always easy to chalk this up to yet another round of IT Buzzword BINGO, the business models driving the interest in cloud computing are real, important, and must be understood if you want to be able to sustain your service value for your customers. This week, we’re going to look at a number of different aspects of cloud computing and why they matter. We’ll also take an honest look at the challenges that these models create, especially for security and privacy.

Today: Financial Models and Utility Computing

Most IT managers and staff are used to working with tangible service assets they own; hardware, software, tools, and other assorted infrastructure, applications, and platforms. Based on our available resources and organizational capabilities (knowledge, skills, processes, etc.), we would design, plan, develop (or buy), and deploy services in support of our clients. This required the IT organization to use the business’s capital to invest in IT assets, which may or may not be optimally utilized (consider hardware utilization, applications and associated licenses, data center infrastructure and environments, etc.) Capital investments require a substantial commitment of time and upfront money to create a capability, long before a payback period begins (when the new service is delivering value in operations). If the business’s needs evolve, substantial changes in service warranty are needed (capacity, service continuity, security, and availability) and will require re-architecture re-provisioning, and ultimately waste time and resources.

Most businesses seek a different model (and not just for IT!). Businesses generally prefer operating costs (pay-as-you-go) to capital costs, because we can stop buying it if we don’t need it, or request more capacity or a different level of continuity or security (availability is a bit messier, as we’ll discuss later this week) for an understood price per service. Utility Computing is really nothing more than delivering on the promise of ITIL Service Level Management, where for an understood and agreed price we will deliver an agreed level of service at a defined level of quality. The biggest difference then is WHERE we will deliver it…

In the Cloud Computing context, as with the ITIL Service Model, we seek to deliver value to customers while avoiding the ownership of certain costs and risks. Depending on the level of Cloud Computing your organization may consider, this includes potentially choosing not to own

– Applications – we’ll use providers with SaaS (software-as-a-service) models to host and deliver key software applications, especially generic ones like productivity applications (a la Google docs) and ones where access across a number of devices and locations is a strong benefit (CRM applications like salesforce.com)

– (Development) Platforms – we’ll count on our cloud providers to provide our developers with rich toolsets for building and deploying cloud applications; for example, Microsoft Azure extends .NET developers tools to build in the cloud.

– Infrastructure – we’ll take advantage of the benefits of server virtualization, grid computing use of processing capabiliites, and enormous server farms managed by providers such as Amazon, Google, IBM, and many others to scale our storage, data management, and processing needs as they evolve, and make agility and real Capacity management far more accessible and realistic.

As our ITIL readers know, effective provisioning of whole services to customers involve the correct combination of these three things aligned with the business’s needs and managed to deliver a reliable underpinning of their key business processes. Clearly cloud computing has enormous implications for the entire service lifecycle. To deliver “utility” computing, we must do more than just create pay-as-you-go models; we must actually deliver the right level of utility!

Today: Financial Models and Utility Computing

Next time, we’ll talk about Cloud Architecture.