Enterprise Navigator

ITIL -- It's Not Just for Breakfast Any More

I mentioned earlier that our Planview Horizons North American User Conference is coming up soon — next week to be exact! It's like having 300 friends drop by to visit for a few days. Even though this is our 9th year, we still get very excited to have everyone come to Austin. Since it keeps growing by leaps and bounds, the list of things to be done keeps getting longer as well. I think we have officially reached the point where planning for next year's conference has to start before this years meeting occurs.

As we all busily prepare for that event, one of the presentations I am involved with reminded me of an important topic to explore with you. In my inaugural post, I mentioned that ITIL was becoming the new black. Version 3 of the IT Infrastructure Library promises to be a watershed body of knowledge for IT management standards, which is why the typical Project Portfolio Management (PPM) practitioner should be very interested in it. In fact, don't be surprised to find that it consumes a lot of your time in the coming year.

ITIL has emerged as the clear standard for IT Service Management (ITSM) arena. If you are not familiar with ITIL, I would encourage you to start doing some homework. If you Google ITIL you will discover any number of sites that you can explore to get a basic understanding of ITIL, but let me make it easy for you. Tech Target has some good information about ITIL in their Q3 Updates for entry-level exploration.

You also need to be asking around in your IT Operations groups where their head is about ITIL if you don't already know. Don't wait for them to come to you or find out about it after-the-fact; you need to initiate the conversation. According to Forrester, 80% of billion dollar companies will employ ITIL in 2008, and about 1 in 4 organizations are somewhere in the process of doing so already.

OK Doerscher, so what does all this operational stuff have to do with the PMO anyway? After all, ITSM is all about running a help desk and monitoring widgets, right? Perhaps this was so in the past. But, what makes ITIL Version 3 so important is that it extends focus from the service execution realm (how to effectively design, develop and deploy services), into the strategic domain (are the services we are providing the right ones, and are they providing value). This is significant to the PMO for a few reasons.

First off, the latest ITIL release now incorporates within its sphere of influence areas you are probably already deeply involved with — things like demand strategy (strategic planning and program management), transition planning and support (that would be projects), and service request fulfillment (that would be pretty much all the other work in IT). It is also dipping its toes into things like resource management.

Like any standard, ITIL has its own approach and lexicon, and these are about to collide with those of other well worn standards such as PMI and the PMBOK. I say collide because at the same time, PMI is expanding into program and portfolio management. While launched from different perspectives, both are clearly on the same strategic trajectory, and someone is going to have to sort out how to make them play well together. That most likely will be you in the PMO if you are a 2.0 business management organization that is taking an end-to-end product lifecycle approach to program and service management. This is why it is important that you get on the ITIL bus early in your organization; otherwise you are in peril of being run over by it.

Hopefully some day soon we will have a single common business management framework that accommodates all the various standards and methodologies, but there isn't one yet. Even ITIL is quick to point out early in its Service Strategy Guide that PMI, CobIT, ISO, and other standards must still be employed for a complete IT operating framework. How to merge all these various approaches has been taking up a fair amount of my own time for the past year now, and ITIL is not to be ignored. How important do I think ITIL is? While I have consciously resisted being pigeon-holed by various certifications over the years, I'm going for ITIL certification in November. I'm certainly not one to kneel at any one altar when it comes to business processes, but it is becoming readily apparent that this one is worth taking communion from, or else risk being branded a heretic in the very near future.

Work Prioritization: The Case for an Integrated Approach

…	louder, louder, louder, louder, constantly,
	quit hollerin' at me…
	— John Prine

