4
Creating the Path
At work, and outside work, you’ve probably seen and created lots of project plans. In your organization, you may have participated in or even led projects with a plan that laid out tasks to be completed, assigned people to each task, and set due dates. Or at school, you may have worked on a group project for which you sketched out a simple plan for how your team would get the assignment done. In your community, you may have collaborated on a project for which the steps, responsibilities, and timeframe were outlined. And you may have created your own simple plans for projects you’ve worked on independently—something you were expected to deliver by yourself at work, or an assignment you needed to complete on your own for school, or even a job you just wanted to get done around the house. You probably saw how these plans helped you focus on the goal you were working toward and organize the actions you needed to complete to achieve that goal. Maybe you used the plans to monitor your progress and figure out when you needed to make adjustments to get things done on time.
In this chapter, we’re going to take a look at the project plans you and your team create to support change initiatives at work and the components you can include in them. You’ll see that the project plan focuses on the hard side of change. It helps guide your organization forward in a disciplined way toward the outcome you’re shooting for. But the steps you take to create your project plan can determine the extent to which employees buy into and support your project. In other words, as you create your project plan, you need to keep your eyes focused on the soft side of change.
Later in this chapter, we’ll explore how you and your project team can address the soft side of change as you help prepare the project plan for your initiative. But first, it’s worth stressing why the project charter and the project plan are so important.
Don’t Skip the Project Charter or Project Plan
Are you and your team eager to get started with your change initiative? Are you tempted to skip past the project charter and jump right into creating a project plan? Maybe you think that everyone already knows what your project is trying to accomplish and why it’s so important. Why waste the time building a charter when you’re ready to dive right in?
Resist that temptation. For your change initiative to succeed, and for the project plan to serve its purpose of guiding you to your project outcome, you need to have a clear sense of the goal you are shooting for and the business purpose for reaching that goal. You need to have a shared understanding of what the change initiative will deliver, what will change, and what won’t change. And you need to secure senior leadership support for the change and ensure they understand their role and responsibilities as it relates to the project. Before you begin creating your project plan, create a project charter. A simple one will do. If you’re in doubt, reread chapter 3 before proceeding here.
Or maybe you’re tempted to skip creating a project plan too. Avoid that mistake. As project management expert Andrew Conrad (2019) writes, “Starting a project without a plan is like taking a trip without a map. You might eventually get where you’re trying to go, but not without wasting a lot of time and money.” Without a well-constructed plan, your project team risks straying, and beginning work on tasks, features, and functionality that fall outside the scope of what you and your organization are trying to accomplish. You may end up missing deadlines and blowing budgets.
A project plan provides you with a structure and a road map for proceeding with your project. It helps you clarify the steps needed to get to your goal and the order in which these steps need to be taken. It helps you track progress and figure out where adjustments may be needed. It helps you create accountability and ownership for work that needs to be performed. And it helps you communicate the progress your organization is making. Have a plan.
Let me share a brief story of learning the hard way about the value a project charter and project plan can provide. I was working with a vice president of HR who’d asked me to head up a project to “fix new employee onboarding.” Eager to help out, I assembled a project team, and we dove right in without a project charter or plan to guide us. At first our team discussions seemed pleasant and productive enough. But as the months progressed, team members began to express frustration over our lack of focus and started skipping project meetings. Apparently, some had joined the team expecting that they’d create an orientation program that would help new hires understand their medical and retirement benefits. Others assumed they’d be addressing the role that supervisors play during a new hire’s first year of employment. Still others thought they’d be working on logistical gaps in the onboarding process; they wanted to make sure new hires received laptops and appropriate systems access their first day on the job. By not articulating a clear sense of what our team was expected to deliver, by when, and with what value to our organization, I had allowed our team to just wander. We weren’t accomplishing anything. And as project leader, this was all my fault.
Trust me, the vice president of HR noticed. I had the same tense discussion with my VP as Anil, whom we met in chapter 1, did with his. Our conversation wasn’t pretty. But fortunately, I was given an opportunity to recover. I realized our project needed to proceed in two phases—one focused on assessing the organization’s issues with new employee onboarding, and a second focused on addressing the highest-priority needs we uncovered through this needs assessment. And I also realized, with the help of the VP, that I needed to prepare a project charter and project plan that would spell out what our team committed to deliver, the steps we’d complete to help get us there, who was responsible for each task, and expected completion dates. Once that was clear, I reassembled the team. And this time, we produced results that really did address our organization’s needs and interests. We were late, because I first needed to learn my lesson about the importance of having a clear project charter and project plan. But eventually, we did help improve the new employee onboarding experience.
What’s in Your Plan?
OK, perhaps you’re convinced that you need a plan for your change initiative. But you still may think, why spend time looking at how the plan is created or what goes into it? Isn’t that a project management function? Shouldn’t the project leader create the project plan?
Well, yes they should. Usually, your project leader, with input from the project sponsor, project team members, and key stakeholders, will create the plan. Your role, as you lead and support change management for the initiative, is to review and provide input for that plan—and for the steps your team takes to create it—so the plan adequately addresses the soft side of change. You’ll make sure your project team provides stakeholders with the opportunity to review and provide input for the plan. And you’ll make sure that tasks related to stakeholder engagement, communication, and training are included in the plan so they align with everything else that’s happening on the project. You probably won’t take the lead creating the project plan, but you do need to understand what’s in it, why, and the implications for building employee buy-in.
Let’s take a quick look at the general components included in most project plans. Then we’ll talk more about what you can do to ensure that the plan addresses the soft side of change.
Project Tasks
The project plan for your change initiative should list all the work that needs to be performed from the time the project begins to when it is completed. As your project leader drafts the plan, they may break down the project into its key elements and include steps for planning or designing each of these elements, creating them, reviewing them, making revisions, and finalizing them. For example, in the case study found in chapter 2, we saw a project plan that included steps for configuring a new job application (see Table 2-2). The tasks included:
• Design the application form.
• Build the application form.
• Review and approve the application form.
• Revise the application form based on feedback.
• Conduct a final review and approval of the application form.
In the project plan your project leader creates, you also may see tasks related to project planning and project management. For example, the project plan presented in chapter 2 included tasks like:
• A project kickoff meeting and scope confirmation
• Scheduling weekly implementation meetings
To make it easier to track and manage the status of your project, your project leader may organize tasks into milestones. A milestone is an event or interim stage that signals that a group of related tasks has been completed. It’s still important to finish each individual task by its due date. But the milestone gives you an overarching target date to work toward for a group of tasks that belong together. It serves as a marker that you have advanced the project through a key stage.
For example, when you were in college, you may have considered the end of your freshman year to be a milestone. During your freshman year, you worked on tasks—in the form of completing classes—that helped you achieve the milestone of ending your status as a freshman. Finishing the requirements for your freshman year and advancing to sophomore status served as a marker that you were making progress toward completing your degree.
In the DBZ applicant tracking system case, the project plan grouped tasks related to initial project planning under the milestone of Analysis/Planning. Likewise, the plan grouped tasks related to designing, building, reviewing, revising, and finalizing the application and cover letter forms under the milestone of Configuration. Although the case study just shows pages 1 and 9 of the project plan, the full plan likely included many other milestones, such as System Testing, User Training, and Migration From the Old System. Each of these milestones served as a marker that Max and the team were making headway with the applicant tracking system project.
Milestones help you keep tasks organized. But they also help show your project team, organizational leaders, and project stakeholders that you are making progress. A milestone provides a marker to take notice of. You are partway there. Your hard work is beginning to pay off. You’ve achieved something that you can celebrate.
Timeframe
When does each task need to be finished by? For simple, short projects, your project plan may just indicate the date when each task needs to be completed. For more complex and lengthy projects, the plan may include other information in addition to the finish date, such as the start date, duration (expressed in days or weeks), and percent complete. These additional elements can help you and your team better track progress as you work on the many steps needed to bring the project to its conclusion. That’s what Max saw in the project plan he reviewed in the DBZ case. The project was expected to take about nine months to complete.
As your project leader assigns timeframes to the tasks listed in the project plan, they’ll consider task order and task dependencies. Some tasks need to be completed in a certain order to make sense. For example, in the DBZ case, it probably makes sense to notify recruiters about the upcoming project before notifying hiring managers. Although both recruiters and hiring managers are affected by the change initiative, the impact on recruiters is far more significant. So the project plan should show an earlier completion date for the task of informing recruiters than the task of informing hiring managers.
Likewise, certain tasks must be completed before work on another task can begin. In other words, one task may be dependent on another. The start date and finish dates included in the project plan need to reflect those dependencies. For example, at DBZ, the task of designing how recruiters will post vacancies to the new system likely needs to be completed before Max can begin the task of developing training for that new process. As your project leader assigns a timeframe to each task in the project plan, they’ll think about task order and task dependencies, and make sure the dates they assign make sense.
Owner
Who is responsible for ensuring each task is completed? To build ownership and accountability, the plan should list the name of the specific person responsible for getting each task done. For example, in the DBZ case, instead of saying that the training plan will be prepared by the “change management team,” Max is listed by name as the person responsible for getting that work done.
Some organizations include additional elements—such as status or comments—in their project plans. If your organization provides a standard format or template for creating project plans, become familiar with it. A template can help you save time as you define the change management tasks related to stakeholder analysis, communication, and training, which need to be incorporated into the overall project plan. By using the format that others in your organization are already used to seeing, you can help them save time as they read and review the part of the plan that you’re responsible for providing. Of course, you and your team can create a project plan using a simple spreadsheet. And there are lots of software packages available that can help you build one too. If your organization provides you with access to one of these software packages, use it! By using a tool your organization already endorses, you’ll build credibility and make it that much easier for everyone to get on board with your change initiative.
Addressing the Soft Side
Much of what we’ve discussed so far in this chapter addresses the hard side of change. We’ve looked at how you can create a project plan that helps you make progress on the outcomes you’re supposed to deliver. But for the project plan to really serve its purpose of guiding your organization to its desired future state, you and your team need to organize project deliverables and tasks in a way that show people that their hard work and sacrifices are paying off. You need to provide opportunities for stakeholders to contribute to the development of the plan so they feel like it is relevant and realistic. And you need to incorporate activities related to engaging with stakeholders, communicating, and training into the plan so actions that address stakeholder needs and concerns are given priority and not considered a mere afterthought. As you and your project team create the project plan, you need to focus on the soft side of change. Let’s take a closer look at how.
Create Short-Term Wins
As you plan how your project will unfold—identifying tasks and organizing them into milestones—one of the most significant actions you and your team can take is to plan ways for the project to deliver short-term wins. A short-term win is a benefit your project delivers before the project has reached its conclusion. It’s an outcome that produces some value to your organization while your project is still ongoing. It’s an interim result that stakeholders can experience for themselves and lets them know that the project is beginning to yield benefits before it’s even complete.
Why are short-term wins so important? According to change management guru John Kotter (1996), they provide people with concrete evidence that the organization is embarking on a successful endeavor. This is especially important if other change initiatives conducted in your organization have recently failed. Short-term wins help you demonstrate that this change initiative will be different, because it’s already producing valuable results. They show those who doubt the value or viability of your change initiative that the project can and will benefit your organization. They can help quell the cynics and naysayers and turn people who are sitting on the fence into supporters. And they can provide the evidence people need to get on board—or at least to stop actively resisting.
Ideally, your project team will find a way to structure your project so that it delivers multiple short-term wins over the course of the entire project. This may come in the form of introducing the change to a small portion of your organization before the change is rolled out enterprise-wide. Perhaps you can implement the change initiative department by department or region by region. If the change initiative involves implementing new technology, you may be able to introduce new features and functionality over the course of the system implementation, rather than waiting until the end of the project, when all the functionality is live. Or maybe you can introduce some new work processes first, before the associated new technology comes on board, so employees can experience a more streamlined workflow before they begin using the updated systems. However you do it, look for ways to plan your change initiative so people can see and experience the project generating value before the project reaches its end.
For example, a large university wanted to change the approach it used to staff temporary positions, so that significantly more employment opportunities were provided to students. The university released new guidelines that required managers to post most temporary jobs on the university’s student employment website for one week. If they weren’t able to find a student with the appropriate qualifications during that week, only then could the manager approach a temporary staffing agency to fill the vacancy with a nonstudent. The university announced that the plan was to initially launch these new guidelines in three administrative departments, which would test the approach. Following that pilot test, the new guidelines would be phased in over a three-month period across the rest of the university.
Many managers initially balked at the announcement. Although they supported the idea of providing employment opportunities to students, they doubted whether the approach would work in their part of the university. After all, they complained, the work performed in their area was unique. When they hired a temporary worker, they needed to bring on board someone who had specialized skills—the kinds of skills not typically found in student workers. And yet, within weeks of launching the test, news started circulating across the university about how well the plan was working. Managers in the three administrative departments where the approach first launched started to share glowing testimonials about the student workers they’d brought on board. These student employees had sorely needed software skills and administrative capabilities that the managers quickly pressed into service. And because the student workers were paid through the university payroll system, managers avoided paying overhead fees to the temporary staffing firms too. The new approach gave managers temporary staff who had the right skills at a reduced cost. And it helped the university make progress toward achieving its overall goal of increasing student employment. Based on news of these early wins, managers in several departments not included in the early rollout began to implement the idea in their part of the university before it was required. The early evidence convinced them to try out the idea.
Planning for short term wins also can help you test out strategies and refine them as your project unfolds (Kotter 1996). For example, when the university tested the new temporary staffing guidelines in three departments, it quickly discovered that its procedures for handling student-worker timesheets were cumbersome and needed to be updated. The university changed these procedures before the new guidelines were rolled out university-wide. During the test, the university also found that the guidelines worked well for certain kinds of temporary staffing needs, but didn’t work as well for other kinds of positions. So, it refined the guidelines to identify the specific types of temporary positions managers should seek student workers to fill. Managers could continue to rely on temporary agencies to fill vacancies that were not listed in the guidelines. Planning for a short-term win helped the university uncover and address issues before they were experienced on a larger scale. It helped the university avoid unnecessary, but valid, pushback and complaints.
Short-term wins let people know that the sacrifices they’re making to implement your change initiative are worth it. It helps people see that their hard work is beginning to pay off (Kotter 1996). For example, when organizations implement large-scale enterprise resource planning (ERP) systems that affect employees in just about every functional area across the organization, they typically plan their rollout to occur in a series of phases that unfold over several years. During these years, day-to-day work can become more challenging—at least temporarily—for employees. All the planning and disruption that goes into switching processes and technology can feel like a real slog, and employees may stress over having to relearn tools required for them to perform their jobs. Organizations that are most successful at implementing these systems find ways to engineer into their plans multiple short-term wins that unfold throughout the course of the project. They implement one or two features or functions at a time—something that makes work better or easier for employees—so employees begin experiencing the benefits that the new system is intended to provide as soon as possible. (Think Agile!) The ERP implementation may still take years to complete, and may still be disruptive, but employees see early on that their struggles are worth it.
And finally, short-term wins help keep senior leaders engaged, and their active and visible support is critically important to keeping others across the organization on board (Kotter 1996). Project sponsors and senior leaders usually focus on the business outcomes that change initiatives are expected to deliver. A short-term win can provide leaders with the concrete evidence they need to confirm that their organization is on the right path. Armed with this evidence, leaders are more willing to advocate for the initiative as they communicate with the larger organization.
So whether you’re preparing a project plan—or reviewing and providing input on a plan created by your project leader—look for opportunities to incorporate short-term wins. They can help you increase stakeholders’ sense of confidence that the change initiative will succeed. They’ll help you build support and quiet resistance, so people will be more likely to try out the change. They’ll help you fine-tune plans and avoid unnecessary errors. And they’ll help you keep senior leaders and project sponsors engaged, so they’re more likely to demonstrate active support for your project (Kotter 1996).
Involve Stakeholders
For people to feel like the project plan is viable and realistic—that it provides a good path to help the organization reach its goal—they need to see that input and guidance was sought from those who will be most significantly affected by the change. People need to see that the plan is based on credible knowledge and insight—that the leaders and team members planning the change have an accurate sense of the way things currently function before they begin to change things. For people to believe that your project plan is workable, they need to know that you and your team involved stakeholders appropriately in developing the plan. And quite honestly, you need to involve stakeholders for your plan to actually be workable too.
Encourage your project leader to use an iterative approach when they create the project plan, wherein multiple drafts are prepared and then refined based on input gathered from an ever-widening circle of people who are affected by the project. For example, your project leader may collaborate with the project sponsor to prepare an initial draft. Next, they might ask you to review the plan from a change management perspective. That’s your opportunity to add in details related to stakeholder engagement, communication, and training. At the same time, your project leader may ask the core project team for their review from a functional and technical perspective. Your project leader then may share a version of the plan that’s been updated to incorporate all this feedback with key stakeholders—perhaps supervisors of the areas most affected by the change. And later you have an opportunity to share a further modified version of the plan with additional stakeholders—for example, members of the transition monitoring team, if your organization is using that approach (see chapter 7 for more information about creating a transition monitoring team), and members of your red team (see chapter 8 to learn why and how to create a red team). Each time the plan is reviewed by another group of stakeholders, you, your project leader, and the project team should be gathering and incorporating information that makes the project plan more complete and realistic. Gaps in the plan should be addressed. Missing steps should be added. Unworkable timeframes should be changed.
That’s the approach that Kevin, Bonita, and Max may have used in the DBZ case you read in chapter 2. We know that Kevin, in his role as project leader, and Bonita, in her role as project sponsor, collaborated to create an initial draft of a project plan. They shared the first draft with Max, who was serving as change management leader on the project, to gather his input. Kevin and Bonita also may have planned to share the project plan with members of their core project team, after the plan was updated to reflect Max’s input. And after that, they may have shared the plan with recruiters most affected by the system implementation to secure their feedback and guidance. By using an iterative approach, gathering input from additional groups of stakeholders and refining the project plan to reflect their guidance, DBZ could create a more complete and realistic plan. With each iteration, they could identify and incorporate improvements that would increase the odds that their project would succeed.
By involving stakeholders in the process of creating the project plan, DBZ also would send an early signal that the company intended to follow an inclusive process as the project unfolded. It would let recruiters know that their input and ideas mattered—that their involvement was in fact essential for getting the project started on the right foot. Including stakeholders in the development of the project plan would help DBZ create a more workable plan and help the company secure the support of those most significantly affected by the initiative.
One final comment here: As you, your project leader, and team prepare draft versions of the project plan, avoid accidently disrespecting stakeholders by specifying details about tasks you need them to complete when you really don’t know anything about the work involved. Don’t make assumptions about how they’ll perform a task or about the amount of time they’ll need to complete it. Just let stakeholders know what you need them to accomplish and ask them to provide the detailed steps.
For example, if you know that a website needs to be created by your organization’s IT team, but you are unfamiliar with the work entailed to get that done, just include in the project plan the expected outcome (“website created”) and ask the IT team to provide the detailed tasks—such as design, programming, and testing—and due dates associated with that outcome. Then update your plan to include the details the stakeholder provided. Likewise, don’t assume that you know the amount of effort an area needs to complete a task. If you don’t know how long it will take a stakeholder to get work done, just list the task on the project plan with an expected due date, and ask the stakeholder to provide the date that work on the task will need to begin for them to get the work done on time. For more information about involving stakeholders in the process of creating a project plan, check out Lou Russell’s insightful book Project Management for Trainers.
Incorporate Soft-Side Tasks Into the Project Plan
Your project plan should spell out all of the work that needs to be completed to bring your change initiative to fruition. And that means that activities such as creating the stakeholder analysis, creating and executing a communications plan, and preparing and delivering training need to be incorporated into your overall project plan. It’s OK to have the details of these activities described in separate documents. But the key tasks and due dates defined in these plans need to be listed in your main project plan too. Tasks that address the soft side of change—actions that focus on building awareness, knowledge, and support for your change initiative—need to be planned, executed, and monitored just like any other task in your plan. Make sure these tasks aren’t included as an afterthought. They need to be listed as important steps in your overall plan, just like any other task.
Why is this so important? Well, all too often, when organizations plan major change initiatives, activities that address the people side of change are given short shrift. In the rush to get things done, organizations focus on activities needed to install new technology or relocate people and equipment or redefine job descriptions and reporting relationships. They lose sight of the activities needed to help people navigate through these changes—actions that address communications, training, support building, and resistance. And yet, many change initiatives fail when the team ignores these soft-side actions.
Including activities related to stakeholder analysis, communications, and training in your overall project plan gives these tasks visibility, and visibility creates accountability. As your organization implements its project plan, project sponsors and project leaders want to see progress being made on all of the tasks listed there. Including tasks that address the soft side of change in your plan creates the expectation that these tasks will be completed too. These tasks need resources assigned to them. They need to be monitored and tracked. They need to be discussed and reported on. Including soft-side tasks in your overall project plan signals that they are key to the success of the project, just like everything else.
So when you’re asked to lead or support change management for a project that’s happening in your organization, ask to get involved right from the start. Let your project leader know that you want to—you need to—review the project plan and provide input. You want the opportunity to ensure that the plan appropriately addresses the soft, people side of change. You want to ensure that tasks related to stakeholder engagement, communication, and training are included so they align with and support all the other tasks that are specified in the plan. And you’re willing to be held accountable for those tasks, just like everyone else on the project team.
About to Begin?
Have you been asked to lead or support change management for a project in your organization? Build credibility as a change leader by demonstrating your project management skills—by showing that you can not only support the organization through the soft side of change, but also contribute to managing the hard side of change. Learn how to speak the language of project management, and how to use project management tools such as the project charter and project plan. Find out what templates, tools, or software your organization uses to create project plans, and then use those same tools as you create the communications and training plans needed to support the change initiative. Having a consistent approach will make it easier to incorporate all the elements into the main project plan. And you’ll also show that you are a key part of the team, speaking the same “language” and using the same tools as everyone else who is working on the project.
To continue building your skill, create formal project charters and project plans for your own work-related initiatives. Practice on your own projects. And if you work in an organization that uses the Agile methodology to plan and execute projects, see if it makes sense to apply that same approach to your own work.
This chapter wraps up section 1. In it, we addressed the steps you can take to create a project charter and project plan. We discussed why it’s so important to clearly define the outcome your organization is shooting for—what’s changing and what isn’t—and to build a clear path that will lead your organization to that outcome. We discussed how there are lots of people that you and your team will need to get involved to develop and execute project charters and project plans that really work. Along the way, I mentioned project sponsors and project leaders, core project teams, change management leaders, stakeholders, and transition monitoring and red teams. A lot of people are involved in a change initiative. In section 2, we take a much closer look at all these people—and a few others too—who are so critical to the success of your change initiative. We’ll look at how you can help identify the right people to include in your change initiative and how you can involve them in the right way. Are you ready to meet them? Read on.
Learn more. Check out:
Project Management Institute. 2017. A Guide to the Project Management Body of Knowledge (PMBOK Guide).
Russell, L. 2015. Project Management for Trainers. Alexandria, VA: ATD Press.
Tarne, B. 2017. “Applying Agile Techniques to Change Management Projects.” In How Successful Organizations Implement Change, edited by Emad Aziz and Wanda Curlee. Newtown Square, PA: Project Management Institute.