CHAPTER 1: SETTING THE STAGE

The curtain rising on the opening night of a Broadway production is, perversely, the final step in the process of actually producing and presenting the performance. Prior to that opening night, the producers, directors, actors, stage hands, carpenters, lighting technicians, and dozens of others worked long hours to ensure that all items were taken care of, and that no detail was overlooked. Each person – regardless of whether it was the director, producer, or playwright – broke the action down into its component parts, examined them, tweaked them, reworked them, and then repeated the process all over again until they were satisfied they had the best possible production.

While that was taking place, carpenters were busy constructing sets, Foley artists were painting background landscapes, and set designers were arranging the furnishings and props in a way best conducive to the play’s action unfolding on the stage. Electricians, costumers, caterers, accountants, and a host of other staff – some permanent, some temporary – worked in tandem to stage what each hoped would become Broadway’s next smash hit.

What does this have to do with Information Technology Service Management (ITSM)? It has everything to do with it. If you think about it, the two activities are very similar to one another. Preparing an organization to take on a service management mindset takes the same amount of energy, preparation, and coordination as staging a Broadway production. The people involved in ITSM aren’t called producers, playwrights, or directors, of course. Instead, their titles are Project Manager, Process Analyst, Service Owner and ITIL® Subject Matter Expert, but each person – regardless of the part he or she plays – must understand their role, must execute it in the context and timing of the larger production, and must work with the other members of the team to ensure that the firm’s service offering (whatever it may be) satisfies the vision articulated by the senior business sponsor.

As an ITSM practitioner, you will be required to wear many hats, and perform many different (albeit related) functions. As you work through the steps outlined in this book, be mindful of the specific role you’re assuming. Some days, you’ll take on the responsibilities of the producer or director; on others, you’ll be called upon as a stage hand. Knowing the role you’re playing on any given day is essential to keeping your ITSM production on track. Not only will it provide you with a laser-like focus on what must be done, it will help to clarify the inevitable discussions that will take place, and the conflicts that will arise. That being said, let’s get started.

Let’s assume the client is a mid-sized insurance carrier headquartered in the United States. It is a privately-held firm, but one whose activities are managed by a very active Board of Directors. They have recently embarked on an aggressive five-year plan that includes modernization, acquisition and expansion. The Chief Executive Officer (CEO) has been with the company for 15 years, rising through the leadership ranks until assuming his current duties six months ago. To support his efforts, the CEO has assembled a strong, knowledgeable and seasoned management team. This team is intimately familiar with the insurance business – its pitfalls and potential benefits – but has only a rudimentary working knowledge of how IT can help them achieve the Board’s long-term goal – to expand the firm’s national footprint, and thereby increase market share. The firm has a fairly substantial amount of cash on hand, and is willing to spend a reasonable amount in order to improve operations to the point where taking on a 25% increased book of business is possible. Senior management’s collective opinion is that current IT operations would be unable to sustain services should volume significantly increase.

A prime responsibility of a Broadway producer is to secure funding for the production. Money, as the old adage goes, makes the world go around. Your ITSM transformation initiative is no different from any other project vying for the company’s limited pool of money. In order to successfully compete for your share of the pie, you’ll be required to show how your project will contribute to the bottom line. Don’t make the mistake of assuming that everyone will automatically understand how improving ITSM practices will produce a return on investment (ROI).

Despite the fact that ITSM has received a lot of press, and favorable word of mouth, to many people it’s still a vague and mysterious “dark art.” Given that frame of mind, you’ll have to present – to the CEO and your colleagues – convincing arguments for why a share of the firm’s precious dollars should be funneled to you. A well-crafted business plan will give the Board confidence in your approach, and will help to win over those skeptics that may exist in your organization.

To you, of course, the answer is obvious. ITSM will enhance efficiency, improve services, and generally make life better all the way around. While this may be true, quantifying those qualities may prove difficult. So how does one go about building a convincing Business Case?

Appendix A contains a Business Case template that we have found useful. We have also developed a Cost-Benefit Analysis workbook that can be used in conjunction with the Business Case template. These tools, if used together, can help you present a compelling argument.

On its surface, the Business Case template looks rather complex, but closer examination will reveal that it contains not only the justification for financial investment, but also the beginnings of your operational roadmap (discussed in greater detail in Step Six). The Business Case will include a clear statement of executive sponsorship, expected financial benefits (tangible and intangible), total financial costs, non-financial benefits and costs, and a risk analysis (which should include the risks associated with executing the project, as well as those associated with not doing so). And while it is not mandatory, an analysis covering the expected organizational impact that will result as a consequence of your ITSM initiative is strongly recommended.

Within the business plan, you will lay out several possible approaches (courses of action). A good rule of thumb is to present as least three viable options. This shows leadership that you’ve thoroughly thought through the challenges and obstacles that may be encountered, and that you have a firm grasp on how to circumvent or avoid them.

