Enterprise Navigator

Down Economy PMO Survival Guide: Five Actions You Should Be Taking Now

I'm not even going to try and wax philosophical about the current market -- there are plenty of others doing that and it is well past the point of finding any humor in it. It is what it is, and while the pundits banter about what 'it' is, the one thing we all know for sure is that it is getting pretty dicey out there for many organizations.

The whole situation can be quite depressing unless you put the nightly news in context; the most sensational failures, pessimistic guests and worrisome statistics are going to grab the headlines -- misery sells. But just like in politics, there are only local economics; some verticals are faring better than others, and many businesses are weathering the storm OK… so far. Nonetheless, even among the fortunate it pays to be realistic and assume that significant impacts are looming. I think it is a safe bet to say that any reasonably managed organization either already has, or is in the middle of creating contingency plans for several different and mostly negative long term scenarios.

As a result, even successful PMOs might find themselves between the stadia lines of the hidden cost control snipers that are scanning the horizon for likely targets. With that in mind, I thought it might be useful to discuss the measures that the PMO should already be taking to proactively support in-progress or potential future cost containment moves, even if you haven't been asked. Should some sniper start pulling the trigger, doing these things now just might help save your bacon, instead of them becoming your last act of defiance.

1. Make sure the leadership team has a clear view of what is going on. Managers need to know where Point A is, should they have to figure out how to get to Point B, as in Bummer. If your current report battery does not yet have work classified or graded by what is discretionary, mandatory or base work activities, make sure you have appropriate categories defined and work accurately flagged. Similarly, if not already done, now is the time to start looking at how that work lines up by market, product or service line, or similar dimensions appropriate to your environment and scope. Summarize the financial and resource capacities being consumed in each category and get it in front of the executive team, and be prepared to deliver supporting details on demand.
   
   
2. Identify what is the minimum required to keep the organization functional. This is when it pays to be a PMO that looks at ongoing operations as well as project portfolios. Assume that funding for transformational work is going to dry up for all but the most critical projects. This means that the leadership will turn their focus on what is left and how to conserve expenses further. Assess what it takes to just run the business as-is and nothing else, should the organization have to tread water a few quarters. If the storm worsens, map headcount and work activities further to denote scenarios for cutting first into the meat, and then to the bone.
   
   
3. Identify cost reduction opportunities and implications. With last weeks post in mind, do not forget that the PMO has a unique cross-functional perspective of the organization that is unlike any other. This is allows you to see things that others can't. Take the initiative to objectively assess the organization from your vantage point and offer any meaningful thoughts on how the belt might be tightened. The PMO is also in an excellent position to identify the possible consequences of any cost saving measures that either you or others uncover. Volunteer your analytical capabilities to the cause.
   
   
4. Get staffing and utilization information up-to-date and in the right hands. Resource costs make up the majority of spending in a knowledge worker environment, either directly as salary and benefits, or indirectly in supporting infrastructure and services that the staff needs to function. Sadly, as the unemployment figures bear out every month, people are bound to be affected as part of any significant cost control measures. Help the leadership team make these unbelievably difficult decisions wisely by making sure they understand how to best reduce the workforce with a least impact on operations. Leverage your insights into how staff is being used to identify critical skill sets required to maintain core functions viable, key resources that would be difficult to replace, and flag the areas where reductions can be made with minimum long term effects.
   
   
5. Identify & communicate the minimum operating requirements of the PMO. If you are successful at doing items 1 through 4, you will again remind the leadership team why they need the PMO to begin with. Regardless, if things break bad, the PMO will be impacted just like the rest of the organization, so be prepared when you see the train coming down your track. Start thinking now about what will be required in the PMO should some version of a worst case scenario eventually play out. Formulate options and the business case to negotiate something other than total disbandment and have these discussions with your sponsors well before decisions must be made. Here is your argument:
   
   There is a lot to be said for being able to maintain continuity of PMO assets and functions, even when greatly scaled back, rather than having to reinvent the wheel from scratch a year or two later while on the road to recovery. Prepare a list of critical services that the PMO can provide to help keep things operational in a lean environment, as well as how the PMO will speed up the bounce back -- being the first mover coming out of a recession has historically proven to be one of the greatest advantages a business can have. This means that all of the processes and infrastructure you have painstakingly put in place will need to be ready to rock when the arrow starts pointing up again. It is unlikely that a new manager tasked to restart the PMO 18 months from now will embrace past systems, tools and processes -- without PMO continuity, you lose the knowledge base as well as the ability to your keep management assets maintained in a functional state. In the end, it will cost far more in lost opportunity and PMO rework than the additional savings of cutting a few headcount.

