Enterprise Navigator

Who Should the PMO Report To?

You may have noticed some netbuzz around the impacts of who CIO reports to in the news lately (Forrester's report by Bobby Cameron and Linda Tucci's subsequent coverage of it, as well as a related mini-slideshow "Who's the Better IT Boss?" on CIO Insight.)

This isn't necessarily a new topic; it's one of many that is apparently on some biennial review cycle of things to dust off and ruminate on — but that's not necessarily a bad thing in this case, because the organizational demographics are changing. So, with the subject coming up again for air, I thought it would be useful to discuss where the PMO should be hanging its shingle on the org chart, because PMO misplacement / misalignment is among the most common and serious problems I find out there.

I know, I know, all those silly little boxes and lines really shouldn't matter that much; after all, we're all equally important, we just have different roles to play on the team. Righhht; now let's all sing Kumbayah as we marvel at how remarkably flat the compensation structure is between the board room and server room.

But I digress…

For CIOs as well as PMOs, how boxes and lines intersect mean a lot, but for different reasons. For example, it's generally accepted that IT becomes compliance-oriented when CIOs report to the CFO, while CIOs who report directly to the CEO are better innovators and strategic partners. The latest Forrester report reinforces this general postulate. (By the way, as goes the CIO, so goes the rest of the IT organization; it's practically guaranteed that an IT PMO daisy-chained up through the CFO is going to be preoccupied with accounting codes, charge backs and cost control issues.)

Back to the PMO in more general terms…

Of course, the PMO has a lot more logical options; while the role and span of control for a CIO is a relatively fixed point, the service area and functions of a PMO can vary wildly. But, not to worry — there is a general rule I will offer that we can apply — assuming the PMO actually includes integration and alignment as part of its functions.

Huh?

The lawyer has stipulated that I must put in caveats like that if I am going to continue making sweeping assumptions and gross declarations. So, here goes:

This particular proviso is related to whether the PMO is pursuing alignment and integration across various parts of the organization, or if its role is limited to passive reporting and administrivia. Because if you aren't really actively working to improve things and are content to just crank out streams of postscript data, then I'm not too concerned about whom you report to, and quite frankly, neither is anyone else. Offer of 0.9% APR for 60 months is valid in the continental US only; must take delivery from dealer stock. Employees, their families and suppliers of Planview are not eligible for prizes. Other exclusions may apply. Void where prohibited.

I especially like, "Void Where Prohibited." What does that MEAN?! So much for the fine print. Onward.

In order to foster things like alignment and integration, a PMO must consistently encourage changes in behavior in other parts of the organization without any direct authority over them. When it comes to the power of persuasion, placement of the PMO within the food chain is of critical importance. While it is certainly possible to win friends and influence others based solely on great ideas, stunning looks, a clear, measured voice and genuine smile, all the wit, charisma and charm in the world doesn't give you legitimacy. Besides, let's face it, if we had personalities that alluring, we wouldn't be PMO managers, now would we? So, while being a fascinating individual is quite a handy trait, we need something a bit more compelling — like when Obi Wan Kenobi conjures up the Force. We need authority.

Accordingly, I offer you "Doerscher's Corollary for PMO Positioning:"

The head of the PMO shall be located within the organizational structure in such manner that it has a peer relationship with the heads of the other parts of the organization that it is expected to influence and align.

Examples are useful at this point. If you are an IT PMO that is expected to integrate how all technology demand and services are managed, then you had better be reporting to the CIO, because you are going to need to influence development, architecture, security, web services, operations, and every other department head to achieve that degree of alignment.

If you are being asked to do that as a PMO manager but are reporting to the director of App Dev, you are going to have a rough day at the office, because no one outside of your group has much incentive to consider your entreaties. This is tantamount to sending your 9 year-old kid next door to the rowdy neighbors to complain about the noise. Your legitimacy to sway the status quo, no matter how brilliant and gripping your arguments may be, will likely be challenged at some point (if not outright ignored) by other parts of the organization. When this occurs, the authority for others to consider your proposals rests not with you but your boss, so the whole initiative has to do the old "Up and Over" maneuver. A lot of passion and perspective tends to get lost in such a translation.

