Enterprise Navigator

While going through my innumerable files in preparation for our recent office move, I came across an old copy of Murphy's Laws of Combat (don't ask), which lists any number of axioms gleaned from various skirmishes over the years.

As I reacquainted myself with their wisdom, it struck me that sometimes managing a PMO can seem like a battle as well, as you try to win over the hearts and minds of the organization. What follows are corollaries to a handful of these laws for your consideration.

"You are not Superman or Rambo."

In much the same way that you do not really have the uncanny ability to stand out in the open unscathed during a raging battle, the inspirational case study provided by the seminar speaker will be much harder to replicate in actual practice than the session might suggest. Conspicuously absent from most such presentations are the multitude of conflicts, sharp glares and bruised careers that just go along with these initiatives.

"If the enemy is in range, so are you," along with the popular "Tracers work both ways."

Always remember that when using facts and figures to sway opinion or present a case for action, anticipate that that someone will retort with equally convincing and contradictory analysis or data. This also brings to mind, "Liars figure and figures lie."

"Anything you do, including nothing, can get you shot."

This little rule is useful to illustrate how vulnerable most PMOs are within organizations; see chapter 16 of Taming Change for more about that subject. Overachieving can get you shot. Trying and failing can get you shot. But, without question, doing nothing is the fastest way to get shot; snipers love a stationary target. Hardened warriors will tell you that the best way to survive is to keep moving towards your objective without drawing attention to yourself.

"When in doubt, empty the magazine."

When faced with a problem, it is better to attack the issue with all of the energy you can muster, rather than timidly 'almost' resolve it with incremental actions.

"There is always a way -- and the easy way is mined."

This law is a close cousin of, "If it seems too good to be true…" Be suspicious of those who are too quick to agree to your requests; chances are they are simply trying to get you out of their office, with little or no intention of actually taking action. Worse yet, they could be preparing a counter-insurgency.

"Important things are very simple, and simple things are always hard."

This speaks specifically to the need to build a strong but basic foundation of processes, measures and accountability. This is an important and simple, yet very challenging thing to accomplish.

"If it's stupid but it works, it isn't stupid."

'Nuf said.

"Never forget that your weapon was made by the lowest bidder."

Despite what the selection committee for a new supporting system might recommend, all bets are off once the procurement and contract folks go to work.

"No inspection-ready unit passed combat" and, "No combat ready unit passed inspection."

Worry less about standards and certifications and more about practical application.

"No battle plan survives first contact with the enemy."

If I had a nickel for every time I have used this quote over the years, I would be retired in the Keys. Always stay flexible with your improvement initiatives; apply the Marine approach of adapt and improvise. This also means you have to be vigilant to situational dynamics. To blindly follow a plan come hell or high water is to march right into an ambush. This is further supported by this law: "The enemy diversion you are ignoring is the main attack." Listen to opposing viewpoints! Which leads us to:

"If it's too tough for the enemy to get in, you can't get out."

OK, so your constituents aren't the enemy; but this law speaks volumes about the importance of open, bi-directional lines of communication. Too often PMOs become the organizational equivalent of walled fortresses instead of remembering they are a service provider.

And last, but not least, one final law and universal law to always bear in mind; "Professionals are predictable; it's amateurs who are dangerous."

For as long as there have been project managers, there has been the issue of where they should be on the organization chart, and why. In particular, the question routinely arises about whether it is a good idea for project managers to report to the PMO, and if so, to what degree?

This subject is revisited in a short paper recently released by Gartner and written by Audrey Apfel; "Q&A: Should Project Managers Be Inside or Outside the PMO?" (G00175471, dated 8 April, 2010). It contains a few pages of thoughtful response in the form of the advantages and disadvantages of various reporting models, which I won't repeat here. Bottom line, Audrey suggests a decentralized model makes the most of project manager skills and to spread the practice (…and furthermore, she adds that even though a decentralized model is hard to manage, the PMs are likely already so embedded in other departmental activities that it is even harder to change).

If you are expecting a different or more definitive answer from me, well, probably not so much. But, it is an interesting topic worthy of further cogitation. I have gotten the sense over the years that many organizations have not put a lot of concentrated thought and planning into the subject; it just sort of ends up being a certain way based on where the formal project manager role was originally created.

