The first of four (1 of 4) Solution Shared Services looks at the Transformation Management Office / Owner (TMO). This group, or individual, defines the scope and scale of transformative change. In other words, whether a single application, a set of several technologies, or an enterprise-wide transformation initiative, such change begins here.
TMO is a Shared Service because it does not deliver any one application or technology. Indeed, the TMO does not manage any implementation. Instead, the TMO facilitates the work needed before implementation gets underway. Specifically, this involves prioritizing requests for changes, identifying alternatives, defining areas of change, and securing needed resources. Thereafter, the TMO hands off to others who manage individual implementations.
The Iterative Transformation Model directs change through a standardized framework. At the top, Solutions define the broadest means by which to manage change. Introducing any new application or technology is likely to affect business operations, as well as other IT assets. It is the TMO's responsibility to establish framework boundaries, identifying which business operations and which IT assets a transformative change will impact. Accordingly, the framework allows the TMO to define where such impacts occur.
The Transformation Management Office / Owner begins the change process by defining what may change, and what may not. Further, they facilitate laying a foundation for change by establishing guidelines and guardrails to keep individual change initiatives on track. In short, they ensure the right people produce the right information at the right time. In doing so, they greatly improve each initiative's probability of success. Moreover, their efforts also save organizations a lot of time and money.
Expediting Change: Transformation Management Office / Owner
Any change large enough to affect which applications or technologies an organization uses must involve critical thinking, credible planning, and calculated decisions. At this scale, change consumes a lot of resources - time, money, and people. Moreover, there are opportunity costs of not applying those resources to other, viable changes. As a result, organizations should never take such change lightly, nor begin arbitrarily.
So where to start? Indeed, whether implementing a single enterprise application, planning an initiative involving two or more applications and/or technologies, or dealing with all systems in an organization, each scenario shares common characteristics. For instance, each scenario involves the introduction of new Solutions. Additionally, any new Solution is likely to affect other, related systems. Just as related systems will affect the Solution itself.
Moreover, any new Solution may also replace one or more legacy systems. Sometimes in whole, other times only in part.
Considering the business segments, user communities, operational and transactional data, as well as infrastructure and platforms involved, one can easily see the potential complexity of such change. Is there a way to simplify such complexity?
Framework for Change
Indeed, there is.
The ITM makes a distinction between work done before a Solution's Inception, and work done after a Solution's Inception.
The non-iterative sections within the ITM - Portfolio Planning, Business Process Definitions, and Solution Strategy & Architecture - address work which occurs before Inception. Together, they define individual Solutions and the scope of change. Appropriately, together these sections comprise Solution Definition.
The iterative sections within the ITM - Planning, Implementation, Testing, Reporting, Operations - address work which occurs after Inception. Together, they implement and validate changes which relate to individual Solutions. Correspondingly, together these sections comprise Solution Delivery.
A single entity should orchestrate the work which occurs in the before period. The ITM refers to that entity as the Transformation Management Office / Owner (TMO). To understand the work at hand, let's start by identifying the "Portfolio". Afterwards, we can better describe "Portfolio Management".
Portfolio
Firstly, for an implementation involving a single, enterprise application, the "Portfolio" includes the new system coming in, any legacy systems going out, and any related systems with which the new or legacy systems interact.
Secondly, for an initiative involving two or more applications or technologies, pretty much the same definition applies. In this case, the "Portfolio" includes the new systems coming in, any legacy systems going out, and any related systems with which the new or legacy systems interact.
Thirdly, if considering all applications and technologies supporting an organization, the definition remains the same. The "Portfolio" includes any new systems coming in, any legacy systems going out, and any related systems with which the new or legacy systems interact.
Accordingly, initiatives of any size begin by considering management of their "Portfolio".
Portfolio Management
After understanding the Portfolio, why is Portfolio Management needed? Well, for several reasons.
True Scale of Change
Firstly, recognize that any new system(s) going in is but 1/3 of the actual change. Leadership must give proper consideration to the removal of legacy systems, as well as to integrations with related systems. Otherwise, predictable challenges appear which negatively impact the course of implementation.
A new initiative may appear relatively straightforward, especially when glossing over the more complex aspects. However, sooner or later, there is no way around the fact that implementations must address legacy systems and integrations. Addressing them up front offers the best paths forward. Conversely, addressing them later, or as they arise, frequently introduces conflicts amongst stakeholders. Often, such conflicts lead to re-work and delay, if not outright impediments to progress.
True Scope of Effort
Secondly, most incoming systems offer a variety of functionalities. Similarly, there is often a need to rationalize functionality across multiple, alternative systems. Firms frequently have multiple applications, each capable of supporting the same business processes. Such overlap raises the question of which module(s), from which systems, to use? Ideally, the answer to that question should seek to maximize the Portfolio's value. Accordingly, someone must decide, or facilitate the decision(s) of, which applications are to provide what functionality.
On one hand, it may appear easiest to use as many modules from the new system as possible. However, the broader the functionality, the more complex the need to deal with legacy data and systems. Broader scope also implies more resources. On the other hand, perhaps starting with a single module is easiest. Smaller footprint, smaller problems. In truth, the answer is almost always somewhere in the middle. Considerations must include the number of interfaces, the migration of legacy data, the amount of training, along with potential costs and savings.
True Set of Objectives
A key reason to identify functionality reflects the need to identify and engage the proper decision makers: Customers & Sponsors; Epic Owners; Business / Process Owners; legacy and related System Owners, among others. In fact, these are the individuals who must set objectives for large-scale change. If the proper individuals are not on board, problems are sure to arise. Sometimes, insurmountable problems. Even worse, if someone assumes they can set objectives for the owners, without the owner's involvement, sooner or later everyone is in for a harsh reality check.
The need to set objectives is one of the critical aspects that differentiates successful, from unsuccessful, transformation. Lacking objectives, it is far too easy for efforts to be aimless. Those who want to throw a backlog together and just "get going", typically miss the bigger picture. They can spend an excessive amount of time - and a stunning amount of money - without achieving any objectives. Of course, objectives require context. And context requires an understanding of scope and scale. Objectives also benefit from defined channels for change.
True Channels of Change
Regardless of the "Portfolio" size, the initial step is to identify and define two key channels, or conduits, by which to manage change. The first are Solutions. In general, these define what application(s) and/or technology(ies) the organization will use. Second, are Epics. Basically, Epics define which areas of functionality (e.g., modules) the organization targets for use, by which business segment(s), towards what objectives.
Identifying and defining these two types of conduits provides the framework with which to segment change of any size into manageable pieces. Following the ITM's Portfolio Management tasks offers a systematic approach to establish the Epic(s) and/or Solution(s) within the Portfolio. Those who look at complex, perhaps overwhelming, amounts of change and first think of establishing a project, or program, are taking the harder path. Instead, first look to define the individual conduits for change, and then determine whether projects and/or programs help coordinate and orchestrate the affected channels of change.
While this may sound daunting, there is no need for it to be. Portfolio Management offers a systematic approach to:
- Define Epics and Solutions.
- Engage and align the proper participants; and
- Have the right people, do the right work, in the right order.
If setting up for a large volume of change, using the Portfolio Management tasks, along with corresponding Management Boards can help. For a smaller initiative, or one-off change, there is no need for a Transformation Management Office / Owner to implement the tasks and boards. Instead, simply follow the steps outlined for each task to identify the sequence of work and artifacts to develop.
Afterwards, whether implementing one Solution, or several, the same Solution Delivery approach applies for each. Together, Solution Definition and Solution Delivery allow participants to move forward using knowledge and decisions, not ignorance and assumptions.
Recognizing TMO Forms
Dedicated Group
Many large organizations have a group dedicated to the prioritization and management of change. In many cases, that group uses the TMO name. Other organizations may use names such as:
- Business Engagement
- Business Transformation Services
- Strategic Planning Office (SPO) or
- Enterprise Portfolio Management Office (EPMO).
Whatever the name used locally, the ITM uses TMO. Feel free to infer any group with similar objectives when the ITM refers to TMO.
No Group / Individual
Alternatively, perhaps an organization is not yet mature enough to have a group specifically tasked to manage change. However, even if there is no specific group responsible, the work to prioritize and define change must still occur. It's just harder to do when not formalized. So, if your organization does not have such a group, there will be some extra leg work in figuring out who will complete the prescribed work.
Ad-hoc Group
Another common scenario is when an organization undertakes large, transformative change. Any initiative involving two or more Solutions requires TMO actions to get things off on the right foot. Approaching such a transformative effort as a single Project, or initiative, introduces unnecessary complexity. That complexity will cause challenges and delays. Casting a wider net does not simplify things. In truth, it makes things more difficult. Much more difficult. In this situation, firms should still execute the recommended TMO actions, even if by an ad-hoc group. Doing so will help prevent delays, reduce challenges, and facilitate more timely progress.
Importantly, regardless of whether an organization has a specific group or not, or what its name may be, there are tasks to complete prior to putting iterative delivery efforts in motion. These tasks apply to all Solutions. The ITM uses the term Transformation Management Office / Owner (TMO) to identify those responsible for those actions.
Skipping TMO actions is a monumentally bad idea. None of the prescribed work is avoidable. It must be done, sooner or later. Otherwise, the initiative is unlikely to succeed. Further, doing the work at the wrong time, or in the wrong order, drives increased costs, delays, and frequently leads to large amounts of re-work. None of that helps an initiative's ROI.
What the TMO Should Do
In short, a Transformation Management Office / Owner is responsible for driving, or orchestrating, Solution Definition activities. That is, the TMO is responsible for ensuring alignment between an organization's Business Strategy, IT Strategy, and investments on individual Solutions. As such, one of it's objectives is to balance IT investments with potential ROI.
The TMO owns the ITM's Portfolio Management actions. This includes the means to receive, prioritize, and process Customer Requests for Change. In doing so, the TMO plays a key role in determining which requests to address, and in which order. Further, they also determine how to structure individual changes. They balance Requests for Change against the existing Portfolio, the value of the change, and available resources. As a result, the TMO helps identify and define large increments of change, including new Solutions, new Epics and/or new Capabilities.
Additionally, while they may or may not own actions in the related ITM sections, they also coordinate, and facilitate, Business Process Definition and Solution Strategy & Architecture efforts. Actions within the latter sections are crucial to defining any large-scale change. Typically, these actions occur in parallel with Portfolio Management actions.
Importantly, all three sections produce significant deliverables. Moreover, they help ensure completion of the right work, in the right order, and at the right time. Indeed, many of the artifacts produced in these upstream sections transition from the TMO, on to Solution Delivery groups. Thereafter, the downstream efforts to execute change take over.
Time Management Guidelines
Time management during Solution Definition is more challenging than during Solution Delivery. However, to mitigate that challenge, the ITM borrows many aspects from Solution Delivery and applies them to Solution Definition. By viewing the Solution Portfolio as analogous to any independent Solution, the Transformation Management Office / Owner can re-use many planning, execution, and reporting tasks to suit Portfolio Management.
Portfolio Management drives the work which relates to Solution Definition. Whether or not an organization has formal Portfolio Management, look to the ITM's Portfolio Management section for a prescribed series of tasks and artifacts to get Solutions of any size off on the right foot.
In most organizations, there is more demand for change than there is supply available to deliver it. That is, they cannot address all change as soon as everyone would like. However, that's not unlike a Solution Backlog, where there is more change desired than Teams can produce at any one time. Accordingly, Portfolio Management borrows the same concepts of Sprints and Releases as used for Solution Delivery. Further, it also borrows all the Planning Levels. Additionally, it replaces Implementation Tasks with Portfolio Tasks. Although, it merely applies these tasks from a portfolio perspective, rather than an individual Solution perspective.
Since the TMO tends to deal with larger, and less well-defined objects, time management can be challenging. They will not always have good size estimates for the work required. As a result, the TMO should rely upon WIP Limits, as typically in use for Solution Delivery.
What the TMO Should Not Do
Most Transformation Management Offices / Owners are overloaded. In many cases, that's not because too much is expected of them. Rather, it's that they spend time on things which need not involve them.
If assigning a TMO member to one of the Roles associated with Solution Delivery, then that individual should fulfill that role. However, that need not mean the entire TMO should fulfill that role on every Solution. Some Solutions will be large enough to require dedicated resources in key roles. In this case, they are not suitable for individuals who are time-sharing with other roles and responsibilities. Conversely, some Solutions will be small enough that individuals fulfilling key roles can also cover other roles as well.
In general, unless fulfilling a specific Solution Delivery role, the TMO should not:
TMO Should NOT be... | Who should be... |
|---|---|
| Solution Strategy & Architecture | Application or Technology Architect, Solution Architect or Enterprise Architect |
| Plan the Project / Program | PMO Project / Program Manager |
| Track / Report Progress | Release Manager, Scrum Master(s) |