Planview to the Power of 10

I figure most folks catch our home page on the way to here, so I haven't blogged much yet about our new product version beyond my February 4th post. The release of Planview Enterprise 10 is making quite a positive splash in the industry as well as among our current customer base -- while incremental improvements to the product are always welcome, the buzz and level of excitement about this version is clearly palpable within the user community. Analyst response has also been quite positive, even among a few of the more jaded souls who were initially skeptical about our entry into product portfolio management -- once they got a good look at what we had done… well, let's just say that seeing is believing.

Brian Sommers is one of the first industry gurus to cover it, with a nice mini-review of Planview Enterprise 10 in his blog on ZDNet. He did a good job of hitting the high points of what makes this version so special. AMR also has a great review for those that are members.

I guess it isn't necessarily evident to those outside of the business that there is so much more to a new software release than lines of code. Much like a duck serenely moving across the pond, under the water line there is a heck of a lot of paddling going on, from marketing and communications to supporting documentation, to training material updates and building new relationships, among countless other activities. Even with the software itself, there are things like streamlining code and performance improvements that may not be readily visible or get called out in the release notes, but ultimately add value to the overall package. It has been many months of hard labor, but we are mighty proud of our new baby -- she's wicked smart, very pretty and already speaks 5 languages! Visit Planview.com for the complete rundown on Enterprise 10.

What Makes the PMO Unique?

I am putting the finishing touches on the presentation I'm going to use to kick off the PMO Track at the upcoming Rocky Mountain Project Management Symposium that the Mile High PMI Chapter puts on each year in Denver. Part of the discussion will be around what really makes a PMO different from other management and coordination roles in an organization. I thought it might be worthwhile to share this with you.

Even though the event is still a few weeks away, I figure I can safely blog about this because the potential for readers to fall into an intersecting set with symposium participants is pretty low. Even if you do read this and then attend the event, it's not like I'm ruining the punchline of a good joke or anything serious.

If we sidestep all the corporate buzzwords and boil down the basic functions of a PMO to their bare bones, I come up with eight broad categories, as follows:

• Gather and distribute information (pass-thru)
• Manage demand
• Reporting & analytics (value added analysis & comparisons)
• Coordination and collaboration
• Identify issues and opportunities
• Manage capacities (people & money)
• Provide processes and tools
• Provide specialized expertise, training and coaching

I'm thinking this pretty much covers 90% of the core services offered by 90% of PMOs. Certainly there are going to be differences about how these capabilities are applied within an organization, but most of these functions are arguably PMO standard operating procedure and our recent PMO survey results support this.

After I came up with this list and accompanying clip art to symbolize each one (thereby creating a visually pleasing mental cue for us left-handers to grasp), it occurred to me that these activities also pretty much constitute the job description of anyone in middle management. Toss in something about hiring and firing functions and endless meetings and you can post this as an opening for the "Director of Anything."

Hmmm -- could it be that this is why some line managers tend to not be too impressed by the idea of a PMO? Have you ever noticed how that relationship sometimes has a certain strained vibe about it? Like how medical doctors perceive chiropractors or acupuncturists, or how pharmacists think of herbalists? Architects versus Feng Shui gurus? Certainly this is not always the case, but every once in a while you find yourself in an organization where you catch a whiff of slight distain in the air when line managers must interact with PMO.

