Enterprise Navigator

Agile Redux: How Planview and Our Customers Have Benefited from Agile

Last week I generally discussed how agile planning techniques were being driven by the new normal. This week, we thought you might enjoy getting an inside view of the difference it makes. Rob Reesor, our Vice President of Product Development, shares his thoughts about how we made the shift to adopting Agile development here at Planview and what it has meant for us and our customers.

Guest blog entry by Rob Reesor, Vice President of Product Development

In conversations with Planview customers exploring Agile, most have been interested in hearing case studies, experiences and best practices from their peers. In that spirit, I would like to share a very high level view of Planview's journey to Agile, as well the benefits we've seen.

To provide some context, I have a fairly long history with Agile; in fact, my grad school classmate, Kent Beck, has written several books on eXtreme Programming (XP), one of the most widely practiced agile development methodologies. I had the unique experience of working with Kent in introducing XP to one of my former companies. From my roots at the University of Oregon to Silicon Valley and now Austin, I have spent my career implementing Agile development practices in high tech organizations. My story with Planview began in October 2007, when I joined the company as VP of Product Development, where I was tasked with accelerating product development cycles to be as responsive as possible to customer-driven enhancements and new capabilities. The Planview product development team was just beginning to explore Agile, and I knew from experience this would be an important shift to help meet the goals laid out for my team.

Agile does not happen overnight, and it requires a significant shift in culture and processes backed by commitment from leadership, product management, and development teams. Moving in the direction of Agile, the biggest cultural change was the close working relationship between our developers and product managers on a daily basis. Rather than deliver an extensive requirements document, product managers now put together short user stories for the development team to tackle. In turn, developers are able to deliver working code much faster, quickly change course, and increase speed to market.

Over the last two years, Planview has steadily moved in the direction of Agile, implementing organizational, structural, and process changes to realize the vision. We point to the February 2009 release of Planview Enterprise 10 as a key milestone, because the product was built using Agile processes and the release was managed with Planview Enterprise PPM. The team was able to cover significant ground with major product enhancements, making it one of the most successful product deliveries in Planview history. The iterative approach to product management and Agile application development has yielded Planview and its customers several benefits:

• Better meet customer requirements -- The product development team is empowered to represent the voice of the customer by delivering working code earlier, which means they can react to customer feedback at all stages of the process. Planview's deep customer partnerships have always been a differentiator for the company through programs like the customer Inner Circle, but now we can truly say the product is customer-driven.
• Deliver the right product at the right time -- Adopting Agile has increased the productivity, speed, and agility of our product management process. Planview has been able to lead the market with new functionality and offerings, which is why Planview Enterprise 10 was named by Forrester as the No. 1 current offering for business-driven portfolios in its December 2009 Wave report.
• Drive the portfolio management market -- As an independent vendor with a single market focus, Planview is uniquely positioned to drive the portfolio management market by staying focused, nimble, and innovative. The Agile approach improves our ability to stay on the cutting edge through its value propositions of customer involvement, speed, and productivity.
• Deliver a higher quality product -- The ability to test the product from day one and throughout all stages of development improves quality engineering and assurance, because any minor issues can be proactively identified, isolated and resolved.

Portfolio, Portfolio, Wherefore Art Thou, Portfolio?