The ancient Chinese warrior Sun Tzu observed, “Many calculations lead to victory. Few calculations lead to defeat.” The more scenarios you can envision, and anticipate, the greater your probability of success. In addition, you’ll instill confidence in your audience that you can handle any circumstance that may arise (even if it’s not wholly anticipated). Your selected approach will spell out all the reasons why you’ve decided on your selected course of action, and why leadership should support it. This portion of the Business Case will undergo the closest scrutiny, but if you’ve done the necessary legwork, you’ll be able to deftly answer any questions or concerns that may be voiced.

Notice that for the selected approach you will list assumptions and known constraints, projected milestones (with corresponding deliverables), lay out the critical factors necessary to your (and the company’s) success, and highlight critical dependencies.

Before moving on, we’d like to take a moment to discuss assumptions and known constraints, as this is an important topic that is often misunderstood.

Assumptions are simply that. They are scenarios that you, as the preparer of the Business Case, assume to be true at the time the Business Case is created. If these assumptions prove to be incorrect or non-existent, the implication is that something in your Business Case must change. The same holds true for known constraints. If identified constraints are removed or modified, then something in the Business Case must be altered. This must be clearly and completely understood, not only by you, but also by your audience.

The implications are obvious. Imagine you are undertaking a journey by car, and have mapped out a specific route. You estimate that it will take you eight hours to complete, and cost you the sum total of $250 for fuel, food and tolls. You have a known constraint in that you have a total budget of $300, with no opportunity to procure additional funding. You also assume that the road on which you plan to travel is accessible. If that constraint and assumption holds true to form, you have no problem. You may proceed according to plan.

Imagine, though, that due to unforeseen weather conditions, you’re forced to take a detour that takes you 50 or 100 miles out of your way. Your original plan is now at risk. (Some would say unredeemable.) You can no longer complete the journey in the planned eight hours, and there is the very real danger of running out of funds, possibly stranding you short of your destination.

The assumptions and known constraints in your business plan, if changed, will have a similar effect on your transformation effort that the unexpected detour had on the scenario described above. Therefore, a prudent ITSM practitioner would be wise to periodically revisit the business plan to ensure that one’s assumptions still hold true, and that the known constraints haven’t changed.

Of course, if assumptions and known constraints have changed, that will form the basis of the intelligent conversation you can then have with the business sponsor on alternatives. Knowing the impact that the changed assumption or constraint will have on the project, you can then suggest one of the other courses of action in order to get the project back on track.

Another key component of the business plan is your proposed execution plan. This isn’t the detailed roadmap you’ll lay out in Step Six. This is the Reader’s Digest condensed version. It lays out the execution approach (phased implementation, targeted approach to address critical pain points, etc.), specifies planning assumptions, talks about potential technology impacts, and offers a high-level estimate for required resources. This analysis needs to be detailed enough to be 80% accurate, but doesn’t need to drill down to the Work Breakdown Structure (WBS) level. Ideally, this approach will be detailed enough to give the sponsor confidence that your project will come in within 20% of the proposed budget and schedule. Because it is an estimate, you’ll need to revisit this aspect of the implementation with the sponsor as the project plan becomes more detailed.

An important point we’d like to stress here is that the execution planning assumptions are not the same as the overall assumptions mentioned earlier. The former assumptions dealt with the implementation at the macro level. They addressed assumptions concerning overall efficiency, the company’s strategic vision, and the impetus for undertaking this effort in the first place. The execution planning assumptions should focus on matters that would (if realized) derail the project. This includes issues such as having the right mix of personnel assigned to the implementation, ensuring that they have the required blend of skills and experience, and they will be committed to the project for the requisite time to complete the tasks to which they are assigned.

Another key section of this document is the risk management plan. Any change introduced into the organization carries some measure of risk. That is the nature of the beast. However, don’t assume that all risk is bad. Risk can be beneficial if managed correctly. This section of your proposal must identify all the potential risks that you believe may arise. More important than that is how you (or the company) plan to mitigate those risks. An approach that’s acceptable for an innovative start-up may be completely inappropriate for an established, conservative firm. It is up to you – as the key ITSM subject matter expert – to assess your firm’s risk appetite, and to tailor your mitigation plan accordingly.

Organizational change management is covered in far more detail in Step Seven of our approach. That section deals with the importance of organizational roles and responsibilities, and discusses the various ways in which you can foster required change through the organization. And make no mistake about it – adopting a service management model is a significant organizational change. Unless your organization is already committed to a complete service management philosophy, transforming the practice of ITSM is going to change the way you do business, and will have a direct impact on the internal workings of the organization. Your challenge in the business plan is to alert the sponsor that a cultural shift is going to take place, and to give them some idea of the work required to effectively manage it.

Before discussing the next section, a point of clarification is in order. The IT Governance Institute defines governance as “… the leadership, organizational structures and processes that ensure that the enterprise’s IT sustains and extends the organization’s strategies and objectives.”³ We acknowledge – and agree with – this definition. However, a full-blown discussion of enterprise governance and all it entails is beyond the scope of this work. For our purposes, we would like to concentrate our focus on the control objectives an organization should put in place in order to ensure its strategic objectives are being realized.

Last – but certainly far from least – the business plan lays out the expected benefits. Although it comes last, it is the section that will receive the most scrutiny and questioning. Therefore, it is critical that your analysis takes into account all relevant factors.

