(Working on my presentation on EPM Deployment Best Practices, and decided to work out a couple of ideas via blog posting.) As I think nobody would argue, a significant part of the EPM deployment story is of course in the training deployment – yet, often the training component is either an afterthought, not paid attention to, or simply delivered at the end of a consulting engagement, right before going live with the pilot deployment. This post is my attempt to put my thoughts on paper and try to organize them into some semblance of a coherent narrative.
The Role of Training
The first thing we need to do is to really understand the role of training in the deployment of an enterprise change initiative such as an EPM tool deployment. It sometimes seems that many in the non-training fields see the act of delivering training as simply imparting knowledge from the “fountain” of the instructor to the “empty vessel” of the student. In a complex endeavor such as an EPM tool deployment, training actually performs several roles and if successful fulfills the purpose of multidirectional communication between the participants in the system.
Here’re a couple training value propositions that I’ve identified:
1) Epistemological – It is a demonstrable fact that most project managers who have worked with the same organization for a number of years, and who are faced with an impending EPM implementation, do not know what they do not know. I’ve had experienced professionals sit down in my Microsoft Project Level 1 class and draw an absolute blank when faced with the challenge of describing their duration estimating methodology, or when confronted with the cognitive dissonance of why the schedule critical path is impossible to achieve. They haven’t realized that they have a process gap until we start working methodically through the schedule development process with the intent of documenting shared processes in a organizational schedule management plan (see previous posts here and here). It is for this reason that I like to do the basic desktop tool scheduling training very early in an EPM implementation – if not even before the client has committed to EPM as this gives them a good taste for what issues will have to be ironed out to move to a shared project management methodology.
2) Requirements Gathering – Many requirements for an EPM implementation can be defined in a training environment as students share how they manage their schedules and come to agreement on key issues such as defining schedule contingency for key milestones, or discuss task coding requirements and specific custom fields required. I’ve always looked at training as an easy, cost-efficient way to jump start the requirements definition process for an EPM tool deployment.
3) Consensus Building – As the requirements are defined, and as the class members volunteer how they already manage their own projects, a group consensus will hopefully emerge. As the consensus emerges, ownership is retained by the class members, and the eventual implementation becomes much stickier as a result. Alternately, disconnects will become more obvious as different class factions disagree on specific approaches. Note that for consensus to be built in a class, the students have to be empowered to define many of the requirements for the implementation – or the key decision maker must participate.
Early on in the implementation, this phenomenon can be quite easy to manage. Later on, after many of the requirements have been set, the requirements become more of a fait accompli and it’s harder to grant ownership of the issue to the students. One of the ways to deal with this specific issue is to identify some of the internally respected power users from the earlier wave of training (whom Gladwell calls the Mavens), and invite them back to attend the later training as guests or facilitators. This allows them to explain the thinking behind key design decisions, and to describe the various points of view that were already considered.
4) Organizational Change Management – What a lot of the above topics roll up to, in effect, is selling the change – if that is even the correct way of phrasing change management. From my perspective, there’s no need to sell anything if the requirements for the change actually came from the people who will be required to support it. Then it’s not “selling,” but “implementing requested system improvements.” Nine times out of ten, it’s the project managers and end users who see the value of the new tool, and are the ones pushing for it to be implemented. Sometimes however, the implementation can be so ham handed and centrally imposed that this dynamic is lost and the end users unite in pushing back at the implementation.
At a basic level, pick a change model (I prefer the Satir Model myself), and ensure that your training efforts map closely to it.
The Logistics of Training
Every training delivery situation is different, but as a general rule, I’d recommend the following key training events. Note that this would have to be modified due to the geographic and cultural distribution of the organization, and based on how well the organization accepts the concepts of dynamic scheduling.
1) Basic Scheduling/Desktop Tools – as one of the earliest classes I attended when I got into this field pointed out….implementing enterprise tools such as Project Server doesn’t really change the daily job of the project manager (or scheduler) at all. The most significant impact on their job is that Project Server enables more efficient communication with the project resources. What EPM tools do provide however, is transparency into the individual schedules. Therefore, it behooves an organization to ensure that they can standardize their schedules and get commitment from the folks doing the scheduling before spending a lot of money on centralized tools. I generally recommend splitting this process into two pieces: Basic Schedule Development and Schedule Maintenance – with those two sessions delivered with a couple of weeks breathing room between them. Optionally, consider adding an Advanced Schedule Development session to standardize how to risk load schedules, if in fact the organization is ready for that.
2) Schedule Tools Refresher Course – Shortly before going live with the Pilot implementation, take the organization schedule management plan, and run the project managers through a training on that. See how much discussion or dissent still exists on some of the key elements, such as how to properly add buffer before federally mandated milestones. This class will give you a read on how well the scheduling processes have been adopted, field test the processes, and provide an opportunity for newer hires or project managers who didn’t make the first round of classes to participate.
3) Managing Projects with EPM Tools – Once we have the foundation in place, then we need to train our PMs on how to utilize the new functionality given to them by the EPM tool.
5) Team Member and Executive Training – the bread and butter of an EPM deployment. These training sessions are usually short and to the point. Consider inviting your respected Schedule Mavens to participate and share some of the thinking behind the system design. Consider also adding some gravitas to the change implementation model by pulling in references to other companies that have encountered much the same challenges.
In some organizations, particularly those heavily siloed organizations that have never actually had a shared interdepartmental project schedule, you may want to preface this session with another training on the Schedule as a Concept, with an emphasis on why interdependencies between departments matter.
6) Supplemental Training – You don’t just train and call it a day. There’re all sorts of supplemental training and materials that needs to be rolled out to support an ongoing EPM implementation. Materials need to be refreshed, and new staff members need to be onboarded. A successful implementation looks at these issues and has a solution in place.