Implementation project management
now that you bought it what do you do?
Client Implementation Manager, Hewitt Associates
The presentations are over. The vendor pens, calendars and coffee cups have been distributed. Everyone is thrilled with the purchase of the brand new software package. It doesn't matter what functions the software serves. Could be HR, finance, payroll, help desk, sales management, whatever. All that matters is it is guaranteed to make the company more efficient and save money, all at the same time. And you have been selected to manage the implementation of this cross-functional project. It is just what you were hoping for, another opportunity to excel. Welcome to a real life Dilbert cartoon.
So what do you do? You can start by attending the ‘Implementation Project Management: Now That You Bought What Do You Do' presentation. Clear-cut steps are going to demonstrate how you get the project moving, work with the vendor and establish the base of the implementation pyramid. By the time the session is over you will be ready to build your project team, determine expectations for today and tomorrow, capture requirements for phase 1, and build the infrastructure for a successful implementation.
Implementation projects take on many sizes, shapes and complexities. There are some components that tend to be universal across disciplines. Configuration and testing, conversion, interface and report components are fairly consistent no matter what software system you are implementing. So are the steps. Discovery, requirements, analysis, build, test, train and deploy are all common elements, though they may be called different names. The unique aspect of implementation project management is you are working hand in hand with a vendor configuring their application to your use. This presentation will touch on some of the issues that typically occur during an implementation project and will, hopefully, prepare you for the both the project and working with the vendor on a successful implementation.
Selecting the Core Project Team
Forming an Oversight Committee and Defining Roles
There are a number of options available when forming an oversight committee. A formal steering committee is the most common. Members of the steering committee typically meet with the project team on a specific, periodic basis. The project is reviewed at a high level, issues are brought forward and change orders are discussed. An alternate is the business process coordinator. The client designates specific individuals who already have a vested interest in a specific process. They work independently or with a sub-team and are tasked with ensuring the successful implementation of the process. The business process coordinator has the authority to make decisions on a timely basis, handling issues as they arise and, in some cases, has the ability to approve change orders. The business process coordinator reports directly to the project sponsor and can immediately escalate issues for quick resolution, eliminating the wait for a formal steering committee meeting.
Building a Team That Covers All the Core Competencies
One critical component to the success of the project is to assign knowledgeable people to the core competencies. Does your project involve data conversion? Then someone familiar with the legacy data structures needs to be involved. Are interfaces required? Who is familiar with the data and files layouts? There needs to be some level of configuration and testing. Again, someone experienced with performing the function in the legacy system has to be part of the project team. Are you going to rely on the vendor project manager to lead the project, supplying an internal point of contact, or have your own project manager? All of these questions need to be addressed.
In rare instances, clients bring in temporary employees to assume the legacy processing, so those experienced employees are available full-time to the project team. In the real world, employees are usually asked to participate in the project while performing their current job, though some functions may shift to others. As a project manager, you need to make an accurate assessment on how much time each team member is going to spend on the project and plan accordingly. When building a project plan don't put down a team member as a 100% participant when you know you'll be fortunate to get 50%. Most project plan tools allow you to make the distinction and will shift timeline accordingly to give you an accurate picture of how long tasks are going to take.
Few things are more disconcerting than having poor team chemistry. As a client, you usually have some leverage when it comes to the personnel assigned to your project by the vendor. Your own team members are a different matter. In some instances, albeit rare, you have the opportunity to select your team members. You are going to pick individuals who have two characteristics. They know what they are doing and work well in a team environment. And if you have to pick someone who has one trait or the other I lean toward works well with a team. By nature, projects have enough issues and conflicts without the additional burden of human conflict. And nothing creates more conflict than abrasive personalities and high maintenance individuals.
So what do you do if you end up with a team that borders on dysfunctional? Once you've identified which team members need coaching in how to work within a team, there are a number of options. You can try talking to the individual privately in an attempt to adjust behavior. If conflict is between two people, talk to them together to try to come to an understanding. In some cases, the person's manager may need to get involved. In rare instances, HR is brought into the mix.
Suppose you have an individual who needs to be on the team, though they cause team conflict, and their behavior cannot be adjusted. Try insulating the person from the rest of the team. Perhaps the person can perform their project piece in a silo, with little interaction with the other team members. Another option is to find someone else to perform the function at the direction of the person in question.
Building a War Room
One item that goes a long way toward building and developing team chemistry is a war room. A war room is simply a separate space set aside where project members can work together. Ideally, it is a room that is configured with the infrastructure (i.e. computers, phones, white board) necessary for working on the project. Seating should be configurable, so islands can be created as specific needs arise.
A war room gives the project an identity. Dress it up accordingly. Vendor trinkets, project name in big letters, project plans taped on walls. It all helps to give everyone involved a sense of belonging to something important.
Working in a war room has several advantages, the first being less interruptions, since you are not at your desk or phone. The second biggest advantage is you get to eavesdrop. I find it truly amazing at how discussions between two people quickly become a team exercise when someone overhears something that affects their piece of the puzzle.
With every advantage there is a disadvantage. Working in close proximity to others in a stressful environment can put people on edge. Keep this in mind during stressful times and remember to schedule some time for everyone to decompress. Pick an activity that everyone enjoys (i.e. bowling, wine tasting, miniature golfing) and see if the vendor will pick up the tab.
Working with the Vendor
I always enjoy the period of time that exists between the time a client signs the contract and the time the client starts seeing what they've actually purchased. Peace reigns across the land and all is well with the world. Though client/vendor expectations have been set, know one knows yet how different they are. Then we enter the requirement phase, detailing how the client is going to use the software. That is when we see how funny it is that two groups can hear the same thing yet come up with two entirely different interpretations. So what happens? Some differences are taken care of immediately. Others make there way to the issue log (see Build Issue Management Process –Escalation section, below).
Resetting Sales Expectations
What happens when expectations between the vendor and client are not aligned? What does the contract specify? Were there things shown during the sales cycle that are clearly not in the product? The honeymoon is now officially over. For discussions involving product expectations, a good vendor will bring in the original sales team to determine which expectations are accurate and which are not. The client has the opportunity to review and get clarity on items in question. The vendor has the opportunity to review what was presented and where expectation got misaligned. The results of the discussion ought to be reset expectations on one side or the other, and the continuance of the project. Depending on the severity of the discrepancy the project may continue, with the item entered on the issue log, or it may enter a holding pattern while the expectation is reviewed and the proper steps to resolution are taken.
Vendor Does One Time Work
When deciding how to spend your consulting dollars it is always wise to let the vendor do the one time work. Conversion is a great example. The vendor knows their system and the best way to get information in. It usually involves a repeatable process that occurs multiple times during the project life cycle; then it gets shelved. The vendor may already have a canned conversion routine used by another client coming off the same legacy system, which expedites the process and may lower cost. Unless you have excess capacity to do this in house, it is more accurate and timely to have the experts do it. The same can be said with product enhancements, and to a lesser extent, ongoing interfaces and custom reports. It does come down to time and money, which may drive the decision either way.
Customer Does Continuing Work
The client should always be involved in system configuration and testing. These are activities that will continue after the go-live date. The client also needs to be comfortable with reporting, data extracts and importing information into the system.
One of the major components during the implementation is knowledge transfer. Your goal should be to be as close to self sufficient as possible on the live date. That means making sure consulting dollars are allocated wisely. Given the choice, it is always better to have the consultants assigned to configuration and testing perform more of an advisement and mentoring role while those who are tasked with using the system do the hands on work.
Documenting Today's Processes
Process Maps to Visualize What You Do Today
Having a clear picture of where you are today helps decide where you need to be tomorrow. Process maps of current procedures are necessary to insure all the bases are covered when defining tomorrow's road map. Process maps tend to be text based, with screen prints, describing how processes are performed using the legacy systems. In an ideal world they would take on a more graphical format, making them easier to visualize. A typical process map (see Exhibit 1) demonstrates the steps necessary to complete a process and who is responsible for the step.
Decide What Stays, What Changes and What Goes
Why are you implementing a new system? Reasons range from additional functionality to current system compliancy issues to cost savings. Each reason affects the ‘what stays, what changes and what goes' question. Then throw in how soon does the new system have to be up and running. If speed is of the essence, then the question gets a little easier. The goal is typically to replicate existing functionality in the need for expediency. Otherwise, you do have decisions to make that'll effect the implementation.
As a rule, existing functionality is always included in the first phase. Next on the list are items that lead to efficiencies and/or cost savings. Self service is a good example. Introducing ‘tier 0' support, as it is sometimes called, reduces tier 1 support calls, providing time and cost saving opportunities.
All of these decisions need to be captured in requirements, along with the appropriate timing for implementing these decisions. It is always preferable to bring up a new system as delivered, holding off on additional enhancements and functionality until the system has stabilized and you've had a chance to get comfortable with its features. In addition, deferring additional implementation items may be preferable to trying to get everything into the initial go live date.
Requirements – Analysis, Build, Test
The heart of any implementation is carefully defining requirements in order to build a clear scope of what the project is going to entail. Requirements need to be signed off by both the vendor and client. Requirements drive project scope. Once the requirements are defined, change orders are necessary to modify the contents of the document and the associated implementation scope.
Analysis is reviewing the requirements and defining formal specifications for building the system. One common approach is for the vendor to create design specification documents, review them with the client to get sign-off, build to the specification and deliver the end product. The problem with this approach is what the client wants doesn't always match what they get. The conversation with the vendor usually goes something like this; ‘it may be built to the specification, but I didn't understand what I was signing and it is not what I need'. At best this ends up as rework, at worst in litigation.
A better approach is for the vendor to build a prototype, refined through an iterative process of analysis, build and test with the client. This gives the client the opportunity of touching the system along the way and working in combination with the vendor in the configuration of the system.
Finally, the best approach of all is working within the constraints of the vanilla functionality. Enhancements to a system add to the complexity of future upgrades. I always suggest building the system via configuration and then letting the client see what is available before heading down the customization path.
Defining Tomorrow's Processes
Process Maps to Visualize Where You Are Going
Once you see the process maps/procedures for today's processes you can decide what the future system should look like. Additional and/or different functionality from the current system will drive process change, as will the business decisions that drove the purchase of the system. This needs to be mapped out so there is a clear definition. Quite often these end up as part of requirements and project scope. At the very least, they'll end up as a user knowledgebase and be used in the end user training phase prior to deployment.
Define What's Important for Today and Leave Hooks for Tomorrow
Another important aspect in working with the vendor is to present your vision of the future. It doesn't matter if the vision is 1 year away or 10. If the vision has the potential to impact the configuration and design of the system being implemented, then it needs to be documented properly in the requirement phase so it is accounted for in the design. A 5 year plan that includes acquiring 10 companies and doubling in size may impact the system infrastructure and configuration. So may moving to a new benefit provider or changing financial systems. To the best of your ability, you should try to get a clear picture of where your company is headed. It is certainly desirable to include the hooks to these future endeavors in the constraints of the current system build.
Make a Plan
Define Constraints (Time, Money, Resources)
What is driving the implementation? What defines the constraints? Knowing your project constraint(s) clearly gives you opportunities. Time constraints may allow you freedom in selecting needed internal resources or allow you to spend more money on consulting. Money constraints may allow you to stretch the timeline or add internal resources. Resource constraints may allow you to bring in knowledgeable consultants or stretch the timeline. Combinations of constraints begin to limit opportunities. Have a time and money constraint? Then you better hope additional internal resources are available to get the project done. Have a money and resource constraint. Then the timeline needs to be flexible. Are time and resources a problem? Then having deep pockets to bring in the right outside resources may be necessary. Are time, money and resources all a constraint? Then align project scope with the constraints. If that is not an option, then prioritize the three constraints and understand that whichever one is number 3 is going to be effected, like it or not.
Determine Phase 1
Locking down tasks associated with phase 1 should wait until the requirement phase is complete. This allows you to get a clear definition of where you want to take the product before building the detailed project plan and timeline. What gets included in phase 1 is partially determined by project constraints. Time, money and resources, or lack thereof, will effect what can be included in the initial implementation phase. Therefore, understanding your constraints prior to putting together project requirements allows you to make the proper determination of what tasks can realistically be included in phase 1. Basic functionality is a given. It's the bells and whistles you have to think about.
In addition, a multi-phase implementation plan give you better control, since you are dealing with limited subsets of functionality. You get an opportunity to get comfortable with the system before bringing in additional components. Give thought, however, to the ramifications of a multi-phase approach. That may mean leaving existing systems in place, requiring continued infrastructure and support costs.
Build Communication Plan – Who Gets What, When
A documented communication plan involving the vendor and client is essential to keeping everyone on the same page. Both vendor and client team members should be listed with their respective role and contact information. A matrix defines who is involved in a particular communication strategy. Weekly team meetings may include everyone. Planning meetings may only include vendor and client leadership. Steering committee meetings will involve project managers from both sides, along with the committee members.
The plan should contain details on scheduled meetings, along with who owns the meeting. Visually, it is a good idea to present a calendar specifically listing all standing meetings to get buyoff between the vendor and client.
Status report format should be defined and included in the plan. Who prepares them, how frequently and to what audience are they delivered should also be documented. There may be a weekly status report to the team and project sponsor, which rolls into a monthly steering committee update. The document can be e-mailed to recipients or placed in a shared directory or database. The vendor should have templates for these activities, but will often defer to the client if they have something that works for them.
Build Change Management Process – Who Approves
Project change is a given. Once requirements are complete and scope is defined, deviations require a formal change management process. This allows for proper change tracking, approval and incorporation into the project plan. It is a mutual process between the vendor and client requiring senior level approval of any change requests that effect time or cost. Who prepares the change document, who determines scope in terms of timeline and cost impact and a definition of the change request review process are all components of a change management system.
The vendor will typically have forms already developed for tracking changes. The initial change action is normally escalated to the either the client or vendor project manager. Once the project management team has identified a change to project scope, the change management process takes over and the change document goes through the formal change approval process.
Build Issue Management Process - Escalation
During the course of the implementation, issues are going to arise. Having an issue management process in place in advance will give you the proper framework for recording, tracking, resolving and, if necessary, escalating issues. A proper issue management plan should document the methodology for tracking issues. It should also define the escalation process that will lead to issue closure.
When deciding on a methodology, define who controls the issue tracking device. Issues can be tracked on anything from a spreadsheet to a formal issue tracking system. What drives the choice of tool is based on who needs access to view and update issues. If both the client and vendor update issues, then a central repository needs to be in place that allows both full access, with a tracking mechanism to show who has changed what. Alternatively, a team member from either the vendor or client can be designated as the official issue tracking maven, sending out issue logs based on the communication plan.
Escalation procedures need to be in place to provide closure to all issues that cannot be resolved by the project team. Issues at this level tend to require negotiation and are typically reserved for leadership members from both the vendor and client. Those members and the steps necessary for escalation need to be identified as part of the issues management process. Issues can be discussed during the status meetings, as defined in the communication plan. In addition, a formal issue review committee can be convened, either on a periodic basis or on an as needed basis. This should also be defined in the issue management plan.
Build a Plan for Success
Everyone seems to want a project plan built as part of the sales cycle, prior to proper discovery being completed or detailed requirements determined. This plan is, at best, a guess. The initial plan should provide the appropriate level of detail for initial project planning, completing discovery and getting through requirements, with a higher level view of the additional project phases. Once requirements are complete, the rest of the plan can be adjusted and taken down to a detailed level. The plan itself remains a living document throughout the project, acting as a guide through the various phases.
To build a plan for success it is recommended to phase the implementation to bring in the essentials in the initial phase, followed by the bells and whistles in future phases. An example is deferring new functionality for a second phase. You may also want to consider getting through a milestone period before beginning phase 2. The definition of a milestone depends on the system being implemented. For a payroll system it might be end of quarter processing. A financial system might want to get through several month end closes. A manufacturing system might want to get through a few inventory turns. You'll have to decide what makes sense for you.
And finally, remember that the vendor has as much riding on a successful implementation as you do. They are looking for a good reference to help them close future deals, as well as a continued revenue stream through annual maintenance fees and additional consulting. A good vendor wants you not only to succeed, but wants to meet and exceed your expectations with the system they sold you and the service they provide. The goal is a long term relationship as business partners where everyone benefits.
© 2004, Michael Mearman
Originally published as a part of 2004 PMI Global Congress Proceedings – Anaheim, California