So really then, what makes the PMO Director different from the HR Director or the App Dev Director or the Logistics or Marketing Director?

The PMO directors are the fiddler crabs of the management kingdom, spending much of their time going sideways. Whereas all the other line managers operate primarily on the north-south axis of the org chart, the PMO is unique in that it provides the functions mentioned earlier across organizational boundaries. Line managers spend most of their effort drilling narrow and deep within their respective specialized areas. The PMO must traverse the matrix to link these individual capabilities together. This is a critical distinction and immensely important.

Those of you who have studied the PMO 2.0 survey and the top operational challenges identified within it may remember that the most problematic among them were departmental silos, organizational maturity and interdepartmental politics. A strong PMO and process foundation will go a long way in helping to break down those barriers that form between different groups, helping the organization to better collaborate and function more efficiently.

So, that is what makes the PMO unique; it is not necessarily the functions it performs, but rather how it applies those functions to transcend and federate the fiefdoms and silos of the organization (as well as align executive ranks with the rest of the management team). To the extent that the PMO can successfully execute that service, it will be seen as a value to the organization, and just perhaps, be held in high esteem as a wizard with special tantric powers.

Reverse Engineering Your Reality

Let's see if I can't get back on my game here a little better today. We are back from a worthwhile event in Chicago at CampIT, where over a hundred professionals gathered to spend a day focused on the intricacies of IT PPM. We had some insightful presentations and lots of great follow up discussions with a very engaged group of participants.

But the 60 degree temperature swing between there and Austin did nothing to help shake a nagging cold that is starting to impede my normally ebullient attitude. There is nothing quite like flying with a congested head -- not even tried and true submariner tricks for equalizing ear pressure worked, and I am still dealing with intermittent reception on the starboard side. To top it off, the collapsible handle on my favorite rolling computer bag blew out. Ah, the glamour of business travel.

Back to the topic at hand. The speaker that followed my opening presentation, Michael Menard of The Gensight Group, said something that caught my one good ear and triggered this post. Michael was discussing prioritization of the project portfolio and early on made a bold and nearly profound observation that I will loosely relate as best as my Sudafed-soaked memory allows: it is not mandatory that you have a defined strategy to guide the project portfolio -- the contents of the portfolio itself defines what your strategy is.

How true.

It immediately reminded me of a similar point that we make in our best practices for Application Portfolio Management. When talking about aligning applications to architectural standards, we indicate that if you do not have such standards formally established, then the applications you have serve to create a set of de facto baseline standards for what your current state architecture is. Once you reverse engineer your existing standards from them, you can then adjust those standards to guide future changes in application architecture direction.

Everywhere we look, we see examples of how the realities of our organization effectively reflect back to us who and what we really are, regardless of what might be otherwise stated in some obscure document. Back to Michael's point, even if we have a strategic plan, how we really expend our capacities is ultimately the true measure of our strategic direction. Similarly, how the organization acts day-to-day to achieve certain outcomes is what defines current processes, not boxes and lines on a flowchart. Finally, on an individual level, how we spend the majority of our time every week constitutes our job description. This is a distant cousin to, "You are what you eat." Along those same lines, I believe it was Forrest Gump who quoted his mother as saying, "Stupid is as stupid does."

So, with all this in mind, it occurs to me that this whole idea can be put to practical use as an exercise in self-checking. For example, when faced with a situation that Michael describes where the project portfolio is comprised of projects that were approved without benefit of an overarching strategic plan, there is some benefit to reverse engineering what the imputed strategic direction is. The result might be, "do a lot of really risky internal improvements" or, "approve only the requests from the business unit that makes the most revenue."

Boiling things down to their as-found state and categorizing them based on their attributes brings some factual illumination to how things really are compared to internal perceptions or intentions. If there is a mismatch, then you have a basis for making improvements and changing your reality.

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.