What is a Transition Plan?
One of the most misunderstood deliverables in operational consulting, a transition plan often gets mistaken for a project plan, a roadmap, a change management deck, a communication strategy, or some combination thereof. It’s related to all of those things, and often shared similar features and characteristics, but it is a distinct and unique deliverable.
Before we dive too far into it, I wanted to address the elephant in the room - the consulting industry likes to use a lot of terms interchangeably and inconsistently, so when I lay out these definitions, I want to be clear that this is my perspective and my approach, and does not necessarily fit in a universal standard.
Looking at the gap between our current state map and our future state map, we have an understanding of the scope of the transformation. Now, imagine that we begin from a big-picture or strategic perspective of how to achieve that transformation, and then drill down layer by layer to get more operational. The deliverable for how to achieve that transformation at the most strategic layer would be the roadmap - this focuses on the major milestones and a rough timeline. One layer below that is the transition plan - this is where we answer the question: how do we follow the roadmap to get to the way we want things to work, without the business falling apart in the middle? The execution plan, sometimes called the implementation plan, is the layer below that, and is essentially a collection, prioritization, and organization of the various projects needed to achieve that transformation plan. At the next and most operational layer are the individual projects and their project plans. Finally, in parallel to all of these layers is the communication plan, which is nowadays usually also combined with the change management plan, or how to get everyone in the organization to adopt the new workflows, systems, and processes with as little friction as possible.
A transition plan is, at it’s core, a structured guide that accounts for the operational, human, and technical dimensions of the transformation that answers three questions: what changes, in what order, and how do we manage the in-between? The components for a transition plan usually include (1) a clear description of the current state being transitioned from and of the future state being transitioned to; (2) the gap analysis that defines the scope of the transition; (3) a sequenced set of phases with logic for why that sequence was chosen; (4) identified dependencies: what must be true before each phase can begin; (5) risk flags and contingency considerations; (6) ownership assignments at the phase level (not just the task level). I’ve provided some exmaples below of questions that are asked when creating the transition phase in order to help anchor it in reality for you:
What has to be true before Phase 2 can start?
What happens if the technology implementation in Phase 2 runs three weeks long — does Phase 3 slip, or can parts of it start anyway?
Which processes have to keep running in their old form during the transition because we can't afford to cut them over mid-stream?
Who is accountable for the decision to move from one phase to the next?
One question I often get is why do transition plans matter? Why not just start with the roadmap, pick the highest priority or biggest impact change, and move forward with it? This is honestly a viable strategy the smaller the company is, when it can stay agile and trying to figure out these dependencies isn’t as critical because there simply aren’t as many. But, in organizations that are beginning to encounter some level of genuine complexity (I would usually benchmark this at those with 25+ employees or those with over 5 million per year in annual revenue) the sequence provided in the transition plan can critically affect the success or failure of the transformation. Starting with technology before process is the most common feature I’ve seen of transformations that failed because of going out of sequence. However, when you dive into it, that can be much more nuanced than just “fix every process first”. Some processes or systems can’t be adjusted until technology is updated. Understanding those dependencies, planning around them, and forming contingencies significantly increases the chances of implementing a transformation successfully.
The transition plan is not the end goal: it is a thinking document, one that should be built prior to any actual implementation. It requires a lot of groundwork to create a transition plan (building a current state map and a future state map), and more work afterwards to lay out your execution plan, individual project plans, and communication / change management plans. To complete all of this is not a quick undertaking, but the results are almost always significant, giving you a clear understanding of where you are, where you want to be, and how to get there step-by-step.
— Basile
