The Build Phase is when the new system comes to life. Packaged systems are customized to meet the client's requirements and reflect the agreed-to design. Custom systems are built from the ground up and can be viewed as a functioning program for the first time.
This is when the project really starts to get busy for Change Management. Up until now, you may have been feeling relaxed. You may even have felt guilty that you weren't working long hours like the rest of the team. Never fear...you are about to ramp up.
Communications
You should already be in a groove when it comes to communicating with Sponsors, project team members, and Super Users/Change Agents. Now is when you can begin end-user communications. I'll write another post where I go into more detail about how to generate a detailed end-user communication plan, but for now, here are suggestions about topics you might want to communicate:
- The Final Design: Design phase is complete. This is an excellent time to let people know what the new system will be capable of doing and what it will look like. I like to have two sets of messages here. First, I start with a high-level overview of the system design that explains how it will be used in an integrated fashion by the entire organization. Second, I follow up with department-specific communications that go into more detail about how the part of the system each group will use has been designed. Don't be afraid to name drop. If someone from the department helped design the system, mention that so that future end-users will feel comfortable that their needs were represented and the system wasn't designed in a vacuum by the project team.
- Project Timeline: Start communicating a high-level project timeline. I don't usually go into much detail at this point, because time lines change, but it doesn't hurt to let people know that training will be rolled out in Q2 and the Go-live will occur in Q3. This helps to 1) re-assure end users that you haven't forgotten about important activities such as training, 2) allows them to understand when changes will occur, and 3) reduces the sense of panic about an unknown future that develops when people don't have a general time frame for major changes.
- Benefits: The project should have a list of benefits that the new system will bring to the organization. Begin communicating these. Once again, you can have two sets of messages: one set for the organization as a whole, and one set that is department-specific. A word of warning: If there are no real benefits to the system implementation (and I've seen projects where this was the case), don't try to make them up. People can see through fluffy corporate jargon in seconds, and will read any future communications you send with a skeptical filter.
- Bonus: If you have screen shots (or even real demos) of the system that you can share, start doing it! People love pictures and demonstrations and they will get you a lot farther in building an understanding of the change than any e-mail or list of bullet points ever could. Just make sure that the screen shots are unlikely to change, and that demos actually work before sending them out.
Training
Now that the system is designed, you are able to create the training analysis. This is where you determine
who needs to be trained on
what parts of the system,
when this training needs to occur, and
how you will deliver the training. This is a tedious and time-intensive activity, but it is crucial. Not only will it allow you to create a detailed training curriculum, but it will also help you to determine the plan for creating all of the training, including how many training developers and deliverers you will need.
I strongly recommend that you get input from the functional teams, subject matter experts, and Super Users.
This is also a good time to have a meeting with the client's HR or training department. Ask them about past training they've implemented. What worked? What didn't? Are there certain unique aspects about the organization that could impact the timing or method of delivery? Remember - things like shift work, unions, hourly employees, and location can greatly impact your training plan.
Change Impact Assessment (CIA)
There are many variations on the Change Impact Assessment. The one I do has three components: people, process, and technology. This is designed to help the project, the Change team, and the organization's leadership understand how the new system will affect the organization: the good, the bad, and the ugly. You may find that the change will bring benefits to the organization across the board. Or you may find that one department is gaining a lot of benefits from the change, while another department is losing something that they consider vital to their work. Regardless of the results, it is important not to sugar coat the outcome. A frank understanding and discussion of the impact of the change will allow you to capitalize on the positive and address the negative.
There is some disagreement over the best time to conduct the CIA. Many projects will conduct it much earlier in the project. My experience, though, is that until the design is complete, people don't understand the new system well enough to give good insight into how it will be different from their current way of doing things.
- People: In this portion of the CIA, you focus on the impact to people. Will their day-to-day responsibilities change? Will you need more or less people to do the same tasks? Will they need to learn new skills? Are they open to change?
- Process: New systems often lead to new or change business processes. Is the organization moving from manual to automated processes? Are steps being added or removed? Will the roles involved in a process change? Will the length of time required to complete a process be more or less? Are new safeguards (e.g., authorizations, audit trails, etc.) being added to the process?
- Technology: This is a basic nuts-and-bolts comparison of existing technology against the new technology. In an organization where different departments or business units were allowed to select their own technology, you may find very different impacts. Especially in organizations where there are a lot of home-grown systems that were specifically designed for a department's individual needs, you are likely to find that people consider the new technology a step backward.
Organization Design
Now is a good time to start working with Human Resources to understand if there is an organization design component that is required as a result of the new technology. If there are new skills that are required, job descriptions, compensation structures, and responsibilities may need to change. Entire teams and departments and departments may need to be re-designed if the roles, responsibilities, and processes are changing drastically. You may also find that positions need to be added or eliminated based on the new system's ability to increase or decrease workload. Even if HR comes back and says they don't want to make any changes until they've seen the system in action for a few months (which is a response I've heard often), it's good to at least begin thinking about how the organization may need to adjust in response to the coming changes.
Let me know: How often is Organization Design part of the projects you work on?