There are a variety of methods for building the best case, worst case and most likely scenario models, each with their individual strengths and weaknesses. We have no preference for which benefit model the reader chooses to use, and will, therefore, offer no recommendations. What is critical, however, is that the expected benefits satisfactorily answer the following questions:

1.   Is the proposed plan adequate? Does it accomplish the intended objective within the business sponsor’s guidance and parameters?

2.   Is the proposed plan feasible? Can it be accomplished within the established time, cost and resource limitations?

3.   Is the proposed plan acceptable? Does it balance cost and risk with the advantages to be gained, and meet the requirements specified by executive leadership?

4.   Is the proposed plan complete? Does it incorporate the activities and tasks that must be performed to achieve the outlined objectives?

5.   Does the proposed plan reduce costs, increase revenue, improve efficiency, or achieve some combination of the above?

If you can answer “yes” to all of the above, then you can have every expectation of your plan being approved and funded by the business sponsor and, at the same time, you will have taken a very big step toward success.

Your Business Plan is done – now what?

Even though you now have an approved business plan, and have received the requisite funding, you still aren’t ready to move on to the next step. One more crucial bit of preparation is required. You now have to communicate – to the rest of the organization and to your external business partners – what you are planning to do.

This is important for two significant reasons. The first is that it sets the foundation for your future organizational change management efforts. Secondly, it offers you the opportunity to educate everyone about ITSM – what it is, what it does, and what the expected benefits will be.

Many people in the organization will assume that ITSM is simply another management fad – quickly implemented, quickly forgotten – that is doomed to ultimate failure. Others will see it as a boon – the answer to all their organizational prayers. The majority of staff will fall somewhere between these two extremes. Their approach will be to “wait-and-see.” Depending on their perception of your ITSM initiative’s success or failure, this group of people will either embrace the service management mindset or reject it completely.

This is natural and expected. It takes time and energy to bring people around to a new way of thinking and a new way of doing business. Organizational change – no matter how ultimately beneficial – is never easy. In fact, we view this step as so critical that we have devoted an entire chapter to it. Remember that you are the principal cheerleader for ITSM, and it is your responsibility to effectively manage this change, and ensure that the proper “tone at the top” is established.

In order to do so, one of your first orders of business after leadership approval is to arrange awareness training and education. Even if staff in your company think they know what service management is and what it entails, it can’t hurt to provide a refresher course. For those who have heard about ITSM, but haven’t taken the time or effort to learn more about it, these educational sessions will come as an eye-opener.

Formal training sessions offer several benefits. They:

•   Foster organizational awareness: Even those staff not directly involved in your transformation initiative will learn what you are doing and what is planned and an educated staff is a better performing staff.

•   Establish a common lexicon: Most often, in projects such as these, the new nomenclature becomes a source of confusion and ambiguity. Formal training sessions, augmented with pocket glossaries distributed after the sessions, allow everyone to speak the same language, and eliminate the “Tower of Babel” effect.

•   Provide context: Staff – especially at the lower levels – often do not know or understand the rationale behind projects of this scope and nature. Training sessions are an excellent way of showing them how this will positively affect their day-to-day responsibilities.

•   Ensure historical and documentary continuity despite staff turnover and organizational realignment.

•   Encourage active participation: A good training program is designed not only to teach, but to motivate and engage. The right training partner will help plant the seeds of future champions willing to support your cause.

Some clients insist that all personnel achieve – at a minimum – ITIL® Foundation certification. Personally, we don’t feel this is necessary. Unless people are going to assume process or service-oriented roles in the organization, the anxiety of having to study for – and pass – the exam, is more stress than the results are worth. Everyone should be trained, everyone should understand what the new service management culture will mean to the firm and the way in which doing business under this model will affect their day-to-day responsibilities, and everyone should be supportive of the effort. Everyone, however, does not need to become an ITIL® Expert.

At the conclusion of the training, staff should have a clear understanding of how to:

1.   Execute activities and tasks consistently using standardized processes.

2.   Manage expectations (between peers and supervisors) predictably.

3.   Achieve clear visibility of outcomes and standard metrics.

4.   Analyze and improve processes that are “built to change”.

5.   Avoid process failures.

6.   Improve and clarify their roles and responsibilities.

This level of preparation will seem daunting to some. To others, it will be seen as being too slow. Often, companies adopt ITSM because they have specific pain points they want to address, and they want those issues resolved immediately (if not sooner). In some cases, you will have been brought in to perform a “quick turnaround.”

We want to say this in the strongest possible terms: don’t shortchange the planning process!

Tactics without a clear-cut strategy are simply sound and fury, signifying nothing. A strategy without well-designed tactics is nothing more than an academic exercise. A comprehensive strategy will direct and guide your tactical efforts. Feedback received from your tactical successes (and failures) will refine and improve the strategy. One cannot succeed without the other. They are the symbiotic sides of the same coin.

Now that we’ve created the business plan, obtained leadership’s approval, been allocated the requisite funding and conducted our education and awareness training, it’s time to move on to the second step in our approach: inventorying the current service offering.

3 COBIT 4.1 Framework, Control Objectives, Management Guidelines, Maturity Models, IT Governance Institute (2007).