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?

Understanding the Value Proposition of a PPM Investment

After writing yesterday’s post, I started thinking about really how to define the value proposition of a PPM investment.  While the primary value remains (as I wrote yesterday) alignment with portfolio goals, there are still quite obviously benefits related to operational excellence, increased efficiency, and reducing the risk of rework or potential safety issues.  In fact, as I started writing down all of the various value propositions of a PPM investment, I realized that pretty much everything falls into one of two categories:

  • Benefits that align the portfolio/program/project with the goals of the organization.  (Aligned)
  • Benefits that reduce the delivery overhead of the portfolio/program/project. (Efficient)

I then mapped those value propositions to the engagements and organizations that I’ve worked with to see if I could map them to specific characteristics of an organization, i.e. to determine if some organizations value efficiency while other organizations value alignment.  I played with a couple of different taxonomies, before settling on this one:

  • Organizations working with a defined project / program / portfolio scope (Defined)
  • Organizations working to translate a high level strategy into an execution plan.  (Derived)

Once I mapped that out, I realized that many of the organizations I’ve worked with have evolved over time.  I initially engaged when they were focusing on operational excellence and efficient delivery, and then over the years, have watched as they’ve grown in maturity and become focused on how to effectively define the portfolio.

Finally, I overlaid some of the component capabilities of a PPM solution to see where they fit into the model.

The end result is as follows….thoughts?



Understanding the Value Proposition of a PPM Investment

In PPM, Situational Awareness Trumps Operational Excellence

Consider, for a moment, a cautionary tale of two organizations: Organization A and Organization B.  Each organization takes a significantly different approach to delivering the project portfolio management (PPM) capability.

Organization A has a relatively immature approach to project portfolio management and performs annual planning on a, well, annual basis.  Each business unit compiles a list of project requests which are submitted to a central repository.  Months of back channel negotiations and positioning ensue.  At the end of the process, the organization has a list of approved initiatives for the next fiscal year…which may then be summarily ignored in favor of last minute project requests thrown out by the business.  This is what I would classify as a typical “pull” approach to PPM, where each group submits a request to pull the project through the approval cycle and into execution.

Organization B, on the other hand, takes a different approach to portfolio execution and starts a bit farther back in the value chain with an exercise in defining what organizational performance actually means.  This is broken down into strategic programs comprised of projects that are identified by the program management structure.  This is more of a push model where the PMO organization is responsible for identifying projects and pushing them into the portfolio.  If we apply this to the traditional v-model validation concept, we would end up with something like the graphic below where the traditional PPM measures actually fall at the lowest level, i.e. the “Execution Plan.”


Where do these goals come from?  These days, those goals are increasingly being driven by gains in the field of analytics.  As analytics platforms mature and the volume of data generated by the Internet of Things expands, analytics are expected to drive ever more decisions as to what projects need to be executed and where capital should be prioritized.  Are assets providing the expected return?  Is equipment performing as it should?  Increasingly, analytics will drive these assessments.

Once gaps are identified, i.e. once we identify reality is not performing according to specifications, what is left but to charter an intervention in the form of a project?  Now, however, the project is not driven by a request or saddled by the lack of an ability to track benefits.  The project is born of analytics and will support a specific measurable goal.


This then becomes the key indicator for the maturity of a PPM system….not how many strategic drivers are leveraged to assess projects, or how structured the process is.  Instead, the single indicator that will drive PPM maturity into the future is how much data, or situational awareness at the highest level, is actually being used to drive the project identification process.

In PPM, Situational Awareness Trumps Operational Excellence

The History of PPM – 2016 Q1 Edition

You know that video on Youtube?  The one where this guy presents the history of dance in 5 minutes?  This blog post kind of started as an homage to that, i.e. an attempt to take you through trends in the PPM space over the past several decades.  Part of the driver for writing this post is that I’m starting to see discussions turn to “the next big thing” in PPM which is an early indicator of a shift change in PPM thinking….and a helpful reminder of the last time I listened to the NBT discussion.

Stage 1 – Project Execution

It all started with the push to enhance project execution.  Focus was placed on enforcing a consistent delivery methodology, resource balancing and religious wars around which execution methodology was most appropriate for any given scenario.  I’m not discounting the importance of any of this…..execution is important.  What’s happened in tier 2 portfolios at least is the growing recognition that execution is not the end all be all of getting value from the project value chain.