I have a new white paper (ok, so it's a booklet) posted on our site for download that is a step-by-step guide to developing and using an integrated work prioritization process. If you do not yet have a comprehensive mechanism in place for assigning relative importance to total planned workload, I encourage you take a look at this and consider adopting the approach it spells out.

You have heard me note that I was a PMO manager as one of several functions during my public utility years. To clarify, I was manager of a work control team for nuclear engineering services — we took in all departmental demand, from several different customers as well as internally generated work, managed the backlog and metered it out to the appropriate groups. We owned the related information, processes and tools, provided planning and scheduling services to our group managers, facilitated the five-year business plan, and performed a myriad other business functions. I had to build the work management group from scratch (I wish I held the patent for scratch — you can make anything from that stuff), and over the years there were a lot of different advances we managed to make.

Unequivocally, putting a common prioritization scheme in place was the single most beneficial process improvement we ever carried out, at least from my vantage point. The reason was it all but eradicated impatient customers screaming at me as the preferred means of communication. As the de facto voice to our hungry constituents about work status, that also made me the services organization piñata. Being tongue-lashed to a tree branch for a verbal bashing was a regular event, despite the fact that not once did deliverables ever fly out my butt as a result. Or candy.

Hey — they were just doing what they felt was needed to get attention to their needs, albeit a bit vocally. If their frustration came through it was primarily because we had such a mediocre track record for delivering things as promised and hadn't yet given them a better communications mechanism. When describing unaligned multiple customer environments, I often use the analogy of baby chicks in the bird nest. Each with their heads turned skyward, beaks open, and squawking bloody murder in hopes of attracting favor for the next morsel. If a sibling starves to death in the process, well that's just that much more for me. Unless you can frame services capacity and usage in a broader context, customers do not care what you are doing for someone else or how busy you are — they simply want what they want, and they want it now.

Once we were in a position to show what we were working on and effectively illustrate that we were not a bottomless pit of resources, we were able to convince everyone to sit down long enough to discuss how finite engineering services capacity should be apportioned across everyone's diverse needs to the general benefit of the business. The integrated prioritization concept was put forth and the whitepaper describes how we built it and what ultimately resulted.

While its original objective was to simply find a better way than shouting to prioritize a variety of work types from several different demand sources, the resulting efficiency increase was a stunning and unexpected dividend. There was general lowering of the decibel level within engineering as well — everyone was on the same page and working better together. All in all, it made my life much more bearable. For the first time we had a common understanding of what was next in the queue, regardless of what it was or who asked for it. The customers had visibility into total demand, where their requests fit into the overall scheme of things, and knew why it was there. There was no down side, and I have been a proponent of this approach ever since. While it's been called out in our proprietary best practices for years, in retrospect, I feel like I should apologize for taking eight years to put it in the public domain.

So, if you are feeling a bit like a piñata yourself as the work management authority for your services organization, click here to download this white paper and let me know if you have any questions or comments.

PMO 2.0 Leadership Forum: San Francisco Here We Come...

Wow — just back from a BPM conference in Vegas, so lot's of things I'm anxious to talk about. But for this post, I want to let everyone know we now have the date and venue set for the San Francisco PMO 2.0 Leadership Forum and registration is open at our PMO 2.0 Resource Center. We will be looking forward to seeing all our friends in the region on Tuesday, December 4th at the Marriott on 4th Street between Market and Mission. Given the date and location, you might as well come in early and get some shopping done, right?

Actually, Austin and San Francisco area have many ties, particularly through the tech sector and our respective eclectic attitudes. Janis Joplin, among several other music notables, got her start here in the live music capital of the world before she moved on to the bay area scene. Much of the early Silicon Valley development was directly linked to the chip design and manufacturing techniques developed here in Austin. There was so much traffic between the two in the 90s that direct flights were instituted, dubbed the Geek Express, which has recently re-emerged after a hiatus during the post-dot.bomb era.

But I digress…

For those not familiar with this leadership forum series, we've been touring the country through 2007, holding half-day events as an opportunity for PMO managers and stakeholders to discuss how PMOs are evolving to meet the new challenges being placed upon them. We kicked the series off in Chicago and moved on to Boston, Denver and Atlanta, with each event getting bigger and better. What started out as a strictly local concept has turned into a regional event, drawing in people from hundreds of miles around the host city (see the write up from the Atlanta forum in my August 30th post in the Industry and Events category).

These morning sessions are basically split into two parts. We kick off with a brief overview of the PMO 2.0 concept and some of the key points we have learned through the series, and then get to hear a presentation from a local PMO Director and their journey. For the City of Love event, Tom Elliott of McKesson Pharmaceuticals has graciously agreed to share his story of how their PMO is evolving.

Next, we convene an expert panel and open the floor for questions. I'm very excited to announce that Jean Gehring of IT Ascent and Bob Sanders of Wells Fargo have agreed to join Tom on the panel, and we will likely add another panelist before we have the session. Tom, Bob and Jean are top notch, seasoned practitioners (see their bio's on the registration link), but we learn a lot from everyone in the room, regardless of where you may be sitting. The open discussion session is very interactive and the 90 minutes seems to fly by.

