Enterprise Navigator

Notes from ITIL Foundation Training

You may recall some time ago I noted that I was going to get ITIL Foundation-level certified. Well, after a few delays, the deed is done, and I'm back from immersion in the fundamentals of the IT Infrastructure Library. Since it was held in Dallas, I also got immersed in that massive wind and rain extravaganza that eventually flooded the middle of the nation last week.

While there are many different providers of the ITIL Version 3 Foundation Certification Course such as BMC, HP, Learning Tree and others, the particular class I attended was offered by the ITSM Academy.

I was both delighted and relieved to discover that our instructor, Joy Yoder, has a lot of practical experience in service management. Besides being an excellent instructor, Joy was able to use her background to keep the class interesting with plenty of practical context and references. There are few things more frustrating than being subjected to training facilitated by someone who cannot go beyond the set curriculum. Joy deftly managed my inquisitive barrage; thanks to my classmates who patiently endured the interruptions and commentary.

The foundation-level certification class provides an in-depth guided tour of:

• ITIL objectives and its approach to Service Management
• How ITIL is structured, the processes it includes, and the key concepts
• Lots of ITIL-specific definitions and terminology
• A glimpse into how ITIL relates to other IT standards and methodologies

It concludes with a 1-hour, 40-question formal certification test. I should point out that the foundation course and its certification exam is still at the 'awareness' level; there are several follow-on practitioner courses that delve deeper into the methodology for those who are responsible for implementing ITIL. The foundation level is a good for stakeholders who must govern or facilitate the processes and need to be able to speak the language. For those seriously interested but need more education before making a decision, it is a great mechanism to assess whether ITIL is even right for your organization, and if so, to what extent.

While I went in to this course with a pretty solid grounding on general ITIL structure and concepts, this 3-day tour does a good job of thoroughly exploring conceptual nooks and crannies of ITIL, far beyond the overview you get from a one-hour webcast or and industry article. For me, it did a lot to separate the facts from any preconceptions or suppositions that only casual exposure inevitably creates. Joy was also able to give us some deeper explanation well beyond the slide deck when needed.

So, what did I come away with? First of all, before I complain or counterpoint, let me start by saying that from the vantage point of what ITIL sets out to accomplish — establish an approach for IT Service Management, it does so in a largely detailed and practical manner. I have some minor grief with how it redefines or ignores some common business terms (pet peeve), and others that it simply makes up that are of questionable benefit (really now, if you are going to discuss Deming's PDCA improvement model, then why not DMAIC from Six Sigma as well? Nope — let's make up our own 7-step model instead…). There are few areas where I have to wonder why they even bother to go into them, as they cannot be treated in enough depth to be meaningful.

In my humble opinion, there are also some balance issues; an entire guide dedicated to continual service improvement? Component level asset documentation and information management is a big deal. Service Desk — lots of focus. Yet, applications and their management are barely recognized. Software is the most common tangible deliverable that customers interact with, the core of most services and the primary reason that the other components even exist, and one of the more costly aspects of service development and delivery; why is there so little discussion or guidance about establishing mechanisms for how to assess, optimize and manage them?

Most of all, the class served to further reinforce my concerns over the significant overlaps that exist in V.3 with other proven and widely accepted methodologies. The overlap itself wouldn't be so bad except for the lack of recognition or accommodation. For example, both Service Strategy and Continual Service Improvement concepts pretty much ignore product, program and portfolio management approaches. But the biggie is project management.

I have a better appreciation for how much real work it is going to be to integrate ITIL into an environment that has already established a project-oriented culture. The irony is, because of the overlap, it is probably impossible to fully implement both PMI and ITIL standards in a single environment, yet both disciplines are required; "Projects — 'ya can't live with 'em, can't live without 'em!"

The ITIL Lifecycle goes from (Service) Strategy to Design to Transition to Operation and Continual Improvement. Conspicuously absent is Development. It reminds me of the infamous Sydney Harris cartoon from The New Yorker, where in the middle of a long equation written on a blackboard is the statement, "then a miracle occurs"…

