Enterprise Navigator

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.

(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.

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.

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.

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!

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.

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".