After all…..why execute bad projects well when we can execute good projects poorly?  In the end, we still get more value.  And hey, if we can execute good projects well, then that’s pretty much the sweet spot.

Stage 2 – Project Selection (The “Pull” Model)

Hence we moved into the era of strategic drivers and pairwise comparison.  The goal was to take a passel of projects, throw them into an analytical engine and let them shake out into an optimized portfolio.  Couple this with a feedback mechanism from the project execution process, and we can ensure that our project portfolio is ever optimized.

Again….sounds great.  The model begins to erode however once we introduce benefits realization into the mix.  Benefits realization is they key to optimized portfolios.  Hence, this required that all projects must be tied to a benefits case.

The other challenge is that this required a regular cadence of project review and approval.  Many organizations don’t have the time to wait for a project to be proposed, go through a review, and then wait in a hopper with a number of other projects in order to get evaluated and approved.  After all, that’s the only way to account for the opportunity cost associated with the project.

Stage 3 – Program Based Allocations

Continuing in our search for the optimal project portfolio, some organizations have turned to program based allocation as a remedy to the slow pace of the traditional “Collect and prioritize” model.  Funds are allocated to the program, and in turn, are allocated to other projects that meet the needs of the program on a regular cadence with less dependency on evaluating all projects against all other projects.

Programs when used in this fashion, i.e. essentially a benefits realization framework, also provide the critical wrapper for project performance metrics.  We don’t need to track the benefits of each project, but rather the program in aggregate.

Arguably, ITIL came in ahead of its time with a concept ahead of its time by providing a way to wrap projects around services that are offered to the business.

Again, this is a great approach and a significant step forward.  Where this is lacking is the link to the corporate strategy.  The portfolio management organization at this point has reorganized to work flexibly and bimodally but is crucially still lacking in a way to tie the execution work with the overall strategy.

Stage 4 – Project Identification (The “Push” Model)

Remember back in stage 2 where our goal was to get a whole list of projects put together and prioritized?  Around that time was when the ideation vendors used to come in and pitch their products.  How do you prioritize a list of projects when you don’t even know whether the list was complete?  How do you methodically identify the gaps in performance and strategically develop the next innovative product offering?

Enter the world of capability based planning and enterprise architecture.  Identify the goals of the organization.  Identify the capabilities required to support those goals.  Invest in strategic capabilities – by treating each capability as what is in effect, a program.  This represents the next step in the evolution of portfolio management thinking, i.e. the critical link between the doing of portfolio management and the content of the portfolio itself.

Enter the next phase of the portfolio management evolution.  The portfolio management organization identifies the projects before they’re even requested. (Both hands leaving the temple in a “mind blown” expression.)

Stage 5 – Whither Next

So where do we go from here?  That’s a good question.  A couple thoughts…

  1. Identifying a flexible framework to allow us to adjust our portfolio management approach based on conditions in our industry or the economy.
  2. Incorporation of big data and the Internet of Things.  With ever cheaper access to analytics and benchmarking, organizations can shine a spotlight on their internal operations like never before, and use that data to create portfolios of prioritized projects designed to address those gaps.
  3. Moving away from the concept of projects entirely and focusing on making everything into a small collection of process improvement efforts managed as part of a continual flow.  (Think about this, maybe the move to the cloud may be the last big software project most organizations ever undertake.  From there on out, it’s all going to be a gradual evolution to support new processes punctuated by the occasional interruption caused by an acquisition or divestiture.)


As I was writing this, I realized something however.  These stages don’t necessarily represent an evolution in maturity.  Rather they represent a growing push to make work more relevant.  When that push starts at the bottom, i.e. at the level of the people doing the work, then what I’ve outlined above is a natural progression that many organizations move through.

What if we start at the top though?  What if we identify the strategy and then work our way downwards to design from scratch the optimal mechanism to operationalize that strategy?  Wouldn’t we end up pretty quickly with a design very similar to what I’ve outlined in Stage 4?

That then begs the question… often do companies take that top down approach?  If, as I’ve observed, it’s not very frequent, why?  Why is it always an approach of starting at the bottom, and then increasing our reach in larger and larger slices of the organization?  That’s a post for a different time.

Finally, yes, I know that image is still in your head.  Here’s a link to the Evolution of Dance video.  Always worth checking out.

The History of PPM – 2016 Q1 Edition