I've said it many times before and will reiterate that these forums are about exchanging ideas on how PMOs can better enable the business, not about what tools can do or are being used. In fact, most attendees are not Planview customers or prospects, and they range in size from small local companies to multi-nationals, adding to the diversity of thought. If someone wants to stick around and see our products, we offer an opportunity for you to do so over lunch, but that is after the forum itself is over.

So, if you're going to San Francisco, be sure to wear… naw, I can't even finish it. Just be sure to mark you calendars and get registered — we hope to see you there! (and sorry about sticking that song in your head for the rest of the day.)

Now, where did I put my paisley jacket?

Thoughts on Acquiring a PPM Application (Part 2 of 2)

In my previous post I discussed why it is so important to structure a sensible timeline for a new application initiative, from approval to roll out. Part of the issue revolves around the selection and procurement phases trending longer and longer. This entry will touch on a just few of many things to consider that will help keep you on a reasonable buying schedule. If you like this, let me know, there are more…

Know what you want, and why you want it

Referencing my last entry and the posting from September 28th (Sponsorship is Not a Spectator Sport), an application purchase is likely driven by some chronic pain. Before you ever start shopping, take the time to clearly document your pain, why you have it and what you think it is going to take relieve it. This will save you tons of time later on.

Answer those questions from a combined people, process and tool perspective, as well as internal versus external requirements, and get major stakeholder agreement. This will lessen the potential of internal bickering erupting in the middle of the process, and help vendors understand who you are, what you want, and why you want it. We really are interested in being a partner that provides the value and capabilities you need, but before we can do that we have to understand them.

Be pragmatic about your ability to change

Today's application suites are a marvel of integrated capabilities, offering a dizzying array of features and functions. This has potential to inadvertently expand your intended scope well beyond your ability execute. While all the technology can be put in place relatively quickly, there are limits to any organization's ability to change over a given period of time. Once all your major objectives and outcomes are identified, analyze, prioritize and focus them into process-based capabilities that can be deployed in phases. This will help you be more realistic about what you are asking for, as well as put you in a great position to discuss deployment with vendors from both strategic and tactical perspectives.

Use analyst information to quickly narrow the field

There are a large number of products that all look competitive on web sites and magazine ads. But, in over 80% of our opportunities, it's the same small group of the usual suspects that are eventually rounded up for evaluation (Casablanca is definitely in my top five of all time favorite movies). Now is the time to get real benefit from that subscription to Forrester, Gartner, AMR, etc. Most analysts will offer a brief synopsis of each product in terms of functionality, strengths, weaknesses, and relative ranking. Vendors work hard to ensure these groups have accurate information to do their job. Draw information and opinions from multiple sources and use this to help ID who you evaluate. If you are planning to submit RFP's to over a dozen product providers, you might want to do a bit more homework to narrow the field to 6 or 8.

Control the RFP process

Product selection is essentially a communications and learning process. Written content is the least effective and most time consuming means of doing this when compared to verbal discussion, visual demonstration and hands-on experience. Nonetheless, RFP's have grown steadily over the past few years and are now so bloated that responses can be well over 100 pages. You have pushed past the point of diminishing returns if you find yourself spending several weeks preparing them and waiting on responses, only to drown in a sea of data while fishing for information that is really useful and relevant to the selection process.

I've been involved in creating and responding to many RFP's over the years; typically the question volume is inversely proportional to their quality. Since RFP's tend to be strictly a written Q&A proposition with little or no opportunity to ask each other specifically what is really meant, vendors will put in information based on their interpretation of the question, and tend towards too much content rather than risking too little. General questions yield general responses, which are of limited use in the actual selection process.

For example, Describe your technical architecture. Now as you can imagine, the range of response could be a paragraph or a booklet. A predictable outcome is frustration from your technical rep on the selection committee because the ability to support a Citrix environment wasn't mentioned…

If I were back on the buyer side, I would limit the RFP to focus on the only the key functional and service requirements using a checklist format (Does your product support a Citrix environment?) as a due diligence document and mechanism to winnow out those who do not have required capabilities. I'd rather spend more time (and that of the vendors) in initial face-to-face discussions, demo's and preliminary evaluations of no more than a half dozen contenders. You can always employ a broader list of nice-to-have features during these sessions.

Look hard at the final few