Organizational parity brings a level of recognition, authority and legitimacy to bear that cannot be simply brushed aside. If you are operating as a peer, your cohorts know they must at least listen and negotiate in good faith, given that all share common superior that is willing intercede if direct reports are not playing nicely together. It's rarely fun when that has to happen.

Bear in mind that all this discussion about organizational placement only gets your foot in the door so you can have a fighting chance. Notice I haven't used the term "respect;" you know how you have to get that…

So, if you find yourself utterly exasperated by your inability to effect change in your organization, perhaps its time to ponder your relative rank on the ship's roster compared to what you are being asked to do. You might just find that your positioning is obsolete compared to new responsibilities; either that or you are seriously overdue for a refresher at corporate charm school.

Does the Name Pavlov Ring a Bell? -- Right Sizing Projects

A comment quoted in SearchCIO from Audrey Apfel of Gartner today rang a familiar note that I thought useful to chime in on. The article was titled, "Project Management Needs to Think Smaller, Faster," by Linda Tucci. The gist of the opening paragraph is that CIOs need to make sure that projects are defined in digestible bytes (that, and to get comfortable with unknowns, which should not be a foreign concept to readers of this page — ref. the Planning Horizon discussions in my 6/24 and 7/2 postings). The article then goes on to discuss various sour perceptions of the PMO in some detail.

But — to the point about how to define what constitutes a project. If we explore the changes in timbre along that bell curve of technology project size, we'll find they vary from a few high-pitched, quick-hitters that are month or two in duration, to the majority ringing out in the 4-9 month, $500K-to-a-million range. Eventually we reach those low frequency gongs that resonate endlessly through the entire organization — the handful of big multi-year, multi-million dollar monsters lurking off to the far right.

But sizing a "project" is often simply a matter of shifting perspectives. For example, the IT department that receives a request to create and support a new business-to-business web site and a few interfaces might very well define that as a project (maybe even more than one) — blissfully unaware of the discussion going on upstairs about the new VAR Alliance "project," and how a small part of that will be adding some new web enabled B-to-B capabilities, along with partner sales incentives, new marketing strategy in the vertical and several other elements. Gee, I wonder if a whole new universe exists within a cell in my thumbnail…

I am reminded of a particular organization that I have worked off and on with for several years now (which has gotten to be quite adept at managing their portfolios). As a brand new customer a long time ago, we were reviewing their IT PM methodology when a couple of policies caught my interest. One was the CIO had mandated that no project could be greater than 6 months in duration, and the other being that they would do all initial assessment and estimating of technology requests without charging back those costs to "the business." In fact, it became apparent that these initial planning exercises were themselves being managed as individual, stand-alone projects.

So, I asked a few simple questions.

"Do you know the percentage of these initial assessments that are actually being subsequently funded for design and development?"

Response: "No."

"Hmmm, might be a good metric to track, along with just how much utilization is being consumed by these "free" assessments." (After all, there is never a shortage of good ideas…only cash.)

Then I asked, "As these projects are broken up to be less than 6 months long, does each one still provide deliverables that directly add measurable benefit to the business?"

Response: "No, sometimes it takes several of them together to reach that result."

"Do you know how many projects you are doing that never contribute to adding value?"

Response (head sinking lower by now): "Uh, no, not really."

Of course by then, the implications of this Q&A were painfully obvious.

So, the moral of the story is this: Regardless of what level of detail or degree of segmentation you decide is appropriate to call a project a project, never — never! — lose sight of the expected business value that the deliverables are to achieve. If this means that many small projects are collected and tracked as a program, then by all means do that. If you have to roll up multiple programs to an initiative to get to meaningful value, so be it. But, somehow, some way you have to maintain that chain of custody between the work being done and business benefit achieved. Otherwise you will find yourself very busy working on meaningless projects. To quote Forrest Gump, "Stupid is as stupid does."

