Enterprise Navigator

Does Methodology Matter? Turn to Fashion for the Answer

Regarding PMI's monthly journal PM Network, this may stun some of you, but I generally do not devour it cover-to-cover. After a decade or so, I find that most special interest magazines start to repeat themselves. I usually scan the table of contents and quickly flip through it to size up the marketing budgets and skills of the advertisers.

However, a teaser on the January 2010 cover caught my attention and I immediately went on safari for the matching article on page 27 -- a one-page commentary by Jesse Fewell; "The Great Debate," subtitled, "It may seem like blasphemy, but methodology doesn't matter." By all means, read the article, but I want to continue the larger conversation.

Jesse and I firmly agree that methodology does not matter. But, why not? The article doesn't elaborate on that point. To answer, we have to first look to what a methodology is. Michael Hanford (whom I consider among the more brilliant of the Gartner analyst ranks), offers the following in a review of the new Prince2 update (also a great read -- ID Number: G00172256, dated 13 January 2010):

"Methodologies are a body of practices that prescribe an ordering of work within a discipline, while "best practices" describe successful or well-used work approaches. One view is that methodologies are adopted by organizations, while best practices are adopted by individuals."

In my experience, when organizations wholly subscribe to and adopt methodologies, they tend to breed zealots. Zealots get myopic and then other options and approaches start to get branded as 'wrong' rather than 'different.' Zealots are dangerous; that's how wars start.

This is where the world of fashion comes in to play. (What has Bravo and a house full of women done to me?) Like a good suit, methodologies seldom fit as they come off the rack -- they have to be tailored. Methodologies represent a general set of practices that must be applied to the context of a specific circumstance. They are also subject to interdependencies with other disciplines that are outside of their own scope (in other words, incomplete). As a result, all of them have to be adapted before they can be adopted.

Methodologies are like fashion lines. Even the most snobbish avoid limiting their wardrobe to the work of a single designer. Preferences are fine, but some situations call for Versace and some days you just need Ralph Lauren. Why on earth would you limit yourself exclusively to considering any one methodology? Mix and match -- it is OK to carry a Coach bag while wearing a DKNY blouse (however, no matter what you see on the red carpet, Armani with Converse is NOT OK).

Finally, like designers, any single methodology is probably lacking some essentials that make up a complete wardrobe; case in point, adopting ITIL exclusively without a good project management foundation is the equivalent of going out in your LBD without… well, um, let's just say certain prerequisites, and leave it at that.

Given the Texas weather, I am a big fan of the layered look; perhaps a basic process foundation, with a casual PMI jacket, and some Val IT accessories. Maybe I'll toss on a bit of agile if I'm feeling especially pretty.

OK, you get the idea -- methodologies matter about like fashion magazines matter. They are useful to browse while getting a pedicure or to glean ideas from, but let's face it folks, most organizations just don't have the body to pull off a closet full of Lean. Build a wardrobe of functional and comfortable options, and pull together an outfit that is age and occasion appropriate.

Addressing the Hierarchy of Guidance

Greetings from sunny Austin, as we endure our umpteenth consecutive day of record-breaking triple digit heat; today's forecast is only 105 F. I figure we have about 77 more such days to look forward to before we get a meaningful change unless a hurricane pops up in the Gulf. Just so we're clear, I'm not whining, merely sharing. At least you don't have to shovel heat out of the driveway.

I received a comment from Hanu Karavadi on the Stoutlining post from earlier this month, asking if I would explain the difference between various levels of written guidance typically found in organizations. Well Hanu, here we go.

Whenever this subject comes up (yes, it is a regular topic of discussion), I have a little drawing I use to illustrate the concept of the 'hierarchy of guidance.' (If it seems eerily familiar it may be because it was posted in one of my entries way back in November, 2007 titled, A Schedule and Process Walk into this Bar… In that post, we took a look at the differences between -- you guessed it -- process steps and schedule tasks.)

