Architecting a Transformation Initiative

Like many posts I write, this one started as something somewhat tangentially related.  Originally, this post was supposed to be a rousing survey of funding models for large transformational programs.  Yes, I know….sounds exciting.  As I started looking at the funding models currently utilized however, I realized that this story is not really one about funding models – but about how transformational programs are fundamentally structured, about the fundamental operating model or architecture of the transformation program.  (“Structure” or “architecture” being shorthand for the combination of processes, tools and behavior required to support the transformation effort.)  Hence, at some point during the writing, this post transmogrified from the original discussion of funding models to one on transformation program architecture.

As with most of my posts, these conclusions are still evolving and are based on observations made working with and talking to hundreds of organizations over the years.  That being said, most of the organizations I work with tend to view large scale transformation programs according to one of two main paradigms:

  1. Step change transformation
  2. Incremental change transformation

A step change program is one that is embarking on a specific goal over a relatively short time frame.  Examples of this may be a regulatory remediation project, M&A activity, a divestiture, or an asset rationalization initiative.  The main challenge, of course, in a large step change transformation program is preserving the value proposition of the original proposed change – and in maintaining the new target behavior once the formal program has concluded.  After all, most large transformational programs are designed to permanently modify the underlying behavior of the organization.

An incremental change program is one that occurs over a potentially much longer period and involves the gradual alignment of culture with the long term needs of the enterprise.  Where the step change program is a “big bang” approach, the incremental change program is more of an evolutionary transformation conducted by tweaking the levers that guide project selection (among other things).  Think of this approach as an implementation of formal governance processes followed by a gradual adjustment of those processes and the metrics that govern the organization to steer it in the right direction.  Arguably, this approach is harder to implement due to the sheer number of moving parts – but it may also lead to more lasting change within the organization.  (Which is another post).

These two approaches could be mapped to a top-down vs. bottom-up model in terms of organizational change management.  If we were to visualize these two models, it might something like the graphic below – albeit the incremental transformation is probably significantly slower to achieve the same level of lasting performance as the step change model.


Process Perspective

Each transformational program architecture includes a series of critical processes: standard program management blocking and tackling; project identification, prioritization and selection; funding, metrics and analytics, etc.  Some of those processes may come naturally to the organization and some of those processes probably don’t.  In fact, unless you work in an organization that is always transforming itself (which does exist) or in a consulting shop, it’s likely that you may not have the required skills to structure a transformation program.  Anyways, suffice it to say, there’s almost always a series of new processes that must be defined to support any large scale transformation program.  The focus on which processes to develop does change based on the specific architectural model applied to the program.

In a step change transformation architecture, the focus will be on the traditional program management blocking and tackling.  In this centralized structure, the desired end state is defined, split into multiple workstreams – and then each workstream is planned out and rolled up into a single Integrated Master Schedule (IMS).  The program is then staffed with a program manager, IMS scheduler, workstream leads, and all of the other required staff.  It sounds easy – but it still surprises me how few organizations manage to do this properly.  (Pro tip: the more time you spend planning and structuring before just jumping into execution will be time well spent).

Incremental transformations rely on a different model for driving lasting value.  In this model, the transformation program piggy backs off of existing functions and processes.  Instead of instilling a new structure outside of the existing organizational structure, incremental transformation attempts to control the existing planning mechanisms to implement the change.  Typically, this means that the program goals are translated into strategic drivers and metrics which are then injected into the annual/quarterly planning processes of the different subunits of the organization.  This requires that these subunits employ some level of formal planning in selecting project portfolios – and that these methods are subject to some level of influence by the transformation program leadership.

Funding Models

Now we arrive at the original premise of this post.  What are the funding model implications of these two approaches?  This is actually a perennial question that many organizations struggle with.