For example, in IT, it is a common practice for many project managers to report to Application Development. Now, this is fine for the actual development part of a software project, but what about those phases that happen before and afterwards? Hmmm, does this possibly have any bearing on whether business requirements are nailed down tight, or if adequate focus is placed on successful deployment of a new solution? If most of your project managers do indeed come from App Dev, what will the Agile revolution do to the number of PMs in the organization in the long run?

Furthermore, do you really want your PM to come from App Dev when you are facing a process improvement project, implementing a procured asset, or some other initiative that doesn't involve cutting code? I know, I know -- if the PM is good, theoretically it shouldn't really matter, but let's face it, we are products of our environments. Then there is also the inherent reluctance of the App Dev manager to cough up resources for projects outside of his or her interests.

Taking this a step further, how many projects are done primarily within the confines of a single department versus drawing significant resources from across several groups? Does it make sense that the majority of project managers reside in technology groups when the majority of projects are requested by other parts of the organization to implement business improvements? I'm just asking.

Of course, having project managers report directly to the PMO presents its own set of dilemmas. It is after all, a bit of a "fox in the hen house" situation, in that the ability of the PMO to provide oversight and accountability becomes a bit tricky.

(Reading this so far, it is getting a bit too Andy Rooney-like for comfort; can't you just picture him, hands folded on the desk, reciting this in that whiney voice?).

But, I've had pretty good luck with centralization of service staff over the years. So, cultural idiosyncrasies notwithstanding, if I were to design an approach, I might be inclined to centralize most PMs who support routine projects within something akin to the latticed PMO structure as described by Margo Visitacion of Forrester. This would keep them close to the departmental action to still retain the advantages of a decentralized model that Audrey points out, while also countering many of its disadvantages. I would then give those project managers a career path to become Senior PMs, who report to the EPMO and manage the big strategic projects or those that involve multiple lines of business -- if I were to design an approach, that is (and of course, I'm not). And, just to show you the influence that Mr. Perry has had on me, let me quickly say that I am only talking about 'formal' PMs in a so designated full-time role, not the myriad informal/accidental/part-time project managers that spring up in organizations like the crabgrass in my backyard. The PMO (and PMs) should give them assistance and love whenever they can (the informal PMs, not the crabgrass -- it gets NO love).

Still imperfect, but I'm just trying to have my cake and eat it too. I love cake. Just ask my family; I'm a fool for cake. Mmmmm, cake.

Remember the Binary Day post from November of last year? Well, I just checked the market (DJIA) and it was at 11011.11 -- go figure.

We don't spend an inordinate amount of time here discussing multiple PMO situations, so this post is dedicated to the topic. Those of you who attended (or saw the on-demand version) of "The PMO in 2010 and Beyond" Webcast may recall a discussion we had about 'latticed PMO structures' with our esteemed guest, Margo Visitacion of Forrester. Well, Margo just released her research paper on the subject, dated April 9, 2010 and titled, "The Next-Generation PMO: The Latticed Model Enhances Enterprise IT Visibility."

Suburbanites who have fishbowl backyards are already familiar with the use of lattice. You can use it to create a sense of intimacy and personal space around decks, porches, or hot tubs. Whether it is in form the stapled redwood variety or of the more recent molded plastic type, lattice serves to define an area and add some privacy, while still communicating part of the view, breeze and sounds of your surroundings.

In some respects, this relates to the concept of the latticed PMO model for multi-PMO situations. Margo is quick to point out it is not hierarchical in form, but rather a more loosely defined consortium of multiple PMOs that work together as needed. A key concept is that smaller, departmental PMOs have enough autonomy to provide on-the-ground services to their constituents; this fits well with my personal PMO mantra of 'global alignment, local support.'

As Margo answered during the Webcast, a latticed PMO model is not mutually exclusive of using an Enterprise PMO; it's more a matter of how the EPMO influences the other PMOs of the organization, and to what degree. Since the other, more localized PMOs do not report to the EPMO, the relationship becomes more advisory, and the local PMOs have more flexibility and freedom to focus on those they serve, rather than being skewed towards primarily taking commands from the mothership.

The idea of a PMO model as Margo explains it is probably more reflective of common multi-PMO environments than one might think. Surveys usually show that a healthy percentage of organizations have PMOs that operate in such a manner. Our 2008 PMO 2.0 survey reflected that 10% of respondents were in a multiple PMO environment that were functionally aligned, while another 24% indicated their multi-PMOs were largely independent. This compares to only 12% who indicated their PMOs were using a federated model (54% of respondents were in single PMO situations).

