Documents
Resources
Learning Center
Upload
Plans & pricing Sign in
Sign Out

Creating an EPM Deployment Plan - Microsoft

VIEWS: 2 PAGES: 8

									Creating an EPM Deployment Plan
By: Chris Vandersluis

“Can you help us install the EPM system and get it up and running in a few days?” is one of the
most common requests EPM deployment firms get. And regardless of the size of the
organization, the short answer, is unfortunately, “No.” The challenge isn’t technology; it’s a
series of policy, process, procedure and practice questions that have the potential to create far-
reaching organizational change.

Let’s take a look at what an EPM deployment plan must include and how you can create your
own. I’ve identified the major points and even put in estimated times for how long each phase
might take in a mid-sized organization with several hundred EPM system users. Before you
dismiss each time estimate as too short or too long, think about what you would need to do in
your particular organization in order to accomplish that section. The durations are not work
estimates, they are calendar estimates, so keep in mind how long it takes to get certain kinds of
people assembled for the kind of work you will need.
1. Establish the EPM System deployment team
If we have no project team then our project won’t go far. Several people will have to be
assembled in order to bring this project from the idea phase all the way to production. With an
overview plan already in mind, you will need to think about people who will be with the project
as long as a couple of years.

Key steps in this first phase are:

       Identify Key Stakeholders
       There’s often one key stakeholder before the project even starts. It’s usually someone
       at the executive level who is feeling the pain of not having this kind of system. That’s a
       great start but it won’t be nearly enough to bring such a project to fruition. Identifying the
       business owner of the system is critical to a successful EPM deployment and must be
       done almost immediately. The business owner will be the person who uses the benefits
       of the completed system and sees the value in going through what it will take to
       complete it. There may also be one or several executive sponsors. The executive
       sponsors might be management level staff who have some use for the ultimate results
       but they might also be people who will work on the project until its completion and then
       move on with little investment in the final operation of the EPM environment. You can
       live without an executive sponsor. You can’t live without a business owner.

       Identify internal expertise resources
       Having determined who the business owner and possibly the executive sponsors are,
       the project team should determine what internal expertise is needed and available to
       move the project forward. Often we’ll find a lack of expertise in a particular technology
       such as the current version of EPM software but that’s not the only kind of expertise we
       require. Internal knowledge of the organization’s processes, practices, procedures, roles
       and responsibilities and where data can be located to drive the process will be essential.

       Engage external expertise (if required)
       It’s common to determine that there is a knowledge or skill gap in the project team to
       move from non-enterprise project management to enterprise project management. If
       that’s the case, then there’s no substitute for finding someone with know-how. To
       whatever degree the internal resources are not available, they’ll need to be engaged
       from the outside. These people might be engaged as part of a consulting or outsourcing
       contract or hired for long term use in the environment that they will help develop.
       Training for this kind of expertise from the inside is rarely successful. The most common
       challenge we see in this area is finding out that the internal resources have been given
       the responsibility but don’t have the knowledge or have only a limited knowledge. “I
       used EPM software once and now I’m being asked to deploy it,” is a cry we hear all too
       often.

The size of your team will depend on how wide a scope the project ultimately becomes. It is not
uncommon to find some people with the project for several months who are then replaced with
others as phases of the project change. The authority of the team and the support of
management are also critical to establish at this time.

Oh, and do I need to say it? Treat this project as a project! Amazing as it might sound, EPM
deployments are the most likely project in the organization to be deployed without any of the
elements you’d put into any other deployment plan (something about a shoemaker’s children
going barefoot). So, make a project schedule, a budget, a charter, allocate sufficient resources
etc.

Time to accomplish this: Four weeks.


2. Identify Business Objectives
Ok, we’ve got the team together. Time to get it to work! We’ve got to now identify the scope of
the project, break that scope into phases if it’s big and then create a plan for the work.

Here’s what we’ll need to accomplish in this phase:


       Executive and Stakeholder workshops
       There’s no way to get around this. The whole purpose of creating an EPM environment
       is to better enable management and end users to make business decisions. So the
       relevant management personnel will need to invest some time at the beginning of the
       process to help identify what decisions will be made using the system. I’ve written about
       how to conduct such workshops in the past (See “How to be a Solution Buyer”) but how
       they’re done is less important than that they’re done. This is the opportunity for the
       deployment team to get two other very, very important things while they have
       management’s attention: First, the commitment of management to the process, the effort
       and the ultimate benefits. Second (and far more important), the managed expectations
       of management. The most common management expectation is that this can be
       accomplished in a few days or a few short weeks. When they grasp the impact of what’s
       involved, management support may evaporate. Better to have that happen immediately
       than to get started on something that can’t possibly be delivered with insufficient time or
       resources.

       The results from these workshops (yes, it may take more than one) will be the business
       objectives that will make up the scope and ultimately determine the schedule.
       Identify management role impact
       Once the business objectives have been agreed to by management, there will have to
       be a session or two identifying the impact on the roles and responsibilities of
       management. A common example often appears with resource capacity planning. In
       high tech firms, resource capacity planning is almost always a management request of
       the EPM system, yet who will have to get the authority in that process to allocate
       resources, manage conflicts, and prioritize the work of people in different departments?
       You won’t be able to solve these issues at this point as you have no defined process, but
       identifying who in the executive suite will be affected is important here so that you’ll be
       able to circle back to include them in the process when the time comes.

       Prioritize business objectives and create a Master Deployment Plan
       It’s almost certain that the plan should break into phases. With virtually every EPM
       deployment, the desires of management on what benefits the EPM system should
       deliver are vast. The prioritization of which objectives to go for first is an essential
       element of success at this point. Get the top two or perhaps three objectives put into a
       phase and push everything else downstream. Each phase should deliver a working,
       production EPM environment that is valuable in its own right.

       Establish milestones and metrics
       We’re project managers, aren’t we?! Let’s get some milestones into our project and
       commit to some measurable metrics. With any enterprise system deployment, making
       sure it’s staying on track is an important part of the process.