For example, what often happens is that a particular transformation program is decomposed into multiple workstreams, and that one of those workstreams is IT.  The IT components are then added as projects into the IT portfolio during the next planning cycle.  From the perspective of the IT portfolio manager, several projects have been added to the intake process that have been classified as either high priority or as mandatory projects.  These projects may draw on the same funding sources as all of the other IT projects, but be flagged somehow as belonging to the transformation initiative.  (One might suspect this funding approach is indicative of trying to “transform on the cheap,” by simply absorbing related projects that would have been initiated anyways as part of the overall program effort.)

The alternate approach is to secure funding for the entire transformation program and to treat that as a coherent, holistic budget.  As projects are defined and moved through the approval pipeline in the context of the program, those projects represent committed funds against the program budget.  A slight variant on this model is to budget for each workstream, and then to allocate funds within each workstream as projects are identified and moved through the approval cycle.  (The latter approach representing a more agile approach for an adaptive program management model within the step change framework.)

As always, the decision for how to architect the funding model lies on control.  If the program requires firm control and visibility into progress as in the step change model, funding should be through a central program entity.  If the program is less urgent in time, and is dependent on gradually shaping the direction of the organization, a deferred funding model is probably appropriate.  That being said, the more sophisticated organizations that I work with still have a portfolio coding mechanism to flag wholly or in part how much of the investment in a particular project is supporting the transformation initiative.

Supporting Technology

The two approaches also imply a separate supporting technology architecture.  In a step change model, attention must be paid to the structuring of the work portfolio, the decomposition of the overall program into its component parts, and the required blocking and tackling for each of those parts: budgeting, scheduling (deterministic or agile), risk management, schedule integration, etc.  Each of those parts must then be mapped to the overall context of programmatic risk management and governance.  These processes require appropriate technology support, i.e. a mechanism to structure and support the overall governance of the program.

Incremental change is typically more dependent on a federated PMO model.  Organizations usually maintain multiple planning organizations by function and/or business unit.  These organizations are responsible for selecting the appropriate mix of projects for the organization – and in turn, their specific spending authority is subject to a number of factors such as how nimble the organization needs to be, economic factors, etc. (see an older discussion here).  The critical consideration here is that to support the overall needs of the long term incremental change, leadership needs a way of influencing the behavior of the specific units within the organization, and that is most often performed through pulling the levers of the project selection mechanism.  Hence, if each unit within the organization has a centralized function to perform portfolio planning, and the factors that impact the planning are capable of being influenced from the central organization, the entire ship may be steered in an appropriate direction.

In the incremental change model, attention should be spent on ensuring the appropriate technology is in place to support visibility into the pipeline of projects passing through each of the various planning entities – and to ensure that project approval decisions are made according to the appropriate drivers.  In this case, the technology is focused on making the approval decision making process transparent and consistent.


Transitioning from Step to Incremental

The reality though is that the question of step change or incremental transformation is not an either…or… decision but an either…and… decision.  I typically see organizations leverage a step change opportunity to implement the technical and process infrastructure required to support the long term adoption of an incremental change culture.  Hence the processes that get created to support the step change transformation get baked into the organization and reinforce long term behavioral change and performance improvement.  This approach also serves to reinforce the value proposition that the original transformation was designed to bring about in the first place.



Architecting a Transformation Initiative

Under What Conditions do PMOs Naturally Emerge?

I remember reading Tolstoy’s War and Peace in high school.  The book (tome may be more accurate), if you haven’t read it, depicts life during and after the Napoleonic invasion of Russia.  The book tells a story, for sure – but it’s also a very (very) long essay on one fundamental question:  Does history make the man…..or does the man make history?  Let me restate the question in terms more relevant to what I do….do PMOs make the environment they operate within…..or does the environment create a PMO?  More specifically, perhaps, what are the conditions upon which a PMO naturally emerges – whether or not it’s actually called a PMO.  In what environment does a PMO-like structure naturally emerge?  The goal in asking this question is not to identify what PMOs actually do – but rather, in what environments, where a PMO doesn’t exist, it should.  In what circumstances should we look to create a PMO function when none exists?