This time, let's focus more on written guidance. Although this relatively simple graphic does not fully cover all the possibilities or terms that may be applied, it helps get the basic point across that there should be some clear relationship between various forms of guidance. Much like playing Jenga, removing levels from the middle of this hierarchy can send the whole carefully stacked structure tumbling down in a topsy-turvy cacophony of disarray.

Specific to Hanu's question, policies are typically related to providing high-level governance that is broadly applied as formal and specific expectations. Policies, (along with methodologies and standards) presume that some number of options might be considered generally available; of these alternatives, there are one or more prescribed options that are considered acceptable or otherwise constitute a defined approach. From a glass-half-empty perspective, they can also identify what is excluded or NOT acceptable. Gotta love those dress codes, right? "No shoes, no shirt, no salary."

Perhaps we can use IT as a more useful example. A policy states that all IT expenditures will be charged back to the consumer organizations. This policy may drive the adoption of ITIL or CobIT as the selected approach (as a methodology or standard) to manage IT services and thus fulfill the policy.

At the next level, processes are employed to further establish the specifics of what is to be done, and by whom. To continue the example, ITIL offers a general approach and terminology for how to define and catalog IT services; processes are developed by implementing organizations to specifically lay out the underlying steps taken in this environment, along with roles and responsibilities. Note that now we are discussing organizational specifics. To put it loosely in CDPE terms, a process is a set of interrelated activities that are event-triggered where a set of specific inputs result in a specific set of outputs (results).

But all of this guidance discussed thus far has only prescribed what to do, not necessarily how. How-to guidance is established through procedures, which are step-by-step instructions for how to perform one or more tasks. For example, a procedure might define how to perform the month-end close process for determining IT service costs and charges.

Supporting these processes and procedures are best practices and guidelines. A best practice offers amplifying how-to information that reflects a proven approach; for example, a best practice that explains a the best approach for zero-balancing the IT budget each quarter. Unlike procedures or processes, which constitute what we referred to as "Shalls" in the nuclear industry, best practices and guidelines provide "Shoulds" -- they are suggested but optional approaches that infer some situational flexibility on the part of the user. Best practices tend to be more educational in nature, while guidelines are more often structured like 'soft procedures.'

There are additional levels of guidance that can be established, such as work practices and instructions, but this is where the water gets murky, since these detailed documents are often defined differently within each implementing organization. There is also the concept of 'toolbox skills' which defines a set of minimum competencies necessary in order to be able to perform a given task, often by role or performance grade, but that is for another time.

OK, there you have it -- the hierarchy of guidance, understanding that all of these things we discussed should be driven by the missions and objectives of the organization in question.

Improving Management Health -- Getting Off the Big Comfy Couch

I bet you suspect, "OK, it's almost the end of March, so judging from the title this must be somehow related to all of the recently-abandoned New Year Resolutions involving gyms, low-carb foods or running." Not so my friends; this is actually about the importance of finding some balance across different management focus areas -- even when it forces you to address topics well outside your zone of comfort and expertise.

Besides, I don't run. If you see me running, it's because I'm out of ammo. You better run too.

One of the things we commonly find is a situation where organizations have fallen into a lop-sided approach to management improvement initiatives. Let's say for example that several years ago a generally process-immature organization began a program to advance its ad hoc project management capabilities. They kick it off by bringing in an experienced, PM-savvy manager, identifying what is in the project portfolio, and establishing some basic processes to help move projects through the lifecycle. Later, they start to build out some document and WBS templates, get some basic tools in place and begin a training program on PM fundamentals.

So far, so good. A year or so later, with some early improvements recognized, another round of PM refinement is launched, adding more rigor and sophistication around scope and requirements management, use of decision points and milestones, and better performance reporting. Flash forward a few more years and improvement cycles, and the organization now boasts a high percentage of certified project managers. Overall, the project management methodology itself gets a strong B grade.

But, the law of diminishing returns kicked in some time ago and making further progress in raising the project success rate seems to be stuck in a rut. What went wrong?

Project management became the big comfy couch. Bolstered by early successes and becoming increasingly comfortable with the initiative, the organization decided that continuing to improve project maturity was far more inviting than turning equal attention to other management areas in need of development. To continue the work-out analogy, it's like getting past the initial pain and establishing your technique for doing wrist curls. But, if that is all you do, then you may end up looking like Popeye the Sailor Man -- able to firmly grasp project planning and execution, but little ability to do the heavy lifting needed for true innovation.

