Enterprise Navigator

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.

Elevate Your Thinking -- Managing Beyond Projects

Some technology organizations have become so numb to project failure that they have fallen into collective indifference about crappy project execution of crappy ideas, and utterly complacent to the impacts that such an attitude wreaks across the enterprise. Any report on the success rate of technology projects will back up the fact that this is a commonplace situation. I've been recently incorporating into my presentations some information from a Hackett Group study, "Core Competencies of Financial Top performers: Managing the Business Value of IT". Every time I see those numbers I am again reminded of the disparity between the top performers versus the norm and it really infuriates me — there's just no reason for so many organizations to have such mediocre project performance.

For anyone that has attended one of our PMO 2.0 Leadership Forums or heard one of my presentations lately, you know that I am a strong advocate of ensuring that projects are always placed into 1) proper perspective, and 2) business context. Both of these help combat project portfolio lethargy.

First is proper perspective. Recognize that a project itself has no inherent business value. In fact, worse than simply being neutral, it is a massive negative drag on the organization, by virtue of it also costing time, money and resources. Projects consume an inordinate amount of managerial oversight, invite considerable risk and greatly distract from otherwise normal operations.

Whoa, them's fightin' words. Remember the Alamo, and Annie Get your Gun!

But it is true. From the moment it is conceived until the day it is finished, a project is a worthless, costly disruption, and too few ever amount to anything else. Every year a huge amount of energy goes into analyzing and estimating proposed projects that end up getting tossed aside like a crate of salmonella-laden tomatoes. Still others may make it through initial funding and design, only to never get the green light for development. Finally, too many projects that run to completion never adequately fulfill the promise offered in their charters. Projects fight a war of attrition at every step along their treacherous journey towards delivering potential value.

Fortunately, a project does have a chance to make amends, but only posthumously. A project runs a long gauntlet of potential mishaps and hurdles to actually provide deliverables that generate substantially more business benefit than it cost to create them. Only then can we can finally look back on it and attach some modicum of redeeming merit. "On time and under budget" may reflect tactical ability to manage projects, but they are meaningless measures when it comes to whether business value was reaped from the results.

That perspective leads us to placing projects into business context. Given that projects themselves hold no intrinsic business value, what are they good for? They are transformation mechanisms. Projects give us the vehicle for changing the status quo of our products or services. That's it. They can either create or modify a product or service, or some combination of the two. End, period, next.

By adopting this point of view, we approach the decision to pursue and execute projects relative to the bigger, value-based picture. If you manage your environment from the vantage point of analyzing and understanding your current portfolio of products and services relative to their contribution to the goals and objectives of the organization, then you elevate your thinking to whether products and services must be transformed, and what is to be achieved. By concentrating on the lifecycle of existing products and services relative to strategic imperatives, the process of identifying, analyzing and making go-forward decisions on projects is accomplished with a sharp focus on outcomes.

This linkage must be articulated and maintained throughout the life of the endeavor, or you run the risk of perceiving project portfolios as disconnected entities. And, by life of the endeavor, I mean achievement of intent — delivery of business value. Once a project (or portfolio of projects) becomes decoupled from business outcomes, it invites a gambling hall mentality where a certain expectation of routine failure is allowed to incubate. Attitudes about projects become more of a game of chance, where a roll of the dice dictates whether you will lose or win, rather than viewing each and every one as critical investment that must be carefully considered and nurtured to further organizational missions. That's not to suggest that you become so conservative that you quit taking risks, but you should be deliberate and methodical about what the risk-reward scenario is at a business level, and make a conscious effort to stack the deck in your favor to minimize attrition.

Project deliverables must also remain tightly coupled with business outcomes to ensure effective follow through after the project itself ends. These outcomes may take weeks or months to emerge, so it is critical that a mechanism is in place to continue to move the effort forward into an operational state. See my post on Benefit Management.

So, the next time you initiate, evaluate, fund or execute a project, remember that it's only value is as a transformation agent applied to products and services, and that change comes at a considerable cost. Then think about why you need the transformation, the intended outcome that is to be achieved, and remove failure as a regularly acceptable option within the collective project management culture.

---------------------------------------- cut here ----------------------------------------

OK folks, glad I got that off my chest; I feel better. Print this entry out, snip along the line above, and attach it to the agenda for the next quarterly meeting of the steering committee. I bet you a beer that proposals on the docket receive a reinvigorated dose of discussion and scrutiny.

Same Latitude, Different Attitudes -- The Charlotte and Los Angeles PMO 2.0 Leadership Forums

I know I went a little quiet again. I'm on this City of the Week diet, to see if I can lose weight by just eating little bowls of warm nuts at high altitude.

It isn't working, so I'm going for a fresh baked baguette and tureen of truffled, fricasseed something in Montreal Monday evening (or, a burger). For those of you in the area, feel free to recommend a nice restaurant downtown, as well as come to the "Surviving the Best Practice Jungle — An IT Executives Field Guide" seminar, sponsored by KOAN-IT on Tuesday morning. Tim Stratton of KOAN-IT and I will be clearing a path forward for you, hacking our way through the thorny vines, hidden tiger pits and the moss-laden slippery slopes that dot this particularly treacherous landscape.