Finally — does the name Quasimodo ring a bell?

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

Why the PMO Should Care about Application Portfolio Management

Application Portfolio Management (APM) is a discipline often left to the IT operations group (if formally done at all), but APM is something that a full service PMO should be involved with sponsoring, if not outright owning, as a supporting function for the overall management of work, resources, money and services. While the PMO historically tends to focus on bringing new applications to life by way of project portfolios, APM gives us repeatable, consistent techniques required to manage the substantial software inventory that inevitably accumulates. Part of that is making sure that apps that have run their useful course are identified and retired. APM can make the difference between an IT shop that runs lean and mean and one that is overburdened with bloated operational costs and staff.

Almost every technology service has at least one supporting software application, sometimes several. Furthermore, next to human resources, the application is often the next largest contributor to the cost of a service. Applications also directly drive the costs associated with the supporting hard assets and infrastructure.

OK, but why should the PMO stick their nose in this discipline? Because APM requires coordination between different technology areas and end user communities, has impact on strategic planning, is a big contributor to overall project demand, is a relatively easy method of achieving (sometimes dramatic) cost and effort reductions, and it is integral to managing IT services. While there are certainly technical aspects to APM, the discipline itself is essentially a business management function.

Besides being a process that is just a general good practice, mergers and acquisitions up the APM ante considerably — inheriting a full complement of redundant applications is one of the major IT headaches that M&A generates. APM is your means of sorting out what to keep and what to toss.

For all the good things offered in ITIL, APM is curiously absent in terms of providing detailed guidance. In fact, it's hardly even mentioned. That oversight makes me a little bit nuts, given that service management is so dependent on application management. Nonetheless, there is a lot of guidance available from other sources as well as the major analyst groups on how to establish and run an APM program. For Planview customers, we provide the "PRISMS Application Portfolio Management Guide" as part of our best practices content for our Service Portfolio Management functionality that is a great "how to" APM primer for getting started without trying to boil the ocean.

APM is a pretty straightforward process. Once all the prerequisite programmatic elements are in place, such as identifying objectives, creating a governance board, and establishing the procedure, APM is an iterative cycle consisting of three primary steps.

Step one is conducting an inventory of applications and gathering information about them. This step is often done in phases to control both the initial effort as well as the scope. APM need not be overly complex or data-intensive. Those just starting an APM program can get substantial value from surprisingly coarse information on only their primary business applications. The low hanging opportunities can often be identified using simple qualitative assessments.

Next, that data is used to assess the lifecycle stage of the applications and their relative cost versus benefit. These results then drive recommendations for consolidation, retirement or further investment.

Many of the management and assessment concepts employed for APM were borrowed directly from the product management world. For example, the quadrant matrix for evaluating an applications' lifecycle is repurposed from the Boston Consulting Group Matrix for Product Management. Data collection and comparative analysis is typically performed along four planes: Business Value, Technical Value, Cost and Risk. Below is an example of how those elements are graphically charted for analysis.

While there is certainly some benefit to be gained from a one-time application inventory and assessment, APM should be an ongoing part of the IT management regimen. Applications should be regularly assessed for how their perceived value changes over their lifecycle. For example, a given application could take on a trajectory over the course of five assessment periods such as the one depicted. Note how both its business value and technical alignment diminish over time, while costs and risks increase.

OK, so hopefully I have made a reasonable case for why APM is an important element of the PMO 2.0 concept, as a critical mechanism for end-to-end management of your IT services. If you do not have an APM initiative in place or under assessment, go ahead and generate a request for one for consideration in your strategic portfolio — it is a low cost program with a high rate of return.

PMO Content from Gartner and Project Times

Well, now that I am back from the family road trip, I've been sifting through the copious content that has been languishing in my inbox and thought I should pass a few on to you.