I wouldn't be surprised to find that, upon closer examination of the PMOs in the functional and independent categories, many of them would really be collaborating in ways similar to what Margo describes. If you are a PMO in a multi-PMO environment and you don't collaborate with the PMOs in other departments at all, well, I'd suggest you may have some serious silo issues -- not to mention a large missed opportunity.

So, for all of you PMOs that fit this model, now you have a name for yourself. Yet one more term to help enrich our colorful and somewhat daunting language of business.

BTW, I'd be remiss if I didn't also mention that Margo also reiterates in this paper the importance of modern PMOs to expand their interests and areas of focus -- Oh yeah.

Finally, we are taking our Webcast series international next week -- I'll be having a discussion with Patrick LeRoy of Allianz France and how they approached the challenge of managing the many demands placed upon their organization. Although this event is primarily directed towards Europe, my French is a little rusty (as in non-existent) so we will be presenting in English. With that and the timing of the event, there is no reason why those in North America shouldn't join us on the Webcast as well if you like. The Webcast will take place Tuesday, April 20th at 4:00 pm CEST / 9:00 am Central US / 10:00 am Eastern US. Register here for the Allianz France Webcast for the Webcast.

Sometimes it seems we move so fast in different directions that it's a wonder why organizations don't just fly apart.

Not literally, like the Big Bang theory, with people being physically ejected from the building at various odd angles, but rather in terms of striving to maintain a unified sense of purpose between individuals in teams, groups and departments. Like the difference between whether atoms just exist as bits of individual elements or combine to form molecules. Or, whether those molecules simply drift about in Brownian motion; whether they are within a colloidal suspension or take a more cohesive form. If they do, can the resulting compound be molded into something of value?

A common sense of purpose is what distinguishes an organization from a random mass of people. How we maintain a sticky operational binding in the face of change has been a recurring theme in a couple of public forums the last few days.

The first one was the webcast we did with Margo Visitacion of Forrester Research last Wednesday, around the topic of "The PMO in 2010 and Beyond." (By the way, even if you are not one of the more than 1500 people who originally registered for this event, you can still access the on-demand version.)

For those who attended the event, you know that the idea of looking to the PMO more often as a unifying force across organizational boundaries was a core aspect of the discussion. PMOs provide some of the organizational gravity needed to counter the momentum of various groups moving in different directions.