Back to the topic at hand, before I digress any further.

So, we held our 8th PMO 2.0 Leadership Forum in Charlotte on June 4th, and followed that up with the LA event on the 10th. I found it interesting to note that while these two cities differ by only two degrees of latitude, they are about 2,430 miles apart when it comes to the vibe. Southern Hospitality meets Malibu. Nonetheless, both forums proved to be interesting and interactive, with great presenters, panelists, attendees and topics.

Dan DudekI must publicly thank Dan Dudek for stepping in at the last minute to present in Charlotte (along with Dan and Jeanette's hospitality at their lake house). Our scheduled featured presenter had an emergency come up just prior to the event, so I shamelessly pressed Dan to fill in with less than 48 hours notice.

Dan is the president of Optimum Technologies, and was my Planview consultant almost 13 years ago when I was just taking the reins of the engineering work management group (a.k.a., PMO) at the utility I was at. As I mentioned at the forum, we each have a short list of people that, in retrospect, have had a profound impact on our career trajectory. Dan is certainly on my list, as he patiently reset my thinking from managing reliability programs and plant outages to managing knowledge workers.

Joining Dan on the expert panel (with yours truly at the podium) was (from the left, seated) Greg Cimmarrusti with Hitachi Consulting, Susan Steagall of Novant Health, and Christie Soper from Lincoln Financial. The attendees wasted no time in taking advantage of this significant amount of PMO expertise, with insightful questions and discussion.

Some of the Charlotte attendees

On to The City of Angels. Unlike the warm, sultry North Carolina weather, LA greeted us the following Monday with low clouds and a cool breeze off the Pacific. Actually, with my blood thinned out from a triple-digit Texas weekend, I was freezing my tail off while all the SoCal locals seemed comfortable in their board shorts and sandals. Happily, we got enough sun on Tuesday to take the chill off.

Sue Burgess of Early Warning came over from Phoenix to share her PMO story. Pretty amazing what she has been able to do in a few short years, from formalizing the project management discipline and governance model, to managing the technology portfolio integral to the needs of the business. It just goes to show you what can be done with strong leadership, teamwork and executive support.

Of particular interest was how Early Warning balances and manages their IT portfolio into strategic, informational, transactional, and infrastructure asset classes relative to risk and return. Sue freely credits this approach to what she picked up at the Sloan School of Business Management and the MIT Center for Information Systems Research — honestly, when was the last time you saw someone effectively apply their higher education in actual practice?! Way to go, Sue.

Jeff, Sue and FredFred Maxie and Jeff Paradowski joined Sue for the interactive discussion with forum participants. Fred is an independent consultant that has been working with us and our customers for several years now, so it was a pleasure to catch up with him. Jeff is a vice president with Hitachi Consulting, providing communications and content solutions for the media and entertainment industry. Together, they offered a diverse, yet formidable amount of expertise for us to draw upon.

We certainly learned some things about the area from this event as well. First off, given the size of the population, we expected a bigger turnout (the Charlotte forum had more attendees).

Also surprisingly, there were hardly any tech folks in the audience; most were from the 'business' side and product management — definitely a demographic shift from most of our other events, that also showed in the discussions we had. Granted, no one cites LA as a hotbed of technology, while everyone is aware of Charlotte's Web.

Ooh.

Alright, so what is next for the forum series? As we approach summer, we will take a planned break for a while since everyone will be off doing their vacation thing (self included). We have New Jersey and Seattle on the docket for later in the year, but like any responsive organization, we are "analyzing some mid-season adjustments to dynamically manage our PMO forum portfolio". In other words, if we change our mind, we will let you know.

Don't forget about a restaurant recommendation for Montreal…somewhere in the H3B neighborhood.

Communicating Best Practices -- Lessons Learned from a Stealth Bomber

For want of a nail the shoe was lost.
For want of a shoe the horse was lost.
For want of a horse the rider was lost.
For want of a rider the battle was lost.
For want of a battle the kingdom was lost.
And all for the want of a horseshoe nail.
— 14th Century Proverb

Have you taken the time to adequately document and disseminate your processes, procedures and policies? This effort is probably one of the most important but weakly executed steps when developing or improving processes. Why is this so often inadequately done? Because it is a grueling exercise to first develop the documentation, then train everyone, and maintain the body of knowledge current and relevant as an ongoing effort.

So what is at stake? Consider the crash of the Spirit of Kansas B-2 Stealth Bomber crash on Guam in February, which is in the news again because the cause of the crash has been discovered. For want of a known procedure for removing moisture from avionics sensors being incorporated into maintenance and operations manuals, a $1.4 BILLION dollar aircraft drilled itself into Andersen Airfield upon take-off (the pilots ejected safely). According to the crash assessment report, "This technique was never formalized in a technical order change or captured in 'lessons learned' reports. Hence, only some pilots and some maintenance technicians knew of the suggestion."

Our own need to codify our accumulated best practices and intellectual property in written form so that we did not have to rely solely on passing tribal knowledge around was the genesis for developing the Planview PRISMS Best Practice Guides. An important point illustrated by both the cause of the B2 crash as well as our own efforts with PRISMS is that documenting best practices is a journey, not a destination.

Changing needs, new discoveries, and increases in maturity all point out the need for an iterative approach when it comes to managing the knowledge base. For example, when we first started PRISMS, it was a small single guide. The next version was a much larger single guide. Eventually, it became a library of guidance, and today it contains over 850 pages of content across a dozen different topics. The library continues to grow, but it will never be finished. So it goes with any similar documentation effort.

The good news is that today’s technology enables a high degree of collaboration when it comes to individual ability to contribute to a common brain trust. Taking a wiki approach where inputs and updates are submitted by all stakeholders, and then moderated or edited by an assigned subject matter expert, opens up whole new vistas in how best practices can be created and maintained.

The important thing is that the collective knowledge of the organization be codified and shared — for knowledge worker environments, it is the most precious asset you have. Otherwise, you too may crash and burn.

For want of a best practice the project was lost.
For want of a project the program was lost.
For want of a program, the strategy was lost.
For want of a strategy, competitive advantage was lost.
For want of competitive advantage the business was lost.
And all for the want of a best practice.
— 21st Century Proverb

Gaining Insight: Interactive Analytics from PPM

Any PMO manager knows that it's all about the outputs.

Of all parts of the organization, the PMO is uniquely situated to have the right combination of organizational positioning, skills, access, familiarity and capability to render all that data into useful management information. And, once business information is distilled by analysis, you can then define what information requires action as opposed to monitoring.

Once the rest of the office begins to clear out and the fog of the crisis du jour lifts, the real work begins for the PMO. Every week is like working a Sunday paper crossword puzzle or sleuthing a whodunit; all that data is trying to tell you something — something important, but what is it?

Inputs are easy enough (OK, relatively speaking anyway). Perhaps the world's easiest platform for inputting data is a spreadsheet. Bangity-tab, bangity-tab, bangity-tab, and it's in there. And, if all you have is simple data and simple needs, the chart wizard will gladly oblige you with easy outputs too. But somewhere out past a handful of data attributes, dynamic data sets, and the need for accessibility and collaboration by many different individuals requiring different views, the whole spreadsheet approach goes to hell, no matter how good your file links and pivot tables are. Easy gets hard. And wrong.

The next thing you know, you are on the hunt for new tools. But historically, planning platforms (regardless of the logo) have been much better at collecting information than they were at giving it up, especially when the ability to 'customize by configuration' emerged as part of becoming web-based; canned reports were limited to the basic configuration and data elements that were pre-defined. Back in my PMO days we were using Crystal Reports; it took a lot of SQL and inside and outside joins to get custom reports out, and they were about as sexy as a dirt clod.

Of course, I didn't write the reports — that's why I had Tommy Five Hairs (back then he was still Just Tom). Tom got really good at wrenching data out of the many tables and presenting it in a usable format, primarily because I pestered the daylights out of him for an endless array of reports. So naturally, when I came here, it took a year but I finally coerced him to follow. We had a lot of nicknames in consulting, like Obi-Wan and FuFu. You'll have to ask those present at the time how Tom earned each of those five hairs, but "T5H" has been our ace consultant custom report guru here at Planview for many years now.

But I digress.

So, if you've been following these pages at all, you know by now that as a corporate blog for a software company, I don't spend too much time chatting up the products. I figure we have lots of sales people and marketing collateral doing that, so I'd rather spend time discussing other things. But, I have to say that I sure wish I had our latest offering back in the day when we were solving various management riddles.

Last week we launched Insight Analytics as the latest addition to the Planview Enterprise family. It is a very powerful, easy-to-use OLAP platform based on SharePoint and Microsoft Analytics with beautiful graphics. Before you dismiss that last point as a vendor pushing eye-candy, let me just say that a good graph can make something obvious that might be otherwise overlooked in an endless column of numbers.

We have been using Business Objects in conjunction with our own datamart and universe as our main battle tool for reporting for several years now, and will continue to do so, but Insight adds an additional dimension to our reporting repertoire.

One of its many advantages, especially for larger customers, is that it is wicked fast to refresh the cube — Insight runs the largest test databases we have in a matter of minutes, so it becomes feasible to run data refreshes several times a day for near-real-time analytics.

Another feature I like is its distribution capability. Because it is based on a Microsoft platform, you can publish reports straight to an Outlook folder or seamlessly dump them to Excel for further manipulations.

But, back to the outputs — those wonderful "ah-hah!" analytical moments aren't much good unless you can convincingly relate the story to those who need to take action. That's where Insight Analytics really shines. You can start at a high level metric or dashboard with a particular issue, and walk people through to the root cause with drill-by-click capability, while making side trips as needed based on how you choose to combine data elements; very slick.

Anyway, after living through the total technological transformation of our products a few times over, I don't usually get overly excited about incremental software changes, but this is genuinely cool. It's like a Tom-in-the-Box. Simply grab the cube, turn the crank on the side a few times as the funky music plays, and Bingo! Out pops an analytical revelation.