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.

 

Performance Improvement in 2 Slick Pages

Caught this PDF the other day while browsing ISPI.org’s website.  (I used to be on the board of the Central Ohio chapter):

Well worth the time to review:

http://www.ispi.org/pl/about/what-is-performance-improvement.pdf

Choosing an Engagement Model

Thanks everyone for coming out to my session on Project Epistemology a couple months ago at the Project Conference.  As I discussed in that session, there are often two conflicting views of any Project Server deployment – and I would contend that most conflict within a consulting engagement typically is driven by the conflict between these views.

Put more succinctly, when both parties in a consulting arrangement are operating from a different engagement model, bad things happen.

The first model is simple.  It is based on the following points:

1. The problem is simple.
2. The focus is the solution.
3. The solution is technical.

What this means is that we have a discrete, defined problem.  We can easily place boundaries around it, and the consultant’s job is to come in, design the solution, train a couple of end users, drop an invoice on the desk and run.

The second model is more complex.  It is based on the following points:

1. The problem is wicked.
2. The focus is the problem.
3. The solution is adaptive.

The challenge in the second model is that we never assume that everyone agrees as to what the fundamental problem actually is.  In fact, we don’t even acknowledge that everyone agrees a problem exists.  The first step in an engagement of that nature is to work on defining a common consensus as to the problems faced and the priority of those problems.  Often times, this requires covering ground that may have been covered already long before the consultant walked in the door.

That’s the fundamental building block upon which to continue the engagement.  Once that is completed, we don’t acknowledge that there is such a thing as a solution.  Instead, we acknowledge the concept of progress towards a solution, insofar as we can work towards a better future, one where we better understand what the problem is and better provide value to the organization.

What does this mean in the context of a simple reporting engagement?  Reporting, more than pretty much any other topic, lends itself to the adaptive consulting model.  In reporting, you are typically tying multiple data sets into a single reporting tool, and then presenting that data to your stakeholders.  Once they see the data, and they see how it can be manipulated, the questions start.  “Can I see it this way?” they ask.  “Can we add additional data to the mix to see how it impacts things?”

What that means is that a reporting effort never ends.  It just begins.  It’s an adaptive exercise continued ad infinitum until the stakeholders have iteratively identified what reports are actually required.

How does one consult in a situation like that?  You don’t focus on the steady state solution, which is arguably a myth.  Instead, you focus on building a capability.  Our job as consultants is to build the capability of developing and modifying reports within the client organization.  Once we’ve built that capability and the technology platform to support it, we have done our job well.

For more reading on problem framing as part of enterprise tool deployments, take a look at Kailash Awati and Paul Culmsee’s book, The Heretic’s Guide to Best Practices.