Dealing with email while on holiday is a matter of selecting the lesser of two weevils. Rather than ignoring it, I have resigned myself to trying to make at least a high-level pass through the clutter every few days while out of the office. It is less painful than coming back to a post-vacation backlog of 435 unread emails; such a homecoming creates more stress than the vacation gets rid of.

However, this trip was such that I had to rely on the Blackberry rather than actually getting the laptop fired up and on line, so here I am wading through the minutia. (BTW, The Beast never did break that 21 mpg barrier. Alas, my carbon footprint could be mistaken for a Bigfoot sighting.)

But I digress.

So — there were two PMO items in particular, that while not fully on a path to convergence, do play off one another nicely that I thought I would share.

Linda was kind enough to point out a recent Gartner research article by Donna Fitzgerald, "How to Avoid the Seven Deadly Sins of a PMO". What — there's only seven?! I'm glad it was her rather than me trying to pick what (not) to include; I can think of at least 40, not the least of which is the all pizza needed to bribe folks into attending learning seminars. (For all you non-Parrot Heads, Jimmy Buffett calls out pizza as the 8th deadly sin in the lyrics to "Bank of Bad Habits". Thou Shalt Not Eat Thy Neighbor's Wife's Popcorn.)

The Seven Deadly PMO Sins according to Donna are:

1. Ignoring Resource Capacity
2. Refusal to Deal with Troubled Projects
3. Failure to Create a Bottom Up Program
   
4. Failure to Adopt Release Management
5. Failure to Speak the Language of Business
6. Failure to Get Projects Off to a Good Start
   
7. Expecting Software Alone to Solve the Problem

I would certainly endorse many of these as being high on my list, especially numero uno. Ignoring resource capacity will certainly send you straight to PMO hell in the express lane. Ditto for being in denial about troubled projects. Some of the other sins need the accompanying discussion to fully appreciate their intent. For example, the supporting content for #3 is about making sure interdependent projects are well coordinated, and the release management discussion for #4 also puts emphasis on the bigger picture from a product and service management perspective.

As far as sin number seven is concerned, from a vendor perspective I was hoping we were past that as still being an active fall from grace. Anyone still thinking software is a silver bullet is probably also a horse thief. What happy irony that it aligns to "Sloth" on the original "7DS" list.

Anyway, Gartner customers might want to give it a read. For the rest of you, I did a quick search to see if it was being offered as an article in the public realm and didn't see anything, but if it pops up, I'll let you know.

The second item of interest comes from Project Times and Robert K. Wysocki, "Is it Time for the BA and the PM to Get Hitched?"  While there is some lead-in based on the title, what I found most interesting is that ultimately his suggestion is that a new type of PMO should emerge, which he calls the Business Project, Program, Portfolio and Process Office (BP4O). The definition, mission, structure, and organization follows. For those of you familiar with PMO 2.0, you will see some striking similarities, except that the primary focus of BP4O remains strictly on projects or groupings thereof. Not so sure the acronym is going to catch on with anyone except the Star Wars fans though. Go to ProjectTimes.com and register to get to this article.

So, reading the two back-to-back, the demand versus capacity issue again jumped out at me. In addition to ranking number one on the sin list, the introduction section of the Gartner piece recommends that "Project resources and maintenance and minor enhancement resources should be separated". Later in the article is discussion that project resources should be dedicated to a single project or task to avoid multi-tasking issues. Well, all that sounds good if you say it fast enough, but it can be difficult if not impossible to do, particularly for small to mid-sized IT shops. Even in larger organizations, dedicated project resources can prove to be a costly proposition that reduces resource and skill utilization flexibility. I fear that we are pretty much stuck with matrix environments, so you either have to duplicate a lot of capabilities to isolate project staff, or become masters at balancing assignments and flexing skills.