Take a broad, hard look at companies and products that make the short list. Remember, software is only part of the solution, so spend plenty of time discussing other important aspects such as services, training, commitment to the product line, future direction, etc. DO NOT rely solely on a 1-hour vendor demonstration of features and functions. Trust me, the people who do these are experts and many are ex-magicians — they can make anything look good, clicking faster than you can blink. Take a day to look under the covers to understand how the product is really wired. If you have a complex set of requirements, take the time and effort to do detailed proof-of-concept sessions of two or three days with each candidate. Be willing to pay for this to show you're serious; it is the best insurance you will ever buy.

Thoughts on Acquiring a PPM Application (Part 1 of 2)

The 4th quarter is always a crazy period for us. Major marketing events (most of our marketing staff is at the Gartner IT Expo as we speak, while others are at PMI in Atlanta), Fall product releases and the Planview Horizons US users group all happen before Thanksgiving. And, much like the retail segment, holiday season sales are a big part of our income for the year. Of course, this isn't because Santa is planning on stuffing a key disk in your sock, but more the result of a lot of organizations with a software project on the docket for 2007 that are now 8 or 9 months into it and under the gun to finally get something purchased before the ball drops.

Since the planning season is in full bloom for all you of a perennial persuasion, I thought I might offer some suggestions on how to structure an application deployment initiative, should you be considering one for 08. I'm thinking I'll break this into two installments, so as not to put everyone into a stupor. In the first part I want to discuss instilling some sense of control over the timeline of the overall initiative. It is not that unusual for the average sales cycle to take 6-8 months these days, which is not only crazy, but also has a significant impact to the overall success of the initiative. The second part will provide some specific considerations on how to help meet that timeline.

Everything I'm going to say could no doubt have been written by any of the major software vendors, so I'll chalk this up as a generic service. Because Project Portfolio Management (PPM) still constitutes the majority of our sales, I'll use it as a point of reference, but most of what I'll offer is applicable to almost any business application.

For all but the largest global enterprise deployments, the average customer should be able to get through a software selection and procurement cycle in three to five months, and start harvesting the results of their labor in quarterly installments thereafter. I'll discuss some ideas to help achieve that in the next installment, but for now I think it important to illustrate how a protracted buying cycle negatively impacts the overall program.

Remember, we select a technology platform to improve and automate processes as a means of relieving a chronic organizational need. You would think that would instill a measured but steady approach to doing everything that is required to get relief. But the selection process seems to be extending to longer and longer periods, while executive expectations remain constant for how long it should take to deliver results. The deployment cycle ends up getting squeezed as the buying cycle expands to consume all the time available, which is a Bad Thing.

It never ceases to amaze me how the irony of deploying a planning tool in crisis mode seems to be lost on those who engage in this bizarre behavior. Can we agree that spending eight months to select a product, two months to procure it, and then insisting that it be deployed in six weeks to meet an arbitrary deadline seems a bit, shall we say, out of balance? Treating the entire initiative as a highly visible and structured program with appropriate milestones for each major element is one way to control this. Otherwise, the selection team will consume all the available duration they can, leaving those who must actually make the change holding the bag to meet the unwavering target completion date in the strategic plan.

For planning purposes, your deployment cycle for an application should be at least equal to the time it takes you to select and purchase it. Forget Earned Value — if your planned four month selection cycle slips three months, that's probably a pretty good indication that your deployment cycle will also need to be adjusted. The reason for this is that critical path in both instances is the ability of the organization to gather information, assess it, and then formulate, approve and validate decisions. It's silly to expect that you will be able to make process configuration decisions like greased lightning if you cannot do so when making a buying decision. The same political, cultural and emotional dynamics are at play in either case.

I'm by no means advocating that a major application solution be purchased without appropriate due diligence — quite the contrary. I am, however, suggesting is that such an effort be treated with the same sense of rigor and control that is applied to any other part of the project. Each step in the process should be designed to add incremental value to the decision process, rather than simply going though administrative, CYA motions.

Next Port of Call: Acquiring an Application Part II; Ideas for Controlling the Selection Cycle

Managing Change for Change Management

OK, before you read any further, I want you to stop and establish a mental picture of Change Management.

Got that in your frontal lobe? Now slip it back into the deck, right there on top, taking care to let me see it, and I bet you I still can't get it right. Here's why.