Consider this: if you make tactical improvements to your project management capabilities but ignore strategic planning or project selection, then aren't you potentially executing the wrong projects more efficiently? If so, then the net business value of those PM improvements actually goes down! You are, in effect, wasting money faster. Furthermore, improvements in project management are inherently constrained without commensurate improvements in managing resources.

On the back side of project management, improving how project deliverables are managed operationally is equally important. Building an effective go-forward strategy relies on understanding the effectiveness of the services and products you are delivering today relative to the needs of your markets and customers.

The underlying message is that all of these elements are inter-related, so putting a myopic focus on continued improvement in one single area gains little in additional benefit until related areas are also improved to a level of functional parity. Real operational efficiencies are gained when small step improvements are made across all of the core business process areas in several iterations.

Now, get off that couch and go exercise some of those other management areas in need of some muscle; consider it process maturity circuit training.

Controlling Operational Challenges -- PMO 2.0 Survey Results Teaser

Before we get rolling, I want you to shift your focus about 2 inches to the right — see the Email Updates box? We know how hard it is sometimes to remember to take a moment out of your busy schedule to do discretionary things like read your favorite blogs. If you invest about 20 seconds right now to sign up, we will send you an email and link whenever new posts to the Enterprise Navigator go up. We are just trying to do our part to make life a little bit easier for you.

---

The analytical dust has settled, and I am putting the finishing touches on the conclusions and recommendations for the 2008 PMO 2.0 Survey Report this week. Meanwhile, we are finalizing the schedule for disseminating the information out to all that are interested.

Dare I say, some of the key findings are just going to rock your world.

For everyone that participated in the survey, you can expect to get your copy first, delivered to the email account you provided. This should happen a day or two prior to a web cast we will hold to go over the results. Expect all this to go down around the first week of December.

Why so long? Well, just because I am finished with drafting the report doesn't mean it is ready to go out the door. I need to do an internal briefing on the results, it has to be professionally edited and formatted, blah, blah, blah. Plus, we really think it will be more meaningful to offer the findings up via a web cast; setting it up, getting it publicized and allowing you time to register quickly eats up the calendar.

Allow me to whet your whistle just a bit in the mean time. Among some of the more significant findings is the relationship between operational challenges and their impact compared to other factors. For those who took the survey, you may recall there were 33 common challenges listed, divided into four categories; organizational, process, technological and situational. We asked respondents to identify the impact of each of those challenges, with options ranging from Critical Problem to Significant Challenge, Minor Issue, Not a Problem or Not Applicable. I converted responses into scores, and twisted that numerical data every which way I could, comparing it with several other responses to understand relationships. Let me show you something:

Each vertical column represents 1 of the 33 challenges, while each pair of horizontal rows represent the average impact, and the prevalence of issues marked as 'critical' or 'significant.' Obviously there are scores corresponding to the dashboard colors; those as well as the challenge and attribute titles are omitted for the purpose of tickling your curiosity.

Even with all the details absent, what is glaringly apparent is that a "certain particular attribute" has a HUGE effect — across the board — on whether organizations are being controlled by the host of more insidious challenges, or whether they are able to successfully mitigate their effects.

(To further titillate your intellectual desires, I will tell you that there are actually not one but two related characteristics that yield very similar results when correlated to operational challenges, resulting in a steamy performance management ménage a trois.)

I have to admit to you, when I first uncovered this finding, I was initially swept with a profound sense of sadness. The responses that constitute the first few rows represent real organizations with real people, and there is obviously a high potential for real frustration under such circumstances. Look at how many of these challenges consistently come in as red or yellow, and let me tell you, that is not a good thing. It means that most of the time the issue is CRITICAL or SIGNIFICANT for most of those that fall into that group. Over half of the challenges listed collectively conspire to torment well over a hundred different organizations every day, impacting their performance and generating misery.