We should have enough information now to develop our overall schedule with detail for the first
phase.

Time for this work: Four weeks
Phase 1
For each phase there will be some tasks that need to be repeated. Steps 3 to 9 are all part of
one phase.
3. Inventory processes
Before we get anywhere close to the tools, we need to determine what processes will ultimately
need to be automated in this phase.

       What processes exist and can be adopted?
       We start with looking at what processes, practices, and procedures already exist in the
       organization for the business objectives identified in this phase and determine which can
       be adopted within the new EPM environment. There’s a two-sided benefit to finding
       existing processes that can be adapted with little or no work. First of all, they’re created
       already and known to the users. Secondly, adopting them makes a friend of the person
       who created them. They can now be named as a subject matter expert in that process
       and that eases deployment.

       What processes must be designed
       We never find all the processes, practices, and procedures we need, but we have to
       identify what’s missing. That can be harder than locating processes that exist already.
       You’re looking for what’s not there and that takes an experienced eye.
        Process whiteboard workshops
        For those processes that require work to be adapted or for processes that need to be
        created from scratch, you’ll need to get some workshop sessions with a white board
        underway. Walking through the process and all its implications is best done with the
        people who will live it once it’s done. Document everything.


        Resolve impacted management roles
        Remember when we identified which executives or managers might be implicated in the
        changes that would occur? Time to call them back. For any of the newly designed
        processes that affect roles, authority, hierarchy, or existing responsibilities, you’ll need to
        organize meetings to resolve them.

The final result of this is the draft of a process guide.

Time to accomplish the processes exercise: Four weeks.


4. Adopt, adapt, and design processes
        Review, adapt, and accept designed processes
        Not everyone will have been a part of every process exercise that happened in the last
        set of tasks. So, getting the draft of the new process guide published to the
        stakeholders, managers, and affected parties is essential. It’s quite common for this
        guide to go through several reviews and even for additional workshops to be scheduled
        to resolve conflicts in processes.

The output of this is a completed and accepted process document. Don’t be fooled, the
“accepted” aspect may take several rounds and even require executive intervention from the
highest level before it’s complete but without an accepted process, there’s nothing to automate.
The good news is, even if the deployment process stopped here, this is already of great value.
It is inevitable that those who work through these processes internally see things about their
organization that they had never considered. They will be more effective as a result starting
almost immediately.

Time to accomplish the completed process guide: Eight weeks


5. Evaluate and Select EPM Tools

        Prepare “problem statement” documents for vendors
        If you’ve read other articles I’ve done, you know that I believe strongly in giving potential
        vendors a description of your EPM problems and letting them tell you how they would
        solve them. After all, they say they’re in the solutions business? Great, have them
        design your solution. This is a little harder than making a spreadsheet of all the
        functions you would like, but it’s important.
       Solicit vendor responses
       Never do just one. You may already know who your preferred vendor is, but even if you
       think it’s the right one, get something to compare against. No two vendors will try to
       solve your problem the same way so be prepared to be surprised and keep an open
       mind.

       Short list
       Even if you’re looking at one product but several implementers, get down to who you’d
       like to meet in person.

       Vendor and implementer presentations
       Ahhh, demo day. There’s are many things of value to be had from looking at a
       demonstration but getting caught up in the flash of it isn’t one of them. Sales
       demonstrations are carefully orchestrated by all vendors. If you’re particularly excited
       over a view or a report or a dashboard, ask specifically, “How long would it take to
       develop that exact view?”

       Tool selection and acquisition
       Ok, time to make the big purchase. I know, you thought that was the starting point, back
       at the beginning of this article. Well, don’t worry. We’re finally here. Make your
       selection of the EPM system and get that purchase order on its way!

The end result of this phase is a shiny new EPM product sitting on your desk.

Time to accomplish this phase: Eight weeks.