So, while design considerations, deployment and release management are covered, ITIL is mute on the topic of actually creating or changing the service. Why? Ah, because that's the domain of project management. The implementing organization is on their own when it comes to service development, but instead of leaving an area with a big sign that says, "insert PM methodology here", and providing conceptual hooks where the accepted scope of project management can be logically fit within the ITIL framework, it steps all over a good deal of common real estate.

How does one treat areas such as design and deployment, which both disciplines cover, using different approaches and lexicon? For example, is any organization willing to forego the term 'Project' in IT, and replace it with 'Change Request'? Is everyone going to toss their project charters, functional and technical requirements docs and replace them with a Service Design Package, SLR or SAC? I didn't see 'project manager' mentioned anywhere in ITIL roles and responsibilities, yet it is critical to fulfilling the service management lifecycle. How do they interface with the Change Manager? How about the Program Manager? Are they one and the same? These are all details that will have to be addressed when reconciling competing views on IT management. What a shame — it was a missed opportunity for the respective leading governing bodies for these disciplines to collaborate with each other and find alignment.

Bear in mind that project management can't be ignored and won't go away; it is an accepted business practice that transcends just IT in many organizations, it has more tenure, and ITSM won't work without it. I fear that by ignoring the role project management plays in the service lifecycle, ITIL has doomed itself to be partially adopted in bits and slivers, which will obviously limit its effectiveness. We see it already, with organizations saying, "We're implementing Problem and Incident management".

I like ITIL — it has a lot of good things going for it and brings much needed focus on IT services. These critical operational functions lack the relative glamour of big exciting projects yet suck up most of the resources, so it is good for ITSM to get some time in the spotlight as well. But, at the end of the day, these two have to dance gracefully together to really wow the audience.

Some of you may have been following the webcast series we are doing on this very topic — Integrated IT management with ITIL — Part III of this series will be presented live this Thursday morning. We will feature Peter O'Neill of Forrester Research in this segment. Click here to register for this webcast. In case you miss it, this one as will be made accessible on-demand from our Web site along with the earlier sessions already posted.

Building Flexible Consistency with Appropriate Processes

No, today's title isn't just like jumbo shrimp or military intelligence…

Is it just the season, or what? Seems like the past several weeks have been downright frenetic. For me personally, some of that was self-inflicted as I went through my biennial bout of car-swapping fever, with all the time, energy, emotion and money that particular illness consumes. It's like being plagued with automotive malaria — no cure for it when it comes around, but it's a good excuse for a gin and tonic. It also seems like I've been somewhere on business just about every week lately, from one coast to the other and points twixt and 'tween.

Yes, that was indeed a thinly veiled lead-in to defend my lack of recent meaty postings — I really do have a day job.

"Burger's Up!"

In my February 20th posting, Teaching a Pig to Whistle, we touched on the perils of trying to force too many things into too few operational niches with processes or templates for the sake of uniformity, especially when it comes to professional knowledge worker environments. I promised to follow that up with some thoughts on how to strike a balance.

First order of business, from a PMO perspective anyway, is to review what the drivers and real minimum requirements are for standardizing operating models. For example, are there certain mandates that you are chartered to enforce? Things like:

• Corporate and/or regulatory policies, such as the floor for what is potentially capitalized, SoX compliance, etc.
• Certain corporate-endorsed methodologies or standards, like PMI, ISO or Six Sigma
• Anything that is in the "Because I Said So" category from on high… I am not talking about mere suggestions; we're in the land of "prerequisite for continued employment", a.k.a., "Thou Shalt" statements. For example, the timing of certain events (e.g., the budget cycle), mandatory gate reviews, etc.