Now, did you put on your PMI hat and think about scope control? Or, were you wearing your service management glasses and think of configuration control? Those in app development were probably thinking code control or versioning. Perhaps you are currently undergoing a revamp of processes and visualized controlling organizational change. Finally, any new parent undoubtedly conjured up how big of a stack of Huggies is needed to make it through a family visit.

To all the various standards and methodology organizations and committees of the world, PLEASE quit laying claim to such common terms and declaring myopic and unflinching definitions for them. Hardly anyone is printing stuff out any more, so the cost of a adding a modifier word is so low as to be immeasurable. Given that the PMO must deal with all those examples above (perhaps the Huggies not withstanding), it surely must be as frustrating to you as it is to me.

So, I want to start a movement, a grammatical revolution, a veritable forced march towards effective communications. I want to suggest to PMO staff that any time someone mentions Change Management, immediately ask the following:

Oh, are you talking about scope management, configuration management, code control, or application version management? Or, do you just need to change your pull-ups as a result of the new process we unveiled?

Perhaps after hearing that a few times, folks will start being a little more descriptive in their language, and recognize there are equally valid interpretations of terminology. And, just maybe those various standards committees will quit trying to hijack common business lexicon by twisting them up for their own nefarious purposes and pitting brother against brother in an uncivil war of definitions.

By the way, it was the Three of Spades — now how on earth did I do that?!

Five Steps to a Mediocre Planning Cycle

In keeping with the spirit of strategy and budget planning season and to infer a bit of continuity to this stream of consciousness (hah!), I thought it an opportune time to air some of my pet grievances associated with typical cyclic planning approaches. I thought about a Top Ten List (no shortage of issues), but figured if you find this personally relevant right now, you probably don't have the attention span for that many. Besides, this isn't a one hour talk show…

1. Don't Provide Top-Down Guidance
   I'm always disappointed by the lack of defined direction provided to organizations during the planning cycle. Heck, even in a commune, everyone gathers around to get aligned on what crops to plant. This is a highly collaborative process with the involvement of many individual inputs — unless a clearly written business strategy is communicated to participants, they are going to have a hard time shaping their input to align to it.
2. Accept the Status Quo
   Too often, budgets are baselined to whatever input was provided the previous cycle as a starting assumption. If you keep doing what you've been doing, then you shouldn't expect anything different, right? The planning cycle is the greatest moment of leverage to shift how business is being conducted. If you want significant change, then utilize funding and budgets to make change happen.
3. Avoid Contingency Planning
   If I am staying current, Greenspan is predicting a 30-40% chance of a recession. How will your business be impacted depending on 08 election outcomes? What happens if oil goes to $110 a barrel or there is a shooting war with Iran?
   
   Nowhere is it cast in stone that only Business As Usual assumptions are used to create a single set of inputs. Extend the value of planning by adopting a PERT-based attitude: develop Most Pessimistic, Most Likely and Most Optimistic versions of the plan, based on a range of pre-defined business environment impacts and assumptions. The degree of variance that results from these inputs provides great insights into volatility and your vulnerabilities, while giving you the confidence that various scenarios have already been thought through and are readily available for quick deployment.
4. Plan Beyond Your Effective Horizon
   If you can only reliably prognosticate 12-18 months into the future with at least half a chance of being right, then don't waste everyone's time asking for a detailed 3-year plan. All you are doing is propagating everyone's perception that this is a meaningless exercise if you ask for information that isn't dependable. Why not ask for a 6-month plan in great detail, a summary plan for the next 6 month period, and only gather general predictions/conceptual direction for the outlying periods. (see discussion of Planning Horizon concepts in whitepapers or web casts available from our PMO 2.0 Resource Center)
5. Drag it Out
   Planning cycles should be approached like bandage removal; make it an acute event rather than chronic ailment. Put enough focus on it to quickly get it over with. A few hairs will grow back, and it's a well established fact that extended planning causes you to pull it all out anyway. If you fuss and fiddle with it for three or four months, you will increase the potential for plans becoming obsolete before they can be put in play, generating a phobia (e.g., Allodoxaphobia, Decidophobia, or Tropophobia), or worst of all, a nasty strep-like planning infection, which is the organizational equivalent of stripping sanity right off the bones. Referencing my entry from last week (If it's football season…), better to do it quickly and often than making some kind of major Broadway production out of it.