The white boxes are neutral, meaning the average impact falls somewhere between 'significant' and 'minor', or that the rate of significant occurrence is less common. Green is good of course; the average impact is 'minor' or less, and the frequency of these issues being identified as significant is under 40%. So, what is so different between the organizations that have to endure the active lava flows littering the operational landscape in the top half of the rows, versus those living in the cool green valley of the lower half? Well, that's the good news — getting control of challenges is readily achievable by any organization that wants to. Just realizing that the whole situation is correctable pulled me out of my funk and I quickly recouped my customary jovial composure. The answers to this little riddle are in the report, along with a host of other actionable insights.

Of course, you know that this blog is ground zero for staying informed about things like the date and registration details for the web cast, or how to download a copy of the report, or any scheduled public presentations on the survey — did I mention that you could sign up to get an email alert when important information like that is posted? Thought so.

Making Trade-Offs in the Portfolio of Ethics

A preferred purveyor of things that I appreciate has a great marketing slogan:

"In a World of Compromise, Some Don't."

Catchy. Cool. It still looks bold in the understated white lettering on the black coffee mug, and it's well-suited to leveraging their deserved reputation for high end, high quality products.

But in actual practice, adopting such a position across the board is darned difficult if not impossible to do. For most things, for most of us, we are forced to compromise at every twist and turn, creating an endless clash between the elusive ideal and cold sober reality. My wife swears I babble in my sleep about demand versus capacity and cost versus benefit; a veritable fit of tossing and turning, grinding of teeth as I wrestle with vexing business trade-off dilemmas of a nocturnal variety. Either that or it was something I ate.

So, on my way back to Austin as I write this at 27,000 ft. somewhere over Louisiana, I am reminded that the insulating solitude afforded by noise cancelling headphones comes at the cost of interesting and pleasant conversations that I used to have with fellow travelers. If it tastes good then it surely isn't good for you. If it's easy, it's probably wrong. If it's cheap then it's likely not worth the money. If one party wins, we fail to achieve a bipartisan solution.

So, when it comes to ethics, where does one draw that line in the sand between making sensible trade-offs and refusing to compromise? When balancing our portfolio of personal principles at work, what is negotiable on an individual level, and does that always match the same threshold as your employer or co-workers? What happens if there is a gap between those two? It is a Faustian quandary that dogs us our entire careers. Lean too far to one direction, the devil steals your soul; go to extremes the other way and you become paralyzed by self-righteousness.

I supported a sales meeting this week with a "high-visibility, high-value" prospect. I don't go out on these with great frequency, but am happy to lend a hand when asked. It was a one-day review of capabilities based on their pre-defined script. It's impossible to thoroughly investigate the entire scope of interest in that amount of time; inevitably, questions must be asked and answered in lieu of demonstrating every possible nook and cranny.

At that precise moment, when due diligence meets a presumption of honesty, the potential for ethical mischief emerges. In the heat of competitive battle with a possible large sale on the line, a simple question like, "Does your product do…?" puts personal as well as corporate values to the test. Such a situation tempts malicious compliance by providing terse one word answers that leave unstated assumptions hanging precariously, leaving it up to the prospect to probe deeper. When the ethical thing to do is to ask clarifying questions or voluntarily qualify your answer, furtive glances filled with trepidation fly from the rest of the team — no one likes venturing into a rat hole littered with potential issues that could furrow the brows of the selection team.

The concern does not arise from whether WE should do the right thing; if that was a real issue I would have left Planview a long time ago. We control our own moral compass as evidenced by a pet term that is common in our corporate lexicon: "wide open kimono". Goodness knows we aren't perfect and have our own small share of past judgment errors in the closet. But, we have matured from these experiences enough to realize that full disclosure, even if painful, is the best policy in the long run and have groomed our business operations accordingly.

No, the problem stems from growing doubt about whether the next vendor will do the same under similar circumstances. That is something outside of our control. How does one fairly compete while maintaining the ethical sextant pointed true north in an environment where fierce competitive pressures may cause others to say and do anything to win business?

Trust.