Those requirements and the underlying minimum process elements necessary to achieve compliance constitute the baseline of what HAS to be done. In most instances, these can be reflected at a pretty high level. If we use project management as an example, most of the have-to elements can probably be depicted and/or enforced at the phase level, along with appropriate work flows.

Everything after that, by definition, goes into the category of discretionary practices.

That doesn't mean there aren't really great ideas or high value approaches that should be done, just that they offer some element of flexibility in how to achieve them. The wheels won't fall off the business wagon if you provide options or allow some room for interpretation. For example, do we have to do something in the testing and validation phase? Yes we do. Do we also have choices in establishing the most appropriate ways to ensure a quality deliverable? Yes we do (If you answered no to that, see me later).

So, the question really becomes one of how to best define and promulgate any amplifying details, where they come from, and how elastic they are. It's also a matter of who gets to promulgate and who must capitulate. Usually it's a lot more fun to do the former than the latter (at work anyway).

States Rights

I am a big fan of a federalist approach for the PMO; set minimum standards and then focus energy on working with respective line managers to first enable them with the proper tools and techniques, and then further delineate underlying details. By doing this, you accomplish several beneficial things.

First, you are engaging the organization to be part of the process of defining operational requirements, rather than being perceived as the mean old PMO that is unilaterally forcing things on people.

Second, you put the power for establishing managerial and technical details into the hands of the people most appropriate to define them for their respective groups. This greatly enhances the probability that such guidance is both correct and reasonable, which is obviously going to up the potential for adoption and compliance. And, since you aren't the one making the demands, it gets you out of the position of having to enforce them later (which is darned near impossible anyway if the manager doesn't buy-in to them in the first place).

It's important to recognize that this is a collaborative effort; the PMO working together with managers to establish processes, workflows, activities or tasks that will meet overarching requirements for standardization, while still being appropriate to the unique needs of a given group. The goal is agreement, rather than argument.

A real life example serves to further illustrate. A bank IT PMO defines project management-based processes for work and resource management, and promulgates them to the development group with some success. In the second phase of deployment, the PMO pushes these practices to the operations groups, who rebel against them. Why? Employing formal project management standards to non-project service work was administrative overkill and did nothing to add to their ability to manage their work and resources. Lesson learned: processes, templates and best practices are just tools used to do a job — pick the right tool for the job.

Employ Modularity

