Building Flexible Consistency with Appropriate Processes

No, today's title isn't just like jumbo shrimp or military intelligence…

Is it just the season, or what? Seems like the past several weeks have been downright frenetic. For me personally, some of that was self-inflicted as I went through my biennial bout of car-swapping fever, with all the time, energy, emotion and money that particular illness consumes. It's like being plagued with automotive malaria — no cure for it when it comes around, but it's a good excuse for a gin and tonic. It also seems like I've been somewhere on business just about every week lately, from one coast to the other and points twixt and 'tween.

Yes, that was indeed a thinly veiled lead-in to defend my lack of recent meaty postings — I really do have a day job.

"Burger's Up!"

In my February 20th posting, Teaching a Pig to Whistle, we touched on the perils of trying to force too many things into too few operational niches with processes or templates for the sake of uniformity, especially when it comes to professional knowledge worker environments. I promised to follow that up with some thoughts on how to strike a balance.

First order of business, from a PMO perspective anyway, is to review what the drivers and real minimum requirements are for standardizing operating models. For example, are there certain mandates that you are chartered to enforce? Things like:

• Corporate and/or regulatory policies, such as the floor for what is potentially capitalized, SoX compliance, etc.
• Certain corporate-endorsed methodologies or standards, like PMI, ISO or Six Sigma
• Anything that is in the "Because I Said So" category from on high… I am not talking about mere suggestions; we're in the land of "prerequisite for continued employment", a.k.a., "Thou Shalt" statements. For example, the timing of certain events (e.g., the budget cycle), mandatory gate reviews, etc.

Those requirements and the underlying minimum process elements necessary to achieve compliance constitute the baseline of what HAS to be done. In most instances, these can be reflected at a pretty high level. If we use project management as an example, most of the have-to elements can probably be depicted and/or enforced at the phase level, along with appropriate work flows.

Everything after that, by definition, goes into the category of discretionary practices.

That doesn't mean there aren't really great ideas or high value approaches that should be done, just that they offer some element of flexibility in how to achieve them. The wheels won't fall off the business wagon if you provide options or allow some room for interpretation. For example, do we have to do something in the testing and validation phase? Yes we do. Do we also have choices in establishing the most appropriate ways to ensure a quality deliverable? Yes we do (If you answered no to that, see me later).

So, the question really becomes one of how to best define and promulgate any amplifying details, where they come from, and how elastic they are. It's also a matter of who gets to promulgate and who must capitulate. Usually it's a lot more fun to do the former than the latter (at work anyway).

States Rights

I am a big fan of a federalist approach for the PMO; set minimum standards and then focus energy on working with respective line managers to first enable them with the proper tools and techniques, and then further delineate underlying details. By doing this, you accomplish several beneficial things.

First, you are engaging the organization to be part of the process of defining operational requirements, rather than being perceived as the mean old PMO that is unilaterally forcing things on people.

Second, you put the power for establishing managerial and technical details into the hands of the people most appropriate to define them for their respective groups. This greatly enhances the probability that such guidance is both correct and reasonable, which is obviously going to up the potential for adoption and compliance. And, since you aren't the one making the demands, it gets you out of the position of having to enforce them later (which is darned near impossible anyway if the manager doesn't buy-in to them in the first place).

It's important to recognize that this is a collaborative effort; the PMO working together with managers to establish processes, workflows, activities or tasks that will meet overarching requirements for standardization, while still being appropriate to the unique needs of a given group. The goal is agreement, rather than argument.

A real life example serves to further illustrate. A bank IT PMO defines project management-based processes for work and resource management, and promulgates them to the development group with some success. In the second phase of deployment, the PMO pushes these practices to the operations groups, who rebel against them. Why? Employing formal project management standards to non-project service work was administrative overkill and did nothing to add to their ability to manage their work and resources. Lesson learned: processes, templates and best practices are just tools used to do a job — pick the right tool for the job.

Employ Modularity

Almost any PMO will have a number of planning templates that are used. In my past life, we had a library of activity-level schedule templates that contained the appropriate tasks, logic and resource estimates for repeatable, routine work elements that we called "fragnets" (fragment networks?! I dunno — weird term and I haven't heard it since). Odd language aside, they were a great mechanism for building out plans quickly with a high level of assurance that the details were correct.

Such modules can be used effectively in most organizations to both distribute the planning burden and engage the experts in developing accurate plans. An example of this I frequently use is the process of defining, procuring, installing and deploying a new server. Obviously, the PMO is not going to be the resident expert on this. Instead, the appropriate group that must deal with making this happen is charged with building out this module, complete with associated forms, planning elements, resource requirements, durations, etc. The PMO provides the planning expertise and platform, but the technicians who must ultimately work to these tasks provide the engineering expertise and advice. Trust me, if you approach them to help with this, they will jump at the opportunity, since it will make their life easier. Project managers or other work planners can then just "plug-and-plan".

Uh oh, I feel an acronym coming on…SOPA, Service-Oriented Planning Architecture (or 'soup' on most menus in these parts…). I'd better check this out real quick. Lessee, there's something about soybean processors and archers in Sydney. This also stands for "schedule of proposed actions". Nice. In aviation circles, it means "standard operating procedure — amplified"; ooh, that's very good. "Synchronous Orbit Particle Analyzer" is a bit out there though. Heh.

But I digress…

Anyway, you can take this concept and apply it all over the place, if you take a look around. A lot of what we have to do is comprised of many smaller routine activities that just need to be properly assembled. Examples include procurement, requirements, engineering calculations and most technology elements. Allow the modules to be owned by the designated expert and make them responsible for maintaining them, but keep them in a common location so that everyone who needs to can easily access them. Encourage everyone to use them, and set up a mechanism to announce when new ones are made available.

The result is much better planning collateral, less planning overhead, more consistency, broader ownership and buy-in, and better performance. After all, that the purpose of a PMO, right? You'll be a hero.