Just as we have to trust ourselves and each other, we have to trust you as potential customers to ask the hard questions of everyone you evaluate. We very much believe we have the smartest customers out there; smart enough to sense when they are being worked over. Smart enough to figure out if it's too cheap then it's likely not worth the money. So far it's working.

Bottom line, I sleep well at night — unless that 11:00 pm indiscretion with a leftover cannoli comes back to haunt me in the wee hours…

Next week is our annual Horizons North American User Group meeting here in Austin — Needless to say, we will all be very busy hosting our customers, so please forgive me if I do not get an entry posted until late next week — maybe I can try and relate the event to those who were unable to join us this year.

The ROI of PPM

I rue the day that someone (more likely a committee, no doubt) decided our airspace should be called Project Portfolio Management. I want to make a case for calling it WRPM — Work and Resource Portfolio Management. I think by now that most everyone has figured out that all of the work in the world is not comprised wholly and exclusively of projects. There are, in fact, other different kinds of work. Often times the costs of this other work far overshadows the money and effort required for the project portfolio.

Furthermore, you don't get very far doing work management without understanding and managing the motive force needed to get it done. Otherwise, you are basically daydreaming; "Gee, what I could do if only I won the Power Mega Million Lottery" sounds suspiciously like, "Gosh, I could meet that aggressive schedule if only I had some staff to actually do the work."

(As an aside, I would also suggest that WRPM also a much more fun acronym, as it conjures up the mental picture of "Wind up the RPMs"; an irresponsible act that brings great joy into my daily life.)

I am starting out with this basic premise as an important level set for talking about the true value of having an integrated view of all the work and resources in your organization. Specifically, what that is worth to you in hard dollars (or Euros, Drachma, or whatever).

Often times, we find ourselves helping prospective customers calculate the return on investment for acquiring a PPM product (that they will use for WRPM). The basis for this number often centers around hardware, software and process improvements directly associated with installing or using the application, such as consolidating the existing hodge-podge of disparate tools, reducing the amount of effort to produce reports, or time it takes execute certain processes. While there are several such direct elements that can be included when calculating the value of implementing a PPM solution, improving the ability of the organization to work more productively has such significant bottom-line contribution that it overshadows all other considerations combined.

This is important not only for purposes of estimating true return on investment, but also for the implications it has on the overall approach and potential success of the initiative. Fundamentally, a PPM implementation should be approached as a business improvement initiative that applies technology as part of the solution, rather than characterized as a "technology project". Placing productivity improvement in the forefront cultivates a more balanced and successful approach that addresses people, processes and technology in equal measure.

For organizations that currently do not have a comprehensive approach and toolset for enabling visibility into overall workload and workforce information, the potential for increasing organizational efficiency is worth millions of dollars a year. Here is why.

Resource effort is the critical raw material of knowledge worker environments. Because technology service providers are almost always in a position of having relatively fixed resource capacity to meet an excess of demand, the ability of an organization to increase the throughput of deliverables results in direct savings in the form of reduced need for external or supplementary staff, avoiding or deferring future staff increases, reducing the per capita cost per deliverable, and/or realizing the benefit of more deliverables sooner.

It is not unreasonable to expect increases of 15-35% in the ability of the organization to accomplish work, depending on the as-found state of the environment, tools and processes. Realizing this level of improvement usually requires that executives and managers also employ process and cultural changes, but the resulting payback is a compelling source of motivation. To put this in monetary terms, assume a nominal productivity increase of 20% and an average fully burdened FTE annual cost of $100,000. This means that the typical annual recurring savings per 100 staff is $2,000,000.00.

