If you work in project, change, or strategy implementation, you may think of phases mainly as a way to show off your SmartArt skills in Powerpoint. If so, I'm here to say, "Please, think again!" Phases are a multifaceted tool, that can help you in framing, negotiation, planning, and communication. As an implementer, phases should be your friend. Not a casual acquaintance; a friend. Like any friendship, put a bit of care into cultivation, and you'll reap rewards for the effort.
Why phases are a valuable implementation tool
Phases provide a high-level frame or container that outlines the stages or lifecycle of your implementation. They are like a storyboard for your effort. As such, they are valuable because they force you to sharpen the story you want to tell about how the implementation will play out. Phases can be used to clarify things such as: Where are we now? Where are we headed? What path will we take to get there? And, always a fan favorite — How long will it take?!
In addition to clarifying the story, phases can help you to tell that story well to most stakeholders. They are a communication workhorse because they provide enough definition to give audiences something to hold onto while not overwhelming them with irrelevant details.
Below I outline five ways phases bring value to any implementation.
1. Explain the nature of the implementation journey.
In my work, I use five implementation phases (see Figure 1). However, rather than their number or names, I think phases are valuable because they help you to design and communicate an implementation approach that represents the following principles:
Implementation is a multi-stage and evolutionary process. There are more than two phases — start and finish — and you may cycle through some phases more than once.
Effective implementation requires significant effort both before and after the “execution” of what you are implementing.
You must proactively transition the implementation to ongoing operations.
Figure One.
If you think four or six phases will work better for your situation or want to give your phases different names, go for it! However, in doing so, I strongly urge you to ensure two things: First, that the three principles outlined above are reflected in the phases you develop; and, second, whatever you use, use it consistently.
2. Provide a sense of location: Where are we now? Where are we headed?
Phases can give stakeholders a sense of location by outlining the starting point of the implementation, the endpoint, and planned stops along the way. Offering some certainty about the process the implementation will follow can allay stakeholder anxieties about the unknown and also help to educate them about how the implementation will play out.
For instance, I've found that most people want to start executing immediately. They want to show up and go! Who wouldn't?
However, implementation research indicates that successful implementers invest adequate time preparing before they execute anything. They clarify the purpose of the implementation, evaluate potential solutions to achieve that purpose, and plan how the chosen solution will be rolled-out and managed.
When people are itching to do start "doing stuff", you can use the story of the phases to help explain what is most appropriate to do when. I generally do so using an analogy from a common experience.
For instance, I once had an executive say to me, "I just want to do the execute phase. Can't we skip the rest?" I said, "What if we think of it in terms of that hike you took last weekend. Did you have to do anything before you started hiking? Like, decide which trail you would follow? Maybe prepare, by printing out a map and packing water and food. You probably also had to get directions and drive to the trailhead? Yes? This implementation is pretty much like your hiking experience. Right now, we aren't at the trailhead. We are at the house trying to decide what trail to take. If we leave now, we're likely to just end up going in circles. Is that really what we want?"
It's pretty simple stuff, and may even seem a bit hokey. But, it works just about every time!
3. Provide a sense of direction: Loops vs. Lines.
Phases can also help you to inform stakeholders about the direction or flow of the implementation. Although we often depict it as a linear process, it rarely is. While we are aiming for a forward progression from start to finish, we should expect to loop back, reassess based on learning, and try again.
In this way, loops are not an indication that something has gone wrong. Rather, they are a way to ensure things go right. Learning is iterative. So, we should expect that our implementation journey will have curves and corners, as well as mountains and valleys. It’s more like a ride on a roller coaster, than a train.
Try before you buy — three options
The type of ride you’ll have also has a lot to do with how you proactively shape the implementation journey you and your organization will take. You have options!
Pilots
A pilot helps you to understand what it's actually like to use the innovation in your context. It's an experiment that allows you to check assumptions, try out the solution you are implementing, verify your plans, as well as identify the best approach for embedding the innovation in your organization. However, pilots may not always be feasible.
Pilots can require a fair amount of time and resources to develop and execute. As such, they may be most appropriate for implementations that are likely to have a significant impact on the organization — fundamentally affecting revenues, costs or core operating procedures.
Second, pilots are usually carried out with the assumption that they may, or may not, move forward. If the pilot reveals the solution is not workable for your context, or the implementation needs a major rethink, a realistic outcome is that you pull the plug on the effort. Not all organizations and leaders are comfortable with the flexibility required to do that.
The opposite can also be true. Some organizations get addicted to pilots. They pilot and pilot some more searching for a perfect intervention and never fully commit to one. If you find yourself in either scenario, consider the options below.
Graduated schedule
A graduated schedule involves starting the implementation with a small set of initial users and expanding from there, learning as you go. Unlike a pilot, the assumption of the graduated schedule is that you will be implementing the innovation with all intended end users, but that you will evolve through the process.
For example, if you will eventually implement the innovation with 20 teams across multiple departments, you might start with an initial round of implementation involving one team from each department. You focus on learning — did it take people longer to catch on than you thought? What obstacles did they encounter? What aspects of the innovation did they love? Hate? Then you adjust your approach and implement with a larger set of end-users, and so on. This approach demands time and coordination as well as a degree of organizational patience and flexibility. Should you find those in short supply, consider the last option — testing.
Testing
At a minimum, you can incorporate some degree of testing into various aspects of your implementation approach. For example, you can conduct a dry run of your training with some end users to get their feedback before training everyone. You can test key messages with end users to support clear communications. You can also use prototypes or do a “paper walkthrough” of proposed changes with impacted stakeholders. Testing provides opportunities to get feedback from end users about their actual experiences — what they were confused about or challenges they ran into — rather than their opinions or assumptions. Testing is often illuminating, both for the end user and for the implementation team. I argue it should be part of all implementations.
You’ll likely make final decisions about your roll-out approach during detailed planning. However, I believe you should be aware of your options and have a general sense of the path you'll follow in the early days of the implementation. Why? Because in the absence of information, people will make assumptions. Most often they will assume that full implementation will definitely happen and that everyone will have access to the innovation at the same time. Rather than working to shift such expectations, I recommend you use phases to shape expectations at the outset.
4. Provide a sense of duration: How long will this take?
As you likely noticed, the options for roll-out discussed above require varying degrees of elapsed time. The choices you make about roll-out will extend or shorten the overall duration of the implementation. Phases can help you to illustrate this and begin to craft shared expectations and agreements about time with stakeholders.
Consider this scenario: Three months into the implementation the chief executive bangs her hand on the table, “Why is this taking so long!” The wide-eyed response of the implementation lead, “M’am. We’ve only just started!”
As this uncomfortable example demonstrates, the way we view time is relative and mutable — it can vary not only across national cultures, but teams, positions on the organizational hierarchy, and individual personalities. Further complicating matters, most of us fall prey to planning bias; we generally underestimate the time needed to complete tasks.
To combat this, I encourage you to view time as a resource in the same way you would people or monetary support for the effort. “Time is money” as they say. From the get-go, you’ll need to develop shared expectations about minimum and maximum duration, and likely negotiate the time resourcing allocated to the effort.
Use data, not assumptions
As you delve into planning, you’ll develop detailed schedules. However, even at the outset of your implementation, you can begin to influence people's notions about the duration of the implementation process, by aligning phases to a general timeframe. I suggest you do this based on actual data — not assumptions. When developing high-level duration estimates for the phases of implementation, consider the following:
Organizational calendars. Many organizations aim to be quick and agile decision-makers, but in reality, they work on a predictable cycle and at a deliberate pace. Unless the stars align and you have particularly strong leadership support, management decisions on your effort will usually need to align with the organization's planning and budgeting calendar. For instance, don’t predict decisions in three weeks time, if the relevant decision-making body only meets once a month and it takes at least two months to get on their calendar. You’ll also want to be mindful of the organization’s “busy seasons” as well as major holidays or common vacation periods, which can all impact the overall duration of the effort.
Previous experience. Gather lessons internally and externally, directly and from secondary resources, about how long it takes to implement the innovation (i.e., change) you are considering. Don’t assume you’ll be able to do it quicker than everyone else unless you have particular, verifiable reasons to back up these assumptions.
Cycle Time. The time it takes the organization to realize results from the innovation is often much longer than it takes to just put the innovation in place (i.e., get people to start using it.) You should anticipate needing several execution cycles to achieve full performance. How long this takes will depend, in part, on the innovation you are implementing. If you are implementing something that people will only use periodically, say once or twice per year, the end-to-end duration of the implementation process will be much longer than if you are implementing something people use daily. However, even if you are implementing something people use daily, you likely won’t be able to make strategic improvements daily. You'll need to set a schedule to review learning and identify improvements, perhaps monthly or quarterly. Estimating these cycles times, and how many cycles you’ll need before you can transition from implementation to ongoing operations, can help you shape expectations for the full lifespan of the implementation.
Finally, if you want to remain open to piloting or using a graduated schedule as discussed previously, you should account for these in your duration estimates.
5. Provide a sense of your destination: Jumpstart thinking about transitions.
Many organizations conclude implementations with the organizational equivalent of the 'mic drop'. Sometimes endings come simply when the scheduled ending date arrives; sometimes once certain outcomes are achieved. Sometimes files are archived and lessons learned are conducted, sometimes not. Consultants leave, people go back to their day jobs. Usually, someone finds out at the last minute that she is responsible for the ongoing maintenance of the implemented innovation, or worse, no one is ever assigned this responsibility and results deteriorate without a clear owner.
By using phases, you can combat the tendency towards abrupt endings, simply by calling out the existence of the maintenance phase.
In conjunction with the development of desired outcomes at the outset of your effort, you'll want to identify what will trigger the transition to the final phase of the implementation. Will it be based on the completion of a certain number of execution cycles, a specific date, or when target levels related to outcomes are achieved?
Additionally, if you use phases to frame your detailed planning, you'll be forced to think ahead about the activities required to prepare for and carry out this transition. This can include things such as: Who will be responsible for the effort for the long-term? How will they be prepared for this role? What resources will be transitioned to them? What information or artifacts from the effort will be transitioned or archived? When will this happen?
It's pretty easy to neglect thinking about endings, particularly when you've just started your effort. However, the conclusion is a critical part of the implementation story. So, if you want a graceful ending, my advice is to plan for it well in advance.
As you can probably tell, I'm a fan of phases. I believe if you put some time into crafting the phases that shape your implementation journey, you'll create a tool you can use throughout the life of the effort. If you too are a fan of phases (or not) please share your thinking in the comments section. I'd love to hear your ideas.
This article is adapted from my forthcoming book, The Implementer's Starter Kit. Learn more about the book here.