Meanwhile, the BP⁴O concept, despite its intended broader scope compared to the typical PMO model, does not address managing ongoing operations within its scope, as it only deals with innovation. I have come to personally believe that today you simply have to integrate managing strategic change, resulting projects and their product and service outcomes as a seamless management continuum. Who better to do that than the PMO?

The bottom line is that for organizations which have dual responsibilities for innovation as well as maintenance and operations, project management must be considered a subset of the larger overall work and resource management equation, or you risk your mortal business management soul to eternal PMO damnation.

Putting the Planning Horizon to Work

In my previous entry, "Onward Through the Fog", I introduced the concept of the planning horizon. I could have extended that one quite a bit more, but it was getting pretty long in the tooth as it was, so I had to stop. I'm struggling a bit reconciling the whole, "it's a blog not a novel" thing.

However, there is one important aspect that I want to follow-up on while the topic is fresh and before I head off on family vacation. Otherwise, I will undoubtedly forget about it. (See, I've been putting off a two thousand mile driving trip until the price of premium gas got high enough. The Beast only gets about 21 mpg at best, and only if we are going 45 mph downhill with a stiff tailwind. Oh Joy.)

But I digress.

So, if the idea of employing the planning horizon concept on a daily basis seemed a bit esoteric to you, allow me to ground it with some real world perspectives and create some incentive we can all appreciate — less work.

Lessons from the University of Hard Knocks

The hardest lesson for me to get my head around when learning how to manage a dynamic knowledge worker environment was the impact of not respecting the planning horizon. When I inherited work management for the engineering group, I was coming in from a background of planning and managing nuclear refueling outages. We would spend about a year building a ridiculously complex schedule, and if all went well, execute that puppy in about 45 days.

We're talking about ten thousand+ activities in the WBS, with enough relationships and constraints to gag a goat. With a half-million bucks a day in replacement electricity costs and 1000 extra contractors on site, the name of the game was absolute schedule control; we're talking about "calculate the top 5 critical paths three times a day" control.

I once authorized chartering a private jet in the middle of the night to go to Alabama to get a valve part we had to have.

Really. It was on critical path, so a $10,000 shipping fee for a $500 part looked like a bargain.

So, imagine how I first went about trying to schedule engineering work. I had my staff of planners trying to make individual assignments for 200 engineers to detailed work plans about six months in advance. Of course, the results of all that effort wasn't worth the media it was magnetized on, because everything out past six to eight weeks was garbage. It looked really good, but it was a complete waste of time.

Engineer responsibilities would shift around, people would come, people would go, new work would come in and work backlog would get cancelled. Priorities changed, and unplanned shut-downs would totally screw things up.

So I had them re-do it all.

It fell apart again. My staff was burning me in effigy. It took a few months for Dan Dudek to finally bang through my thick skull what was going on. Duh. It's all about respecting the planning horizon, stupid.

The Case of the IT Shop Closed for Business

Flash forward a several years later to an assistance visit with a customer managing a few hundred IT resources at a financial institute. One of the first things I always look at is the rolled up histogram of all the resources. The histogram knows all, tells all.

Like a blinding flash, the sharp violin screeches from the movie Psycho started pounding in my head; there before my eyes was the entire staff fully allocated to detailed assignments to 100% of capacity for the next 12 months.

Three letters immediately came to mind that I got used seeing written across the results of my nuclear physics exams — GCE.

Gross Conceptual Error.

I casually asked, "So, are you all planning on getting any more work requests in this year?"

"Of course, we get in new requests all the time", the VP replied.

"Will all that new work have to wait until next year to get done?"

"No, we'll have to do quite a bit of it shortly after it is requested."

"Oh." "Well then, who is going to do it?"

"Our Staff"

Well, you get the idea…we had a good discussion about things like the planning horizon, keeping capacity in reserve for "known unknowns", etc. They're doing fine now.

So there you have it. If you plan past the limits of the planning horizon, not only will you be mostly wrong — you have to do all that planning over and over again! Stop it, stop it, stop it.

Now — I gotta go see the loan officer about a tank of gas…