With the average customer looking for a solution to manage organizations ranging from a few hundred to several thousand workers, the annual cost/benefit ratio of this calculation ends any lingering doubts over whether the initial investment is worthwhile. If you are the pessimistic type and dubious that you can get much beyond a mediocre implementation, halve the efficiency increase to only 10% (that's only 4 hours per week per staff redirected to high value work); it is still a no-brainer.

But trust me, for most organizations, 20% is like falling off a log; I did it easily 13 years ago, when I was comparatively clueless about that I was doing.

The Innovation Multiplier

However, this calculation by itself does not fully reflect potential bottom line benefit. Innovation defines the ability of an organization to move forward by accomplishing work of high value to improve its overall business posture. Even small gains in the amount of effort spent on operational work can be reinvested into initiatives that transform and expand the business to further multiply savings.

Using a nominal IT spend ratio of 25% to innovation and 75% on current state operations as an example, a mere 5% reduction in operational costs re-applied to innovation nets a 20% increase in the ability of the organization to innovate. Time and effort spent on maintaining the status quo is inherently limited in its net value to the business. Redirecting capacity to engage in more business innovation has almost unlimited ability to contribute to the success of the enterprise.

The Source of Productivity Improvements

Where do these significant increases in productivity come from? There are several specific improvements enabled by integrated work and resource portfolio management, in combination with improved governance and a strong integrated business management process framework, which allows the implementing organization to become more focused, proactive and efficient. These include:

1. Improving alignment between strategic intent and the work being performed, which increases organizational focus to "do the most important work first"
2. Making consistent, informed and transparent decisions for resource utilization and financial spending improves business governance
3. Centralizing inbound requests to analyze total demand creates opportunities to consolidate compatible work, eliminate redundant or low-value requests and better manage the backlog
4. Establishing common priorities fosters a unified sense of purpose and improves collaboration between various matrix environment skill centers
5. Visibility into individual capacity versus assignments allows resources to be better directed using achievable weekly goals. This allows managers to hold staff accountable to target objectives and better control how time is utilized.
6. Use of a common real time data source and business application to manage work and resources ensures that everyone is working with a complete perspective of all the information needed to make decisions, as well as the necessary functions to revise and immediately communicate changes in plans
7. Reduction in the amount of work done in a reactive manner, along with the resulting number of efficiency-robbing stops and starts caused by excessive multi-tasking. Proactive work planning allows staff to focus on fewer assignments for longer time periods, enabling them to get into "the zone" of productive work more often.
8. Better visibility and understanding of how the organization really operates, allowing specific bottlenecks, roadblocks or inefficiencies to be identified and corrected
9. Improved ability to identify and adjust to business dynamics that impact work plans, allowing the organization to be more responsive to change influences

All of these improvements result in a more focused organization that is better able to manage and employ its resources. By being able to accurately measure how effort is currently being applied, immediate improvements can be instituted in staff utilization. Often times, significant increases in utilization can be achieved through a number of minor tactical changes rather than major sweeping modifications. For example, analyzing the amount of time spent in unproductive meetings or on unnecessary travel, finding repetitive functions that consume too much effort and need process improvements, locating pockets of under-utilized staff that can be redirected to more productive activities, or identifying tasks that represent a duplication of effort, are all examples of low hanging fruit that provide quick wins in how effort is used.

In addition to the direct benefits inherent in these improvements, they work in concert to improve the overall effectiveness of the workplace in other significant ways. For example, a common secondary benefit is lower staff turnover, especially in critical skill sets. By working more productively rather than longer hours, and by making better use of individual talents and skills directed to high value activities, workers feel more engaged and successful, and the organization gains self-confidence that stems from operating in a methodical manner at visibly higher levels of performance.

This is the ROI of PPM. You take the initiative, and we'll provide the expertise and tools.

Technology Addicted? Try Soft Skills Rehab

"I call that bold talk for a one-eyed fat man…"

As I prepare to write this, vaguely cognizant that this is a corporate blog for a software company, I am reminded of the above line from Robert Duvall in True Grit (1969) — just take this post as proof that we believe that technology is only part of the solution.

People, Process, Tools — let's talk, People.

(By the way, for all you out there that didn't catch this movie before it left the theaters — the aforementioned quote is not a really a line you want to toss out at John Wayne when he has a double barrel shotgun across his saddle; put this one on your must-watch list of Academy Award winners.)

In my last entry, the idea of "influencing without authority" was mentioned as one of the key capabilities that the PMO must have. A few days later, I'm trading emails with long-time colleague Patrick Boylan, the President and CEO at Intellilink; he was sharing how excited they were about their new offering, PeoplePM. It is a soft-skills development workshop for project managers, and response has been beyond their expectations. PeoplePM focuses on six critical PM attributes: Anticipation, Organization, Leadership, Communication, Pragmatism, and Empathy. Among the many fashion accessories a project manager must don, consider this to be the all-important mood ring. (But then, if you haven't seen True Grit, you probably aren't old enough to appreciate that line either.)

I'm not at all surprised that there is a big need out there for such support, but I am pleasantly surprised that the need is also perhaps finally — finally — maturing into a big market. To get from need to market, the need must first be recognized, and then be considered important enough to actually do something about it. The distance between those two points can make for a huge leap.

How huge?

Step One of Twelve: admit you have a problem and are powerless to fix it on your own.

So-far-gone-I-am-finally-dragging-myself-to-a-meeting huge.

Have things gotten into such a stupor on the humanistic side that technology drunkards are coming in off the street to sober up? Within Intellilink's explanation of their offering is this: "We decided to identify what really makes project managers successful."…" What we found was that it didn't matter if you had a sophisticated project management software system, or were utilizing the latest project management methodology . . . they don't hurt, it's just that something else was more important."

More important? How about as important?!

As I noted to Patrick, even though interpersonal and leadership skills are certainly appreciated, making the leap to actually invest in building them is perhaps one of the most under-served subject areas in the corporate training landscape. Yet, these are among most important skill sets to have in collaborative knowledge worker environments (hmmm, ya' think?). Maybe their response rate to PeoplePM signals a turn in the tide. One can only hope.

Looking over the role of the project manager and that of the PMO, both must certainly be adept at influencing others and plying the attributes listed above, except that, interestingly enough, oftentimes the project manager has more recognized authority than the PMO does! Assignment to a project team has a more tangible stickiness to it than being a member of 'the management team;' too many managers simply opt out of being active members of that club.

At the PMO forums, leadership, culture, and accountability always come up in our discussions, and they undoubtedly will still be hot topics at PMO forums on Mars a hundred years from now. Every generation must re-learn this as a foreign language subject, as it is not a native skill. So, I will end this with the same suggestion that I did in my 3-entry series on accountability from last August: it's perfectly OK for the PMO to take the initiative on setting up leadership training. I figure that if you weren't ready to act on that a year ago, maybe by now the need is more clearly recognized — to the point that its time to do something about it. By the way, sit in on the classes: the PMO staff needs the skills as much as the PMs!

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?

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…

The Resource Planning Horizon: Onward Through the Fog

Stop for a moment and think about how little in our lives we can catalog under the heading of "certainty". The 7-day weather forecast is a joke. Social Security is looking iffy, as is making significant gains in your retirement account this year. Marrying into both money and true love is highly unlikely, and even making it home tonight in one piece for dinner is somewhat questionable (especially if you have to get on I-35).

My operational definition of certainty is "probability of fact beyond a reasonable doubt." We can pretty much skip the category altogether with respect to our jobs, organizations and all things work-related. In this day and age of the CEO du' jour, mergers, buyouts, takeovers, restructuring, layoffs, spin-offs, economic volatility, the cost of oil, political ambiguity and technological leapfrogging, things have become a tad bit ADD in the business realm. Our president and COO Greg Gilmore is prone to describe the situation by injecting, "Look, there's a chicken!" into the middle of a conversation gone awry.

On a more tactical level, daily life in the PMO is fraught with bugaboos and things that go bump in the night; vexing pixies, mischievous leprechauns and other apparitions inject uncertainty into the presumed order of things. Oh, I dunno, stuff such as key staff vaporizing into new jobs, or the boss coming down with the latest "must-do immediately" initiative. Things like finding out that the hardware ordered last month for that big global ERP implementation isn't actually ordered yet, or that there is a calculation error in the interface program that does month-end reports — and that it's been there for 28 months. By the way, the internet is down due to a com failure in Prague.

Despite this, we still have to deal with those who insist upon certainty when it comes to things such as distant milestones, initial resource estimates, and Rev. 0 baselines — probably the same folks who declared that latest initiative as "must-do immediately" with nary a glance at the consequences.

To manage expectations about certainty in the planning process, I like to use the analogy of driving through fog. Organizations, their missions, and their projects are akin to vehicles on an ongoing journey, and to manage them is to be in the driver's seat. On a macro level, we can clearly define the next intended destination, do a reasonable job of understanding our current location, and plot a general path to get there.

But, in the here-and-now of our travels, we can't always see as far down the road before us as we might like. While we can encounter refreshing (and all too brief) periods of clear skies on our quest, more often than not our visibility is limited by the fog of the unknown. The further out we look, the more fuzzy things become until finally we reach the operational limit of being able to visualize and counter obstacles in our way. At that point, we have to accept that we can no longer anticipate what lies ahead with certainty, and adjust our driving accordingly.

The operative word here is "acceptance". If the reality of a given situation is that we are dealing with copious amounts of uncertainty that causes variability in our plans, then to ignore that fact is to be unrealistic — or put more bluntly, to be in denial. Banging fists on the table and demanding that a schedule "not move" is akin to cursing the wind for blowing.

In part 2 of the PMO 2.0 whitepaper series, I briefly describe the Planning Horizon. It's also on my short list of topics whenever presenting key concepts for integrated work and workforce management, and the subject can be found as Best Practice MIC-08 in our PRISMS Management Integration Center Guide. To get to the essence of the planning horizon concept, it is all about understanding that tipping point in your plans and forecasts where projections exceed the probability of being at least half-right, and conditioning yourself not to go beyond it.

Because if you aren't at least half-right, then you are mostly wrong.

This is a critical point. If you put bad information into your planning system, someone will see it, believe it, and try to make decisions based on it. No data is better than incorrect data. One could argue that knowingly putting in information that is probably incorrect is a malicious act.

But that doesn't mean you can't or shouldn't plan well in advance; it's just a question of how much detail you provide. The outer limit of the planning horizon shifts based on the level of planning granularity employed. For example, you could probably feel good that the approved project list for a strategic portfolio will still contain at least half of those items 18-24 months from now. You can likely plan a major project at the phase level 6-to-12 months in advance and be generally correct in your assumptions. And, as far as planning out what specific work activities are going to be done, you should be able to produce a reasonable rolling 12 week plan.

Over the years, I have always taken the opportunity to ask first line managers how far forward they can plan on a named individual actually accomplishing a particular assignment within a one-week window of time. The vast majority answer, "three to six weeks, max."

In my past life, I used to facilitate a "Five Year Strategic Plan". Things got really sparse after the first two years, and there was nothing in it out past year three. The absence of information spoke volumes — it was an admission that we didn't have any idea what was over that 36-month horizon. To plan that far out these days requires pentagrams, Ouija Boards and bleached chicken bones.

Violation of the planning horizon is one of the most common errors that I encounter when conducting assistance visits. It is a hard habit to break, driven by our lust for certainty and short memories for historical performance. Addiction to long range planning often forces the PMO to be complicit in a futile exercise that generates bad information and dilutes the veracity of planning information in general. Once dubious information is allowed into the planning system it can create doubts about the validity of the entire pool of data when it is discovered. I would much rather see that energy put into better planning those things that can be reliably managed in the near- and mid-term, rather than stretching questionable prognostications past the breaking point. The result would be a more accurate portrayal of that which we know, as well as a healthy admission of that which we do not.

So, be zealous guards of the planning horizon and enthusiastic about having others do the same — confidently and completely plan as far forward as you can, but respect the point where you have reached your practical limit.

I like to characterize to the whole uncertainty element under the heading of "business dynamics", which sounds so much more professional than "I haven't a clue". This whole line of reasoning is not intended to be a convenient and plausible excuse for why dates are missed, but rather to foster recognition that "stuff happens". What really matters is not so much the happening itself, but rather our keen awareness of it and active response to it. To accept our dynamics as reality and adjust our thinking to it is to create a nimble environment that is comfortable on the balls of its feet, able to deftly respond to whatever is thrown at it.