In general, an implementation of Microsoft Enterprise Project Management (EPM) is done to replace or supplement the existing the project management and resource management systems and processes.This kind of change impacts most, if not all, levels of the organization,especially, the end users who have to live the “new life” after the implementation.
In this scenario, it seems obvious that a structured change management approach is needed. However, based on my experience, often change management in a MicrosoftEPM implementation doesn’t get the same attention asthe solution and process design and the related technical set-up.
In this article I point out few approaches to consider for your change management process that have worked for me in the past. Although the article focuses on a Microsoft EPM implementation, a lot of what I cover isn’t very different from the change management process you’d follow for any other project.
1. Understand that This is a Project, Like Any Other
A Project Server implementation is a project by itself. It encompasses more than just the provisioning of servers, deployment of the software from Microsoft, or training your teams. It includes internal stakeholder management, gate checks, management of deliverables, and so on. Engaging a Microsoft partner or consultant to help you with implementation will address the area of the solution or process design and development. However, as a third-party it may not be in tune with your organization’s culture and are not in a position to help you manage your project, especially the change management aspects. So realize that the organization implementing Microsoft EPM — not the partner or consultant — owns the project.
2. Plan the Change
There are three main areas that you need to focus while trying to execute change management:
- Stakeholder management
- Communication
- Training
Develop plans for managing all three areas. Conduct a stakeholder analysis; develop a stakeholder management plan, and develop a communication strategy and a training strategy right from the beginning.
3. Form an Internal Reference Team
You’ll need help! Each group in your organization will have its own ways of communicating, doing training, etc. Establish a reference team that has at least one representative from every group that will be impacted by the implementation. Alternatively, identify key people as “change leaders.” These leads will have the responsibility of building support for change as it happens within their individual groups.
4. Develop a Communications Strategy
Communications about the Project Server implementation shouldn’t be limited to a “go live” date. Once your organization has seen the proof of concept and management buy-in has been established, then the teams need to start hearing about the activities of the project, whether they’re active or passive participants. Lack of information causes apprehension and confusion.
Some tips:
- Develop a “goal” for your communications. Remember, your purpose is to take your team members through the “I am aware” to “I understand” to “Count me in” stages.
- Have a weekly status meeting with the reference team, where you can present the project status. The presentation should include both the status of technical implementation and also discussion about other organizational elements.
- Develop a weekly (or whatever frequency is necessary) newsletter, about the Project Server implementation. Have your early adopters share their experiences by writing articles about other companies that have walked the path before. There is a great deal of documentation from Microsoft that you can use.
- Send regular updates to upper-level management. They need to know whats happening since their support is essential to the success of the effort.
- Have a small-scale help center. This can be a person, email box, or phone number where people have a forum to voice their opinions and concerns. The fact that their concerns are being heard goes a long way with team members in developing buy-in for change.
- Develop posters of the project roadmap and position them in high traffic areas.
5. Develop a Training Strategy
Before you start training, develop a training plan. You should identify what the objectives of the training are, who the audience is for each type of training, a schedule, modes of delivery, and training sustainability.
Here are some tips for tackling this area:
- Evaluate training needs before you launch training. A mistake I made done in the past was to assumethe training mode. While instructor-led training might work for some groups, computer-based training may be better forothers. The same goes for the training material. Some people may want manuals while others may prefer PowerPoint presentations. Understand the needs before beginning training preparation.
- Do a pilot round of training for select individuals, preferably the reference team, and collect feedback. The feedback could be totally different from what you thought and will give you a chance to change your training before you go live with it.
- Plan for the training of “masses.” If it’s instructor-led, plan for ample time for multiple sessions for all groups so that people can pick the best time suited for them. This means that training can’t simply happen just two weeks before the go-live date.
- Consider developing computer-based or web-based training. In scenarios where you need to train the masses or several remote users this might prove to be better way to go.
- Think about making training sustainable. Training isn’t a one-time event and will always be on-going. Establish a process for getting Project Server training. Anybody who needs training in the future shouldn’t be confused by the process of obtaining it.
- Capture the issues and discussions that happen during the testing and beyond in a central list on Project Web Access. The documented resolutions to these issues could be an immensely valuable “How do I…” tool for you. The Microsoft Project Server Forums are a great example of this.
- Develop quick reference sheets, with a focus on the “daily activities” that a team member would do in the context of Project Server 2010.
While there’s always more on this topic that could be useful, the points I’ve covered are the ones I’ve seen surface time and again during a Microsoft EPM implementation. The important piece to remember is that change management is an essential project in its own right and you’ll want to address it in a planned way for best impact.