PMOs: You’re Either With Them….Or Against Them

It’s an oft repeated joke about PMOs that the difference between “policy” and “police” is only one letter.  (The other joke being that PMO’s are like potato chips; you can’t have just one.)  Preparing for the webinar we delivered this week on annual planning caused me to reflect on this statement.  Specifically, what is the role of the PMO in a responsive Mode 2 method of annual planning?

We defined this responsive mode of annual planning as having three main characteristics:

  • Segmented Portfolios
  • Program Based Allocations
  • Frequent Rebalancing


It’s basically moving from a model where annual planning is an exercise in work authorization to where it becomes an exercise in work allocation.  Goals are defined as well as key metrics and KPIs.  It’s then up to the program and asset managers to best define how to get to those goals.

What is the PMO’s role in this?  Once we defer the goals to a specific program manager, the PMO’s job is to support the program manager to achieve these goals.  The fundamental relationship of the PMO to the organization has now shifted.  Instead of being a roadblock in the name of process compliance and risk mitigation, the PMO takes on the role of a support office, providing the analytics, tools, and know how to assist program managers in achieving their goals.

This is the fundamental realignment required to support a responsive annual planning model.

PMOs: You’re Either With Them….Or Against Them

Does Microsoft Project Online Integrate with [Blank]? (Part 2)

This question comes up increasingly in our discussions with clients:  “Does Microsoft Project Online integrate with [fill in the blank with whatever Agile tool your organization happens to be using….TFS, Jira, Rally, VersionOne, Excel, etc.]?”  The answer is invariably “Yes, and….”

Given that it came up again this week, I figured it was probably worth a blog post to review the options available.  First, we looked at the technical options for integration in the last post.  Now that we have that out of the way, let’s look at specific scenarios that we see come up most often in this post.  (Yes, I realize I should be doing it the other way around, but to be honest many organizations haven’t identified the specific scenarios they’re trying to support yet, and are really just looking to keep their future options open when standardizing on an overall PPM platform.)

For prior postings on how to integrate Agile processes with an overall portfolio management mindset, please take a look at some of our old blog posts here.

Scenario 1: Portfolio Management

Portfolio management is probably the biggest aspect of using Project Online and an Agile tool.  The project is proposed and selected within the boundaries of the Microsoft platform.  Once the project has been chartered, a high level schedule is generated within Project Online, and the development efforts are pushed to the Agile tool.


In this example, the integration scenario is that once a project has been chartered, the same project must be created within the Agile tool (presumably with the help of a project identification number).  This allows us to ensure that all work has been properly authorized and prioritized against other work.

The reality in this case is that the Agile work is bookended by the portfolio management processes of the organization as well as the high level project execution activities…the user adoption, training, initial planning, etc.

Scenario 2: Resource Modeling

In this scenario, which is probably the most common scenario, the organization is seeking to develop a comprehensive view of resource capacity and demand.  Projects are chartered and work is managed within the framework of the Agile tool.  How does the organization gain an overall view of resource commitments?

In theory, this is quite simple.  To perform true Agile, your development staff is dedicated to the project, i.e. no more of that nasty task switching that causes delays in a traditional waterfall model.  Hence, you follow the same process as above, and when it comes time to allocate resources, you simply calculate the duration from the beginning of the first sprint to the end of the last sprint, and assign your development staff full time.

The details are then managed in your Agile tool of choice, and “integration” simply consists of comparing the finish date for the last sprint with the finish date estimated in the schedule tool.  There may be some reporting requirements, but these are easily handled by aggregating the data from the two systems into the same data model within Power BI.

Scenario 3: Task Scheduling

The final scenario usually involves scheduling of the specific sprints in the Agile tool.  As Microsoft Project is the preferred scheduling engine for many organizations, the overall schedule is modeled in the Project Online tool, and then specific dates are pushed into the Agile tool.


This gets a bit more vague, as the trick here is to identify specifically which data is being pushed into the Agile tool.  If really we’re managing the development activities in that tool, then the only dates I really need are the dates when I kick off my first sprint…..and when my final sprint completes.  Potentially, I may use this to schedule around release windows, i.e. to model release windows and blackout dates in my schedule, and then use that to assess impact on the sprint schedules.

Those are my scenarios.  Did I miss any?  If so, let me know in the comments below.

Does Microsoft Project Online Integrate with [Blank]? (Part 2)