Transformation Pillar: Plan of Attack
About an 8 minute read
I have been to Disney World once in my life, and it was magical. In the span of five days, we were able to thoroughly explore each park and even get in a day at Universal Studios. As a Disney novice, being able to fully experience the happiest place on Earth was made possible by my sister's planning, or I should say hyper-planning. While the days were structured around fast pass and meal reservations, it felt as though every movement was coordinated. There actually wasn't anything strictly coordinated other than several key times throughout the day where we had to be certain places, and we had plenty opportunity to venture where we wanted. Having some structure in place to rally around and give organization to each day, however, helped keep the trip streamlined and prevented time lost to indecision. So again, what made this first Disney trip successful? Planning. The next pillar of organizational transformation is "Plan of Attack". Why not simply call the pillar "planning"? Because "planning" is boring and sounds tedious, and most importantly, "Plan of Attack" is a layer of early planning that, from the start, must look at components of the whole change process. Let's start with looking at how this early planning supports organizational transformation, changes, projects, etc. (I will use "change" to encompass the aforementioned items), and then we can look at the other pivotal pieces within the Plan of Attack pillar.
Planning, in the traditional sense, is vitally important in the world of change. There will always be value in creating transparency around objectives, communication, risks, resources, and timelines. Without knowing why change is occurring and its goals, change would be like dropping a ship in the middle of the ocean with no bearing. Communication is the foundation upon which collaboration can exist; it is the fuel for relationships and progress. Risks exist around every corner in opportunity costs and unexpected benefits, and the ability to handle risk is a trademark of agility and effective planning. If communication is the fuel for relationships and progress, resources are the fuel for actually bringing a change to fruition; without the people and matériel, change management is a lot of talk without any action or output. Timelines hold the markers on the horizon and the ports of destination (guess I'm sticking with a nautical analogy) that help reassure the ship's crew (organization) it's moving in the correct direction; they make the upcoming change real and give accountability to the change's progress. Planning is more in-depth than these brief generalizations, but the important piece to remember with planning is that change leaders need to know what his happening when and who is responsible - that is what keeps the change moving forward. Now, we need to take a step back to view a bigger picture.
The Plan of Attack pillar begins with asking, "How are we approaching this change to build and then execute the plan?" What does that look like to get started? There are several questions to answer first, and the answers will help identify the starting direction. The prototypical user story provides a solid format for answering these questions with the structure of, "As a (insert role/customer), I want to (insert action) so that (state received value)." This format covers three pieces that form a change's north star:
Who the change is for or who is impacted
The desired change
Intended outcomes
Let's try an easy example that focuses on delivering new functionality: As a parent, I want to be able to see what my kids are doing across all their electronic devices (i.e., game systems, phone, computer) and be able to set universal allowances and restrictions to govern their interactions so we can establish consistent responsibility, expectations, and routine without having to manage each device separately. (Seriously, if something like this already exists, I need it in my life.) Okay, we have answers for our initial questions, so how does the plan of attack begin to take shape? In this scenario, there needs to be a period of discovery where we are exploring what current functionality exists and establish more detail for what, ultimately, the customer wants to see in a delivered product. Then, we would look at technical capabilities, design, and prototyping. Assuming achieving the desired outcomes is doable, we then move into development, testing, and feedback. Lastly, after using the customer's continuous feedback throughout the development process, we can train, deliver, and support. Ideally, the functionality is top-notch and the customers are satisfied. Everyone gets a pat on the back and pizza. (That is a joke too, by the way. I'll never turn down free pizza, but we should be putting more effort into acknowledging and celebrating accomplishments.)
Now, let's move to a higher level and see how this applies to organizational change, where communication and transition planning are a more significant slice of the pie. As a growing IT organization, we need to implement a new system of record that allows the organization to manage projects, programs, and portfolios and allows individuals to input where they are expending their effort in order to establish priorities, track work progress, and identify personnel needs. Sounds potentially awful, doesn't it? Yet, for any growing or project-heavy organization, keeping track of people and work on spreadsheets or within the collective memory of the people quickly loses viability. This organization sounds as though they are seeking this change for the right reasons rather than simply for the sake of having a shiny portfolio, project, and time management system. Still, implementing such a system and then being able to derive value from it can be disruptive to how people work. It is something new, and "new" is always met with a degree of concern. So what is this scenario's plan of attack? There are going to be a lot of pieces that go into finding the right system to implement, an example is looking at budget, needs, and usability, among a plethora of factors. While that is important, there needs to be an established plan for the people. If the organization is moving forward with implementing this system no matter what, it would be fair to introduce the concept to those impacted within the organization and focus on what the communication will be throughout the process into training, implementation, and ongoing support. First, who needs to be involved in any conversations or presentations? How are those going to happen and at what cadence? Then, who is going to be responsible for these conversations and status reporting. Once there are guidelines in place, we can explore what the actual communication is going to look like. For the initial mass communication, the introduction of a future change, the "why" behind the change needs to be clearly stated and reiterated, the communication plan for during the process should be established and shared, and the icing on the cake will be stating the expected value for everyone in the end. Do you see the pattern at the foundation of all change by this point? Regardless of a change's stage, it is of paramount importance to ensure the "why" is known and understood as well as the value of the change's end state.
Communication is, of course, only one piece of planning. We are not at the stage, however, where the intricate details need to be figured out; we're still painting with broad strokes. One of the other planning components is determining how the change will be implemented, from the level of determining project approach (i.e., Agile, traditional waterfall), skillset requirements, and timeline. Some changes will not be technical in nature, but that does not necessarily exclude these changes from being run as a project. There will always be value in establishing specific tasks and estimating complexity while ensuring there are frequent check-ins and showcases for stakeholders. Additionally, giving a thorough review of the necessary implementation skillsets will help prevent surprises further along in the process.
Another plan of attack piece is assembling the team or teams to spearhead and implement the change, which will likely have a ripple effect on other initiatives and timelines. From experience, few people are ever dedicated to a sole pursuit. Having a full plate with priorities that pull in multiple directions is commonplace, and if a group of individuals need to include or shift to a new endeavor, there will be transition and preparation periods to accommodate. Often times, without explicit permission from leadership to set work aside and focus, team members will not feel empowered to manage their time and priorities, which then forces them to juggle an additional responsibility. The ability to generate agreement on those topics to move forward requires significant conversation and alignment with organizational leaders. As with most things, if the change is not considered a priority, it will fail to launch.
Having an initial plan of attack will help get you through the early stages of a change and should only be the vanguard of overall planning. While organizational changes, projects, or transformations seldom capture the magic of a trip to Disney, that does not mean they have to be a tooth-pulling undertaking. Focusing on communication and establishing alignment on key topics like timeline and personnel will help navigating change feel more like a choreographed exercise than "let's hope for the best".