Almost any PMO will have a number of planning templates that are used. In my past life, we had a library of activity-level schedule templates that contained the appropriate tasks, logic and resource estimates for repeatable, routine work elements that we called "fragnets" (fragment networks?! I dunno — weird term and I haven't heard it since). Odd language aside, they were a great mechanism for building out plans quickly with a high level of assurance that the details were correct.

Such modules can be used effectively in most organizations to both distribute the planning burden and engage the experts in developing accurate plans. An example of this I frequently use is the process of defining, procuring, installing and deploying a new server. Obviously, the PMO is not going to be the resident expert on this. Instead, the appropriate group that must deal with making this happen is charged with building out this module, complete with associated forms, planning elements, resource requirements, durations, etc. The PMO provides the planning expertise and platform, but the technicians who must ultimately work to these tasks provide the engineering expertise and advice. Trust me, if you approach them to help with this, they will jump at the opportunity, since it will make their life easier. Project managers or other work planners can then just "plug-and-plan".

Uh oh, I feel an acronym coming on…SOPA, Service-Oriented Planning Architecture (or 'soup' on most menus in these parts…). I'd better check this out real quick. Lessee, there's something about soybean processors and archers in Sydney. This also stands for "schedule of proposed actions". Nice. In aviation circles, it means "standard operating procedure — amplified"; ooh, that's very good. "Synchronous Orbit Particle Analyzer" is a bit out there though. Heh.

But I digress…

Anyway, you can take this concept and apply it all over the place, if you take a look around. A lot of what we have to do is comprised of many smaller routine activities that just need to be properly assembled. Examples include procurement, requirements, engineering calculations and most technology elements. Allow the modules to be owned by the designated expert and make them responsible for maintaining them, but keep them in a common location so that everyone who needs to can easily access them. Encourage everyone to use them, and set up a mechanism to announce when new ones are made available.

The result is much better planning collateral, less planning overhead, more consistency, broader ownership and buy-in, and better performance. After all, that the purpose of a PMO, right? You'll be a hero.

PMO Forum Update: Trading Cherry Blossoms for Cheese Steaks

OK, folks, I told you when I posted the 2008 PMO 2.0 Leadership Forum schedule a few weeks ago that the plans might wiggle around a bit, and so it has come to pass.

Instead of being in D.C. on the 9th of April, we are instead coming to Philadelphia on the 22nd. Hey, if any of you in the Capitol were already lathered up in anticipation, it's only a about a hundred miles; easy train trip, right?

We'll be at the Marriott Philadelphia West, in Conshohocken. Look for registration to go up in a few weeks.

So, the current 2008 line up now is:
Date		Event
Feb. 29th		Dallas (done!)
April 22nd		Philadelphia
May 16th		Los Angeles
June 6th		Charlotte
Sept. 4th		(somewhere in) New Jersey
Nov. 6th		Seattle

Note all these dates are still tentative as we secure venues. I think Erica said we are going to be near LAX for the Los Angeles soiree. We are working on downtown locations for Charlotte, but something is going on that week, as our first options turned out to not be options. Stay tuned here, as there will no doubt be more to follow.

It's a Jigsaw Puzzle -- Connecting the Pieces of Your Strategic Plan

Guest blog entry by Randy Leiser, CFO in Residence

Anyone who has succeeded in putting together a jigsaw puzzle knows that there are a handful of approaches to assembling a big picture from so many small pieces. However, it seems that the process always starts with the same two basic steps — laying all the pieces out on the table face up, and then looking at the big picture on the box cover.

After completing those two steps, the consistency in approach ends. Some puzzle assemblers make piles of similar colors, while others group similar shapes, and still others pick out the border and corner pieces. Invariably, there are also those who disregard completely any organized approach and immediately start digging in, convinced they can assemble the puzzle by starting wherever they find the first connections.

If you think about it, there are some key strategic planning portfolio management lessons that can be learned from putting together a jigsaw puzzle. Like a puzzle, the strategic plan "pieces" and their alignment with the "big picture" can be a challenge to assemble. Where do you start? Particularly if this is the first time the enterprise is methodically assembling the components of its strategic plan.

I submit, like the jigsaw puzzle, start with the same two basic steps:

1. Look at the big picture, or in strategic planning terms, clearly articulate the strategic goals along a cascading hierarchy of missions tied to supporting objectives and strategies. Missions tend to represent fundamental enterprise values that are, or should be, at the core of an enterprise's success. In turn, each mission is supported by enabling objectives, and each objective by enabling strategies and so on until the strategic plan has been articulated to the appropriate level for the enterprise.
2. Lay the pieces face up, or in strategic planning terms, take inventory of the enabling efforts that support the plan. Enabling efforts are the actionable work that produces tactical programs and services. Programs represent a significant undertaking comprised of a series of inter-related, duration-limited projects that produce a specific product or service. Services are organized systems of actionable work that provide repeatable functions or products. There is no question that the inventory step will require organizational involvement and a significant investment of time but have you ever tried putting together a jigsaw puzzle without turning the pieces face up before getting started?

The sorting of enabling efforts begins after the strategic goals have been clearly stated and, most importantly, understood by everyone involved in the strategic planning process. Just like being able to put all the red jigsaw puzzle pieces in the same pile, it will become obvious where the enabling efforts belong. Once in the right pile, the enabling efforts will likely connect to other related efforts. If there is not a connection, then those remaining enabling efforts need to be further considered for fit. That said, unlike a jigsaw puzzle, there will likely be a few pieces that do not fit with the strategic plan. This is a good outcome because there is no sense in spending capacity on things that do not support the big picture.

In fairness, I believe the complexity of the strategic plan does influence the approach taken to align the enabling efforts. Like assembling the components of a strategic plan, a complex puzzle picture with only a few pieces or a simple picture with lots of pieces is much easier to put together than a complex picture with lots of pieces.

The key to remember when assembling the strategic plan is to approach the process using an organized and controlled methodology. For a simple environment, assembling the strategic plan can probably be accomplished with not much more than standard office tools. For an enterprise that has cascading strategic goals and multiple supporting enabling efforts, having a tool that can provide a framework to establish the strategic hierarchy, as well as assist in the inventory, sorting and connecting all the enabling efforts will not only provide a final result that is more powerful and rewarding but will make the process a lot more efficient. And, since strategic plans and their enabling efforts are not static, using a tool makes adjustments and updates far more efficient. Just like a completed jigsaw puzzle — if clusters of already connected pieces are put back in the box, the puzzle can be put together a lot quicker the next time.

On an unrelated note, I'll be attending and doing a presentation at the IT Financial Management Association (ITFMA) Conference in San Antonio, March 10th through the 14th. If you are going, please take a moment to stop and say "hello" if our paths cross in a session or at the Planview display.

Baseline on Managing Knowledge Workers...

This caught my eye today, given the current thought line about how managing Knowledge workers presents unique challenges (see the February 5th blog entry and February 20th blog entry postings).

Baseline Magazine has an article (on-line slide show actually) titled, 10 Ways IT Employees are Different from Everyone Else, by Erika Chickowski. I dropped a comment on it after I read it, and thought it worthwhile to pass on to you. More importantly, perhaps also surface your own thoughts on the statements, either through comments to the article or on my postings here.

Notes from the Dallas PMO 2.0 Forum

As predicted, we had great weather, awesome discussion, and a fantastic turnout in Dallas on Leap Day with over 50 PMO managers and directors attending.

A Full House in Dallas

Eric van Gemeren

I think those who were there will agree that the presentation by Eric van Gemeren of Flowserve stood out as the highlight of the morning. Eric did a great job of explaining how product management intersects with other disciplines such as project and portfolio management and how the PMO serves to further these crucial interrelationships.

We have received permission to distribute his slides in PDF format to those that registered for this event, so it will be e-mailed to those of you we have on record.

Unfortunately, what the slides don't reflect is the commentary that went with them. However, for those of you who could not be there, we have broached the idea of Eric doing a web cast with us that so a wider audience can take advantage of his ideas and approaches.

Before anyone gets the wrong idea, the interactive discussion with the expert panel wasn't exactly chopped liver either!

In addition to Eric, I want to thank Adrienne Bransky with Hitachi Consulting, Jonathan Overton from Baylor Health, and our own visiting expert, Randy Leiser, for participating on the panel and taking the time to share their knowledge and experience with all of us.

Randy makes a point as Jonathan, Adrienne and Eric look on

We got so many great questions from the registrants that I had a hard time limiting which one's to address at the start of the panel discussion. As a result, we took a little longer than usual to turn our attention to the audience, but overall I think the second half was very worthwhile discussion, regardless of the source.

On the ride home, I got a chance to look over the feedback forms. Attendees gave the session very good reviews, along with some great comments and ideas for improvement. The two things mentioned most were, "give us more time to interact", and "set up the room in rounds so people could network more with each other during breaks". I'm going to work on these with our ace event coordinators to see if there is some way to squeeze in another hour of interaction into the next one and tweak the room set up.

A special note of thanks goes out to all the local and regional PMI chapters that allowed us to advertise the forum with them, and to Adrienne and the rest of our partners at Hitachi Consulting for participating and helping to get the word out about this event.

So, another successful forum goes into the books. Up next: Our nation's capital — we'll be coming to Washington, D.C. on April 9th and hope to see you all there!

Finally, last but not least — some boots!