To answer that question, I first looked at the different domains in which PMOs typically exist.  What role does a PMO play in each of these domains?  Can we extrapolate any truths that cross domains to govern when PMOs naturally form?

PMOs within the IT Domain

I know I’ll oversimplify this and probably make some folks cringe, but the basic narrative, which I’ve never really had reason to question, is that PMOs formed in IT right around the run up to the Y2K remediation exercise.  They sprung up to support the coordination of massive numbers of critical tasks and resources that needed to be coordinated to remediate coding issues.  Subsequently, PMOs have stuck around, generally to provide a portfolio alignment capability within IT and process compliance.  Hence, from looking at the IT domain, we might surmise that PMOs emerge under the following conditions:

  1. Large number of tasks that need to be coordinated with a shared resource pool.
  2. Aligning the work of IT to best provide business value.

I might theorize that IT PMOs are required to also drive process compliance, i.e. to mitigate the risk of unscheduled outages in organizations ever more dependent on IT.  The interesting thing here though is that many other domains, such as manufacturing, tackle the challenge of process compliance in different ways, without PMOs.  My theory here is that perhaps IT policies are rapidly evolving, and as such the PMO is required to continually monitor process compliance in a world where process keeps shifting.  In that sense, we may be able to conclude that PMOs should exist when process compliance is an imperative, and when that process compliance governs technology or conditions that are inherently dynamic.

Now the original question may not make sense in the IT domain context.  Of course IT needs a PMO.  That’s been accepted wisdom for years.  But what about other domains?  What about other domains with the same needs but without the same acceptance as to the value of the PMO function?  What about PMOs in oil and gas exploration and production?

PMOs for Exploration and Production

Historically, exploration and production has been a slow, methodical capital driven process where projects required multiple year ramp ups.  In the new world of unconventionals, that paradigm is shifting and organizations are reorganizing and restructuring around a more nimble paradigm.  Historically, that paradigm has been based on local optima, where each group was responsible for managing its piece of the oilfield.  In the new world of depressed commodity prices, that pattern is changing, and unconventional organizations are moving to knit their operations together more holistically and support the ability to shift tasks and schedules based on changing priorities.

Hence, PMOs are appearing in the unconventional E&P space.  Admittedly, some of these PMOs have been around for years, but there’s a growing awareness in the industry of the role and value that may play.  Hence, going back to the original thesis of this article, the appearance of PMOs in unconventional E&P portfolios appears driven by:

  1. The sheer volume of tasks that must be performed in synchronization to generate value and reduce cost in the oilfield.
  2. The need to constantly recalculate and reprioritize the work being performed based on enhanced data and real world performance.

Now, let’s skim a rock over other domains that I typically play within.

PMOs for Professional Services

PMOs seem to often take less of a role in professional services organizations.  In these organizations, projects are generally undertaken for a clear, profit driven reason.  These projects were proposed, went through an economic review, and drive margin for the company.  As a result, there’s less of a need for the PMO to ensure portfolio alignment – but more of a need for the PMO to drive margin through risk avoidance/process compliance.

Going back to the initial discussion, the role of the PMO in a professional services portfolio is to enforce process compliance to deliver results in a rapidly evolving field.

Program Execution

Finally, we have program PMOs – which perform a coordination function required to coalesce many disparate disciplines into a single endeavor.  Again, here we are leveraging the coordination model….made all the more important as the groups are probably not used to working together and need the central coordinating body to ensure work is performed in the appropriate sequence.

Other Examples

I could run through other examples, but as I thought through them, I pretty much end up with the same conclusions.  PMOs tend to emerge when the following conditions are identified:

  1. A portfolio of work loosely aligned to profitability and/or the overall goals of the organization.
  2. A portfolio of work that outpaces the ability of a centralized resource pool to support.
  3. A portfolio of work performed by many agencies that is continuously shifting in response to external factors.
  4. High risk processes that must be adhered to in a domain that is rapidly evolving.

Identify those requirements within your organization, and chances are you need (or have) a PMO.

Under What Conditions do PMOs Naturally Emerge?