6. Automation Design and configure
       Apply the process design document to the selected EPM tool
       Now that we know what the tool is we can start creating system design documents that
       start with our process document and end up in functional specifications. We’ll probably
       want a Development instance of our new EPM system installed so we can test or verify
       certain design criteria. For the first time, a system expert in the configuration of the
       actual system is required on board.

       Design and implement standards
       There are numerous standards that will have to be established. Each and every one of
       those standards carries implications in the system architecture and design. The
       calendar for example is often overlooked. Will we have one calendar or many? Will we
       have resource calendars? Who will have the authority to change them? Do we know
       the effects on the schedule and progress data of changing a resource calendar ? And
       so on …
       Here are some of the elements of our EPM system that we will need standards for:
         Calendars                                       Approval structures
         Naming conventions                              Project and task hierarchies
         Resource hierarchy                              WBS and other coding structures
         Resource load standards for                     Document management
           project and non-project work                   Communication templates
         Rates and costing standards                     Project templates
         Roles and responsibilities
        We’re also going to need some other design and even possible coding for elements that
       came out of our Phase One business objectives. Some of the elements that might have
       to be considered are:
         Design and implement custom                     Design and create workflow
           coding                                         Design and implement reporting
         Design and implement                            Design and create EPM tool
           dashboarding                                     training
         Design and create links to                      Review design with all affected
           external systems                                 parties

The result is an EPM tool that is ready to be taken out for a ride. It should have all the
configuration required to move into a working environment.

Time required for this phase can vary greatly depending on how much custom work was
required but we’ll say twelve weeks given we’ve restricted ourselves to the first phase.


7. Pilot EPM Tool
Now that we have our system ready to go, we must identify the pilot group and get them
working on it.

       Phase 1 install / configure / migrate data
       We’ll need to install the newly configured system in a pilot instance (not the development
       instance. We’ll continue to use that for future phases and as a support and training
       system). We’ll also need to update the configuration to match our development instance
       and migrate the pilot projects from whatever they’re in now into our new system.

       Training
       Training is the poor stepchild of project deployments. It’s often forgotten in a
       deployment plan. Make sure our pilot personnel get the training they need to use the
       system properly.

       Run active projects
       Now, have those pilot projects be managed based on the processes, practices,
       procedures and automation that you’ve spent so much time defining. The pilot needs to
       have a schedule itself that is often oriented around how long these projects will last.

       Lessons learned and document
       Once the pilot project is complete, it’s time to reassemble and see how what was
       created solved the challenges that were set for it. If there are adjustments, corrections,
       or basic changes to make, now is the time.

Time for a complete pilot project and review: Twelve weeks.
8. Roll out Phase 1 into production
       Go-live
       It’s time. Roll out the use of the new system to the appropriate users and migrate the
       appropriate data. Don’t forget training, support, and follow up as the system goes live

Time to rollout is highly dependent on the number of total users: Four weeks.
9. Review and Adapt Master Deployment Plan
       Review and adjust master plan in preparation for next phase
       The master plan probably hasn’t been looked at in months. Time to dust it off and see
       what was originally planned for Phase Two. It’s inevitable that the eyes that look at the
       next phase will see things differently. After all, they now have all the experience of the
       first phase.

Time to complete this phase: Two weeks.
10. Phase 2 – do steps 3 through 9 again
We’ve only completed phase one and as you look at future phases you’ll need to rework steps 3
through 9 (with the exception of step 5). Remember that each phase should result in a working
EPM production that leaves the organization more effective than it was before.

Have you been counting the durations for each of the steps for the first phase? It adds up to 58
weeks. Here’s a schedule of the summary steps defined above:




Now, every organization is different. There are many factors that affect the total duration of a
project. The most significant of these is the extent to which existing enterprise project
management processes are mature. Next is the size of the organization and its complexity. It is
obviously simpler to deploy an EPM system into an organization that is all located in one
building than it is for an organization that is spread across numerous divisions, offices, cities
and even countries.

In each deployment the schedule will look different and not always shorter. There is virtually
always pressure to make a schedule that can be accomplished in days or even weeks, but it’s
vital that more than just the installation of EPM software be considered in order to deliver a
successful deployment.
About the Author

Chris Vandersluis is the president and founder of Montreal, Canada–based HMS Software, a
Microsoft Gold Certified Partner. He has an economics degree from McGill University and over
24 years experience in the automation of project control systems. He is a long-standing member
of the Project Management Institute (PMI) and helped found the Montreal, Toronto, and Quebec
chapters of the Microsoft Project Association (MPA) users group. Publications for which Chris
has written include Fortune, Heavy Construction News, Computing Canada magazine, and
PMI’s PMNetwork, and he is a regular columnist for Project Times. He teaches Advanced
Project Management at McGill University and often speaks at project management association
functions across North America and around the world. HMS Software is the publisher of the
TimeControl project-oriented timekeeping system and has been a Microsoft Project Solution
Partner since 1995.

Chris Vandersluis can be contacted by e-mail at: chrisv@hmssoftware.ca

If you would like to read more EPM-related articles by Chris Vandersluis, see HMS’s EPM
Guidance site.

								
To top