The next day I taped a discussion with Mark Perry as part of his delightful PMO Podcast series, to help introduce the Enterprise Management Association - International. If you listen to it (#180), you will hear Mark recount his experience at a recent Agile conference, which serves as an excellent example of how easily operational momentum can run amok and disrupt the balance wobble of things in general.

All of this just serves to illustrate that our workplace is simultaneously a resilient yet fragile environment. While nature has only four forces to contend with, organizations are subject to a host of competing influences -- politics, personalities, economics, cultures, compartmentalization, preferences and prejudices to name but a few. The only question becomes whether they are forces that bind us together or try to pull us apart.

Someone recently shared an interesting report from National Public Radio regarding the recent NASA budget hearings on Capitol Hill. Included in it was this fascinating exchange between Senator David Vitter of Louisiana and NASA administrator Charles Bolden:

"Somebody once told me a vision without resources is a hallucination," said Bolden. "If you look at where we were prior to the 2011 budget, we were living a hallucination."

But Vitter didn't find that convincing. "If vision without resources is a hallucination," he said, "resources without vision is a waste of time and money. And that's what I think this budget represents."

No doubt some version of this discussion is routinely re-enacted in board rooms around the world. Operational planning is all about enabling your vision. But, it is predicated upon a big assumption -- to be useful, that vision needs to represent getting to some future place as an organization. Too often, this basic premise can be a challenge.

Sure, someone may indeed have a grand plan, but does it constitute a clear destination or simply a loosely defined continuation of the journey? Consider a family trip to further illustrate the point:

"Come on kids, hop in the car!" "Where are we going Daddy?" "West. We're going west… and maybe a little north. Our goal is to get at least 25 miles per gallon, and to cover 500 miles a day." "But where are we GOING?" "Ah, don't worry about that, we'll know when we get there. The key is to make progress and get there efficiently."

In the case of NASA, it is a matter of convincingly defining its future objectives and strategies in the post-shuttle era as an inherent aspect of acquiring funding. The Constellation program had set its sights as returning to the Moon, but was under-funded. Now, Bolden is hinting towards Mars, but even he concedes he isn't sure how we will get there or what it will take.

For a corporation, such reconciliation is usually more pragmatic. In addition to being able to articulate in actionable terms where you want to be in 3, 5 or 7 years, you also have to assess if you can practically get there. It's all about defining your markets, producing the right products, and managing your capacities.

So, the key take-away is to make sure your operational planning process sets clear objectives, defines achievable strategy and allocates the needed funding and resources. Make it tangible; explain it in terms that establish why you would want to go there, and how it will be done. Then you can percolate it through the ranks to truly make your vision a commonly shared goal, and not just some hallucination.

I have never written a line of code in my life and have no intention of starting now -- but I have a lot of room for agile planning techniques. You should too if you don't already because agile is going to quickly reach epidemic proportions well beyond the borders of IT. We should name this the C1B1 virus, because soon enough, transmission will be by mere line-of-sight.

If you think agile planning is just about software, then you're not paying enough attention. Sure, "Agile with a capital A" has structured the concept into various methodologies specific to software development. But, I can safely say that adopting "agile with a small a" is becoming equally inescapable in other disciplines.

Once you cut through the lexicon of sprints, velocity, burn down and scrum masters, the basis for agile is rooted in what many of us have been getting in trouble for doing for years, regardless of the type of project: banding together and collaborating to iteratively arrive at incremental solutions -- despite what the waterfall or contract said. "Hey, you can't work on that activity yet, the predecessor isn't finished!"

Yeah, right.

Perhaps such indiscretions were driven by the realization that the CPM schedule just couldn't keep up. Maybe you went rogue every once in a while in the interest of just cutting through the bureaucracy. Now it's time for you rebels to come out into the light. It has a name. It's mainstream. No longer must you suffer the hot sting of shame and guilt for being practical.

But why?

If you came here via our website then you may have noticed our updated theme of "The New Normal." It is about recognizing, accepting and even embracing the uncertain and volatile operating environment that we now face. Life was fast in 2008 -- then we added record uncertainty. Now we find ourselves at a point where, although hopeful, few are willing to plan or forecast anything with much range or conviction.

The new normal demands that we incorporate an unprecedented degree of flexibility into every level of the planning process, from operational strategy to individual assignments. Do we still make assumptions, set goals and define objectives? Sure. Should we still frame out a project plan? We'd be crazy not to. Nor are accountability or performance measures going away. But the new normal suggests that you need not feel compelled to fall on the sword of the rev. 0 schedule. The race now goes to the nimble -- those who can adjust and adapt for the sake of adding value.

No matter your level in the organization or what you are managing, build in flexibility, expect the unexpected; work fast and lean. Be agile -- it's the new normal and it changes everything.

Here is a link to a good article by the ever-prolific and thoughtful Linda Tucci, for SearchCIO: Tactical decisions outweighed IT strategic planning for CIOs in 2009. In addition to being a well-written piece, it contains some numbers you can add to your list of informal benchmarks. The gist of the article is likely no big surprise; 'when money gets tight, you curtail discretionary spend.' It's like reducing the number of Friday movie nights at the Super 14 Cinemaplex, in favor of more DVD rentals and a bag of Pop-Secret when you tighten the household belt.

What this article illustrates however, is the importance of being able to see and respond to changes as they surface, not just for the CIO, but across the whole organization. So, what role should the PMO play in maintaining situational awareness? I contend that the PMO has a unique vantage point that allows it to spot certain emerging changes that others may not be able to see.

As a part of the organization that is usually sandwiched between the executive and working levels, the PMO is well-positioned to identify and alleviate disconnects between the two. The PMO also operates across organizational silos, enabling it to identify coordination issues between groups or departments. The PMO is also usually the broker of performance information; as a result, its analysis should be the first line of defense in identifying emerging trends.

Going back to Linda's story, the PMO also plays a significant role in how the organization responds to changes; deciding to pull back on strategic initiatives is one thing; reallocating resources, shifting tactical priorities around, and generally rearranging the furniture is another. Intent has to be translated into action.

It's just something to think about -- is your PMO actively posting lookouts as part of navigating the enterprise, or are you simply waiting to respond after you run aground?