(I'm sticking with the Shakespearean title theme -- ere was ye motley dashboard of federal spending; this time, portfolios hearken forth my gibber.)

In addition to being a bit of a romantic, the Bard of Avon also had ghost issues. Perhaps Macbeth was first to utter, "I See Dead People." Not me. I see portfolios. They're everywhere and they speak to me (not out loud of course -- that would be weird; just voices in my head).

For example…

Do you happen to be reading this in your work area? If so, you probably only need to divert your gaze a scant few degrees before your eyes fall upon 'the unit.' Ah, behold the obligatory commercial office shelving. Maybe it is a tall, five-shelf wall rig or the more compact 42-inch variety. Perhaps yours is neutral beige, a more dramatic black or a really tony ersatz wood grain number. It is no doubt lined with books. And more books. And stuff.

Is your poor credenza so crammed with books and binders that prestigious awards, cute and colorful college memorabilia or photos of your pet are being crowded out? Are piles of literature stacked on the floor next to it? Well, whether you realize it or not, this constitutes a portfolio management opportunity; you have a specific issue or objective related to a group of demands and some capacity-based value judgments to make.

The opportunity is to present your shelfgoods in a functional and vaguely professional manner, or at least so as to avoid office embarrassment (or in my case, eliciting outright laughter or pitiful head shakes). Perhaps you just need to make more room for recent library additions, a prized gold and maroon stuffed gopher mascot, or new 5x7 portraits of each of your eight cats. Yes, the condition of your 'unit' speaks volumes to your colleagues -- out loud, I might add.

In terms of demand and capacity, the content of this particular portfolio constitutes all the various and sundry items that are fighting for limited shelf space. Each element in the portfolio is analyzed for its cost-benefit (really now, do you still regularly refer to that "Altair BASIC Programming for Dummies" guide?), and ultimately decisions are made. Some things go and some stay in order to achieve a Zen-like balance and sense of workplace tranquility.

I bet that if you take a moment to think about your organization, you will be able to identify several other situations with the potential to benefit from applying portfolios, no doubt with greater significant business consequences and in need of more analytical insight than our featured decorative reference dilemma. The issues you face when managing the products, services and assets of your organization are not that different.

In every case, you are trying to achieve some objective or result, often using a combination of existing and new portfolio elements. The management goal is to make the best possible selection decisions about these items, usually in terms of benefit, cost and risk. Once selections are executed and delivered, portfolios help to analyze whether the results fulfill expectations as well as identify when new situations brought about by change require further action.

Bottom line, portfolios are not just about projects; they are really more about the reason behind the projects. Everywhere you turn there are potential portfolios; of product families, target markets, service offerings, resources, suppliers, strategies, and investments. Portfolios can include applications, equipment and other assets (like books and knick-knacks).

All you have to do is look around and they will speak to you too.

The Big Picture: Putting Your ITIL Initiative in Perspective

I was out recently for a few days on a very productive advisory visit with a customer. One of many topics we discussed was their ITIL initiative. It's a subject I've touched on previously, but our exchange inspired me to revisit the topic.

Like so many IT organizations, their ITIL program was being led from the operations side of the shop, with little involvement from the PMO and their PPM program, the portfolio managers or development. Hmmm. Let's think about that for a moment -- the objective of ITIL is to do nothing less than provide a method to manage the service lifecycle from end-to-end, yet too often the implementation becomes isolated, addressing how to manage IT from a tactical, technical and operational standpoint. The success of an ITIL initiative depends on taking a more strategic view of how IT service management should be integrated into the overall scheme of things.

This is what the ITIL lifecycle looks like to me:

For all the wonderful guidance in ITIL, it still requires alignment with other management functions to establish a complete approach to managing IT. The recurring nightmare for many organizations is ITIL's lack of recognition for the role that project management plays in IT or any allowance for incorporating that critical discipline into their parlance. This will generate more friction than rabbits on a Berber carpet. Heck, even Microsoft figured that one out with MOF (Microsoft Operations Framework). In my graphic, the cloud between service design and service transition represents that pesky little detail of SERVICE DEVELOPMENT that is missing from ITIL.

The other major issue I have with taking an exclusive approach with ITIL is its woefully inadequate treatment of application management. I am at a loss to explain why this does not play a greater role in the library. You cannot adequately manage the portfolio of services without first getting your arms around your application portfolio. Ask any customer of their opinion about a service that IT provides and chances are excellent they will talk about a particular application. Applications are the tangible interface between the humans in IT and the humans that use the services they provide. Apps are the primary motive force, largest cost element, greatest change driver and biggest drain on resources for 90% of IT services. Oh by the way, applications are the main reason all those servers and infrastructure exists.

Ultimately, successfully managing the technology service lifecycle is an exercise in managing change. You must have a firm grasp on the value, cost and performance of the applications and services being delivered before you can determine what changes are needed, a cohesive, value-based IT strategy to drive change in a unified manner, and a comprehensive approach to managing all the IT work and resources involved in the lifecycle.

The important take-away is to recognize that ITIL is (one) approach to managing IT Services. Viewing the effort as an 'IT service management' initiative rather than an 'ITIL' initiative opens up whole new vistas for how the challenge is approached. This subtle shift in terminology allows you to step back and view the endeavor in terms of the business outcomes that are being pursued, rather than entering into a monogamous relationship with one particular methodology and simply ticking off which subject areas have been instituted. It also gives you permission to explore options -- for each IT capability ITIL addresses, as well as for how to incorporate all of those that it does not.

You: The Product Developer

What busy times we are having around the halls of 8300 North Mopac this year. You may recall that in my October 15th post on the Primavera acquisition by Oracle, I discussed how being positioned as the leading independent in a market drives that organization to be the force of innovation. Well, as we are, so we do.

In case you somehow managed to miss the whale-sized splash across our home page, we issued a press release last Tuesday to mark our 'official' entry into the product development market, including the addition of our new Product Portfolio Management (PdPM) component of Planview Enterprise, related strategic relationships and other aspects associated with delivering a mature product development solution right from the start.

I say this is our official announcement because we have actually been in the business of supporting product development for 20 years now, whether we acknowledged it or not. Now, in addition to everything else, we have that in common with you too, since you're also in that business as well, right?

As you may know, we have been supporting the IT market with gusto since our inception, and certainly technology delivery is, by definition, a specialized form of product development. But beyond that, each and every one of us develops 'products', regardless of if whether tend to think of our work that way or not. Allow me to explain.

Over the years, we have always had a handful of customers at any given time that deployed Planview expressly for product management purposes and many found it to be a good 85% solution. PPM has always been a very competent project and resource management platform, and later, EPM helped define and align product strategies, manage capacities and make investment decisions; all important aspects of product management.

But, when we talk about PdPM as a specific practice area, there are unique requirements that greatly enhance the ability to define and manage the product portfolio beyond typical project management and corporate strategic planning functions. As we worked with these customers, it became clear that if we were to ever get past 85% we would have to think about how we could better serve their needs. The problem was that such organizations were a relatively small part of our overall customer base, so it was hard to justify the investment (OK -- in retrospect, we were blinded by our market paradigm, but then so was everyone else).

Over the last few years we noticed the number of product-centric buyers coming to us was steadily increasing and the overall level of interest in this area started to grow substantially. I guess you would have to ask Patrick Tickle about the specifics of this event, but eventually we had the 'duh' moment:

Every single customer we have develops products.

Think about it: whether you are an insurance company, a bank or a government agency, you produce a portfolio of products. That epiphany, along with analysis of the current PdPM market and offerings, some expert strategic guidance, and a lot of really top-notch work by our own product development folks is what put us where we are today.

So you see, when I said earlier that you too are in the product development business, I wasn't talking about the daily deliverables you work on -- I am talking about the organization you are part of. Extending Planview Enterprise and our company focus into this area is as natural as sunshine and wildflowers. I encourage you to check out the new PdPM capabilities as well as the new delivery platform for them: Planview Enterprise 10. The overall usability of the product is greatly enhanced with this release, along with the addition of several important new capabilities. As Greg Gilmore our COO has said on several occasions, this upcoming release is among the most significant in company history.

Going for Process Gold -- The ITSM Academy CPDE Course

Did ya miss me? Sorry for going a bit silent. I spent all last week in Ft. Lauderdale attending the pre-public version of the Certified Process Design Engineer™ (CPDE) Course offered by the ITSM Academy, preceded by a quick weekend sanity break in Key West at a REAL Lobster Fest. As I write this, the eye of Tropical Storm Faye is visiting the Keys; I figure between all the beer, crustacean drool, sweat and drawn butter spilled on Duval Street while I was there, the place was due for a good scrubbing anyway. Please — just don't hurt the Green Parrot; it's over a hundred years old and I would really miss the joint.

But I digress…

While the focus of the CPDE course is definitely directed towards service management processes, at least 80% of its contents are broadly applicable to pretty much any kind of business process — there's more on that later, so read on.

Successful course completion and passing the exam gains you CPDE certification accredited through Loyalist Certification Services. Note that Loyalist is based out of Canada. The graphic is the CPDE certification pin. While the folks at the ITSM Academy claim mere coincidence, it still gives me an urge to douse myself in maple syrup, speak French and play hockey, eh?

This class constantly reminded me that there are a lot of moving parts to process improvement that architects sometimes take for granted or lose sight of. It is one thing to informally collect tools and techniques over the course of one's career, and quite another to package them all up and deliver (or consume!) them in a five-day period. I have been exposed to, and forgotten, most of the elements covered in this class to some degree over the years, so it was a great opportunity to get reacquainted with all of that content. Perhaps most importantly, I can't really think of anything of significance missing from the course that I would want or expect to see in such an offering. But, to whom to we owe such a compliment?

The CPDE course was developed by Donna Knapp, who leads curriculum development for ITSM Academy. Donna, an experienced practitioner and noted author of several books related to service desk management, also presided over the shake-down cruise of this course to some internal trainers and staff and a few invited outsiders. Some of you may recall that I reviewed the ITSM Academy offering for ITIL V.3 Foundation training that I attended and remarked on the quality of instruction that Joy Yoder delivered. I have to say that Joy wasn't a fluke; Donna, and everyone I have come in contact with thus far at 'the academy' has impressed me with their attitudes, knowledge levels, experience and professionalism, so a big tip of the hat goes to co-founders Jayne Groll and Lisa Schwartz and the rest of the team there for what they have assembled. By the way, both Jayne and Lisa attended the class, so they are fully invested in walking their talk.

OK, so more about the class. The goals as stated in the course manual pretty much sum it up, including utilizing frameworks and standards for process design guidance, determining customer requirements, evaluating the maturity of existing processes, exposing some proven best practices and tools for process improvement (TQM, Six Sigma, Lean, the 7 Tools of Quality, etc.), overcoming resistance to organizational change, and brief review of considerations for selecting technology related to process automation (which I had some thoughts on, as you might imagine). It is a lot of material to cover in a week.

It should not be a surprise that the frameworks and standards discussed concentrate on methodologies such as ITIL, CobiT, MOF and the ISO standard 20000 and 9000 series. Donna employs the ISO 20000 Process Model as a basis for the scope of the class, but also draws upon the ITIL Maturity Framework and an iterative 10-step process design and improvement model that I affectionately dubbed the "Ferris Wheel". You must be at least 60" tall to ride this puppy.

I have designed and managed enough processes to choke a pig over the past 25 years, but I am not, nor have I ever been a service manager, so I entered this course feeling a little bit hobbled. Fortunately, between my ITIL foundation and the fact that I had recently spent some time looking over both MOF and CobiT for an unrelated reason, those parts were not an issue. But the ISO standards were foreign to me, so getting some perspective on those was useful.

What becomes more problematic for those that are not immersed in the ITSM world on a day-to-day basis is the certification test. Eighty percent of the exam points are concentrated around 16 scenario-based questions. They require the student to apply their knowledge to troubleshoot and select the "most proper" approaches to solving real-world service management process issues, often given some "less proper" options to choose from. That is a good thing, but I would be remiss if I didn't mention that both the practice exam and the final test we took were bears. I think most everyone in the class struggled with them to some degree (and remember these folks are all seasoned). Fortunately, representatives from Loyalist were there to debrief and gather our 'enthusiastic' feedback on the inaugural exam, so hopefully the future test bank will be a little more concise. But hey, that's why you do these initial sessions, right?

(Dying to know aren't you? Yes, I passed…and we'll just leave it at that.)

Bottom line — although the course was designed and intended for those who must architect and manage service management processes, I would recommend that anyone actively involved in developing and improving general IT processes consider this course as a way of quickly building a toolbox of skills and techniques to apply. That's not to infer that a process novice will pop out the other side of the week as an expert; this is probably not a class for novices. But if you are already involved in process improvement and do not have formal basis for your work or a cohesive, structured approach to apply, this class is just the ticket. For those of you who subscribe to PMO 2.0 concepts and thus need greater exposure to the service side of the business, this course will not only make you a better process architect, but has the added bonus of broadening your IT business management horizons beyond projects. Just plan on spending about two hours a night studying and eat your Wheaties on Friday morning!

Gartner APM Maturity Assessment -- I Told You

OK, so referencing my Why the PMO Should Care about APM post on July 15, Gartner also released a publication on that very date as well, titled, "Maturity Assessment for Application Organizations: Application Portfolio Management," by Jim Duggan (ID: G00159828 for you Gartner customers). Now I know some of you conspiracy theorists might find that a bit suspicious, but let's just chalk it up to happy coincidence and timely consensus about the necessity of the discipline.

This is one of eight maturity assessments Gartner did across different areas deemed important to overall organizational performance. In addition to application portfolio management (APM), the others are: project portfolio management (PPM); financial analysis and budgets; staffing, skills and sourcing; vendor management; management of architecture; software process; and operations and support. The reports also offer up the characteristics, findings and recommendations for each of the five maturity levels.

As part of this study, Gartner ranked the average maturity in each area of all the respondents on a 1-to-5 scale; APM came in with a 1.46.

Now before all you APM folks start whooping and hollerin' "We're Almost Number One!" and holding up your big foam hands with the tip of that index finger clipped short, bear in mind that on this particular scale, you are lower than a snakes' belly in a wagon rut, as their maturity index tracks along the CMMi model, where one resembles "we just make it up each time," and five is optimized. I can only assume that a 1.46 means, "we just make it up about half the time, but usually we don't even bother with it." I dunno, maybe that's 0.5; but that would be TOO much honesty, like "I used to be apathetic but now I just don't care." I don't think those types respond much to surveys or pay for Gartner subscriptions.

The only thing saving APM from total disgrace is the "software process" area, which was even lower. By the way, the overall average for all areas was head-spinning 1.8, which is "almost repeatable." Good news for us solution providers though — let's face it, if everyone were optimized, our work here would be done.

The report goes on to explain why Application Portfolio Management is an essential element of a well run "Application Organization" (oh), for many of the same reasons I offered in my posting. It also notes that in larger organizations, "Of our clients that perform APM, roughly two-thirds of them select the PMO…[to manage the APM effort]." Ahem.

Okay, so it's not just the ravings of a single madman offering you this advice — there are apparently others as crazy as I that are share responsibility for the haunting voices in your head, "Gerald, submit the APM Program into the '09 budget…"

Do it Gerald. Either that, or fashion a hat out of tin foil to block out the blog-rays.

Jelly, Tootsie, Bank, Cinnamon, Death and Blog

Ah, so many different types of rolls, so little time…

OK, so I admit that a "death roll" is a bit of a stretch unless you are cueing in on "crocodile maneuvers you never want to personally experience" — Ay Mate, Now That's a Knife!

Some eagle eyes may have already noticed that there's something new on this page today. After manning the helm aboard the Enterprise Navigator for almost a year, I want to (finally) introduce my blog roll to you — a listing of blog links related to the topics I cover that I find interesting and think you might enjoy as well. For those of you who follow several different blogs on business, service or project management, I'm sure a few of these are already favorite haunts. For others, perhaps some of my counterparts will provide you with new sources of insight and commentary. I want to be quick to point out that there are many other blogs out there on related topics that are useful and that I occasionally tune in to, but I can't list them all so here are the ones I'm offering up.

I have to confess, I wasn't much of a blog reader until I found myself writing one. So I'm sure many of you are more deeply familiar with the blogosphere than this relative novice. But, I have found the one's listed here to be most relevant and useful to me, as well as a continued source of inspiration to keep me plugging away at this. I can't help but find it a bit ironic that a mechanism designed to communicate with the masses can be such a cloistered, isolating process in actual practice. Let's face it, writing is writing when you get right down to it, regardless of the means of distribution — and converting thoughts to prose a deeply personal process. The whole blog thing is a bit like shouting in the Grand Canyon only to receive your echo in return while wondering if anyone else has heard you.

Anyway, here is a little bit about each blog I've listed (in no particular order), and then you can decide which ones to further explore on your own.

IT Skeptic — Rob England does this excellent and heavily read blog, focusing on ITIL and IT Service Management; you might want to pass this one on to your Ops folks if you aren't personally into ITSM.

ERP4IT — Another one on ITSM, done by Charles Betz and also widely followed. Both Charlie and Rob do an excellent job of reaching down into the recesses of service management, but this one has more of an IT architecture slant to it.

4PM.com — A blog on project and program management tools and techniques done by Dick Billows; tactical guidance for PM's and sometimes suspicious of us PMO types, but a good read nonetheless.

Scope Crepe — An entertaining project management blog by Rich Matzman, with lots of links and references to others.

IT Project Failures — whenever things aren't going well with your own projects, you can always go here for a quick dose of "cheer up, things could be worse". Besides, we learn more from failures than successes — done by Micheal Krigsman.

PMO Setup T3 — Tips, Tools, Techniques — This is Mark Perry's PMO blog; Mark also does the PMO podcast series, and he has graciously invited me to contribute to a PMO book he is putting together.

EQ4PM — A blog that focuses on emotional Intelligence relative to project and business management, by Anthony Mersino.

PM Think! This is a collaborative project management blog, where my friend and colleague Jerry Manas regularly contributes. Those of you that attended the PMO 2.0 Forum in Philadelphia may recall that Jerry was on our expert panel and we gave away several copies of one of his books.

So, there you have it — happy reading, and don't forget to set up RSS feeds to this blog as well as those I've listed so you can easily stay up to date with ramblings from "out there".

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.

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.

How I Learned to Stop Worrying and Love Benefit Management

Benefit Management is an emerging discipline that has PMO written all over it, although it is still not widely understood or employed. We developed PRISMS best practices for this process area a few years ago, but the subject didn't initially attract much attention. While it was moderately well received as a discussion topic at our annual CIO Advisory Board in 2005, by 2006 at that same event, interest had really sparked. One of the presenters touched on it as an aside, and was assaulted by so many questions that they started getting visibly restless to get back on topic. This year, at the request of one of our major customers, I did a multi-city lecture series on those best practices for their North American program and project managers.

I have to admit that at first I didn't key in on its true significance, but have since come to really appreciate Benefit Management as an essential ingredient to achieving high levels of business performance, but one that is too often missing from the process repertoire. If you can employ this function with some degree of competence, it will drive the improvement and integration of many other main-line processes such as strategic planning, portfolio analysis, scope control, and product and service management.

So, what exactly is Benefit Management, or Benefit Realization as it is sometimes referred to? It is a formal mechanism for making sure that someone is keeping a watchful eye on business value versus cost and risk as a program or initiative is proposed, analyzed, approved, developed and deployed, and the methods applied to accomplish those functions.

Initial interest in Benefit Realization was actually generated by our European staff, based on some of the work that they had seen with their customers, and Pat Durbin quickly recognized how it fit within the overall process management structure we were developing (once again illustrating why he's the master of this dojo, and I am but a mere grasshopper).

This is one of a few process areas where best practices were not derived from our own internal expertise and research. Gunes Sahillioglu had successfully developed and employed Benefit Management processes and tools while managing a PMO for Reuters. Upon his retirement from there, we leveraged his expertise to author our PRISMS Benefit Realization Guide.

Gunes, now an independent consultant and author, is a most delightful chap. Turkish by birth but a long time Londoner, he is adept at many aspects of business management, speaks several languages fluently, tells wonderful stories, and works differential equations to stay sharp the way most folks do Sudoku. I also learned in Brussels that he is a valuable travel companion, as it became apparent he can deftly navigate any menu or wine list in the EU. His wife is beautiful and utterly charming, and his daughter is Parisian. Gunes and I share a passion for Jaguars, but that is where all comparisons end, as he has much more character and wit than I shall ever muster. So with all apologies to Dos Equis, I would like to nominate him as a serious contender for The Most Interesting Man in the World.

But I digress — again…

The role of the benefit owner

The Benefit Owner is the central figure to employ Benefit Realization techniques, working in conjunction with portfolio, program and project managers, sponsors and other common roles. Uniquely, the benefit owner is responsible for maintaining a consistent and detailed long term line-of-sight focus on results relative to risk and cost. They ensure benefits are defined, cataloged and quantified as programs or initiatives are created and developed, and challenge ROI, NPV, or IRR assumptions for accuracy. The benefit owner also ensures that benefit metrics are established integral to program approval.

During execution, the benefit owner is responsible for monitoring underlying projects to ensure they stay on track to deliver program objectives at defined cost-benefit values as they face scope changes, delays and technical challenges. If at any time it becomes apparent that achievement of benefit is compromised or in serious jeopardy, the benefit owner has the authority to recommend replacing under-achieving projects or killing the overall effort.

Post-deployment, and long after the project managers are on to other assignments, the benefit owner stays on point to measure how actual program results track to initial projections, recommend adjustments and communicate lessons learned. In some cases, they may remain engaged over the life of the product or service, assisting in continued evaluation of benefit and making end-of-life assessments.

The role of the PMO in benefit realization

The PMO's role in all this is to help sponsor the program and establish processes, train participants, assist the benefit owners with information gathering and analysis, and facilitate reporting. They are also a natural liaison between benefit owners and project managers to help develop a collaborative partnership.

While there are a lot of underlying details that go into this process, I think you can begin to appreciate how Benefit Management acts as a magnetic force to couple strategic intent with actual results. It fosters methodical analysis of investment portfolios relative to business need, and goes a long way towards countering a fire-and-forget mentality that sometimes takes root after the funding decision is made. By providing active value-based management oversight of deliverables as they are designed and developed, it mitigates the potential for a program or project to go on needlessly, or inadvertently lose the essential elements that deliver true business benefit when stresses arise.

Finally, it addresses the age-old problem of who will measure the value that a new product or service actually delivers compared to those fantastical promises of 4-digit ROI on the front-end. In business management, like most skill sports, a seamless follow-through is frequently the hallmark of proper form.

Next Port of Call: Sponsorship is Not a Spectator Sport