3.9. Program Rollout
The activities you have engaged in so far (and I have certainly condensed them here) have brought you to the point of having a quality management system in place, backed up by a supporting process program. You have entered into the project with executive support and have chartered a process team. You have focused your efforts along very distinct lines, and then you and your team have built a program with the active help of the people who will ultimately use it. Then you piloted the program and fine-tuned it based on the results of the pilot. Now you are ready to roll out the program into the day-to-day business of the organization.
Program rollout is not so much about sprinting out of the blocks as it is about preparing the organization to move with you. To do this, you need to make sure you have a sound implementation plan in place. The implementation plan is a roadmap you can use to integrate the process program into the company's way of doing business. Such a plan typically includes the following:
As early as a draft is available, the implementation plan should be reviewed by executive management, by the partner groups, and by any potentially impacted parties. The plan is a significant change agent within the organization and thus needs the blessing of all these groups.
When you've developed the plan and it's been approved, it should be implemented with the same discipline you'd apply to any project within the organization. The program should be tracked according to its budget and schedule, its milestones and deliverables, and you should regularly monitor its progress.
Depending on the nature of your program and the scope of its reach, the rollout may last from a few to many weeks. The key here is to keep it under your guidance and control until you are sure it has been firmly cemented into placethat is, that it is being used how it should be used by the people who should use it, with only general mentoring and guidance by your team.
Here's a brief look at some considerations to help make program rollout a smooth process.
3.9.1. Identify Impacted Groups
You and your process team may be charged with creating the process program, with caring for it, with managing and maintaining it, but you're not really the owners. The owners are the groups impacted by the program, those who will adopt the program for their own use, who will rely on it to help them carry out their business activities. That's why it's important to identify these work groups as part of the rollout. By this point, you have worked closely with these groups, so there's no doubt now as to who they are. But it helps to document the relationship. It serves as an organizational link between the groups, your process team, and the process program.
3.9.2. Identify the Support Team
At this point in the evolution of the organizational process program, your role and the role of your team will begin to change. Up until now, you've been focusing on strategic activities. You've assembled the team, targeted improvement opportunities, and assessed the organization. With your team, you've developed a process program that fits with organizational business objectives. You'll continue with these strategic activities: process improvement is about their ongoing application. But now you'll need to begin focusing on more tactical activities. Your process team now moves from development into implementation. The team members are now going to need to work to help support the use of the program throughout the designated work groups.
It's important to identify your team members as taking on this support role. It serves as a show of executive commitment to the program's success. It also allies your team, in a public way, with the members of the work groups who'll be using the program. This support role is essential to your program's success. It might be the single most essential element.
Especially early on in program adoption, the work groups will rely heavily upon the support that your team provides. There will be a lot of hand-holding, a lot of very active participation from your team. And so it's important that the work groups know explicitly who they can call on for help, who will be available for guidance and assistance, and who will shepherd through the new activities they may be called on to perform.
3.9.3. Define Program Support Materials
The work groups that will be adopting the process program are naturally going to need access to it. As we saw earlier in this chapter, a process program can be made up of many elements: processes, procedures, templates, forms, checklists. Usually these will be managed from some form of repository. The work groups will need access to the material in this repository, but this will probably not be enough. In "Formal Training and Instruction," earlier in this chapter, I looked at the necessity of providing the work groups with the training they need in order to follow the program conscientiously. In much the same way, the groups will also need access to the kinds of support materials that will complement the training and provide an ongoing reference as work unfolds.
This typically includes items like guidelines, instructions, even sample artifacts. It can also include points of contact for coaches and mentors. And in sophisticated scenarios, it might include workflow management systems, hyperlinked manuals, or forms of e-learning and content management systems. The success of your program rollout will be greatly benefited by ensuring that this support material is identified and made available to the work groups.
3.9.4. Schedule the Rollout
You'll need a well-thought-out schedule to successfully implement the process program in the organization. The schedule will be used by you to manage the various implementation activities. It will be used by your process team as a way to guide delivery of their tasks and measure progress. And it will be used by the partner work groups to coordinate interactions while still managing daily business duties. Management may also use it as a way to monitor progress.
Keep two things in mind when developing the implementation schedule:
3.9.5. Establish Milestones and Target Dates
Plan the rollout of the process program as a series of distinct, measurable goals. If you create a schedule that accounts for the numerous and varied implementation activities, and you imbed into this schedule an implementation priority, you should have a structure that supports the identification of progress milestones, with target dates attached to them. These milestonesand how you identify themshould be geared to a single purpose: to chart the way for your teams to move through implementation activities. Defining these milestones is a way to introduce a logical order into the sequence of implementation activities.
It is also a way to segment activities into a series of mini-projects. Depending on the scope of your program, the overall implementation schedule may be large, and it may involve multiple teams, each with separate parts to play. Defining milestonesand linking them to specific deliverablesprovides a way to break down tasks and responsibilities into manageable chunks. Your process team can then use this segmented schedule as a way to manage time, direct focus, and coordinate work. The work groups can use it as a way to plan when their resources will be needed, and what these resources will need to be. And, of course, you will use it as a way to manage overall project activity and report status to the process team, the work groups, and upper management.