I’ve had a lot of people ask me how the Four Phase Training and Implementation Plan fits in within an enterprise software project.
To do this, I thought it best to take a moment to break down the anatomy of a large software implementation project.
This diagram illustrates all of the major steps in a large software implementation project. Read the diagram from left to right, top to bottom. For instance, the first circle is “Vendor Selection” and below vendor selection are the steps needed to complete the software vendor selection step.
You may have to click on the image to see every box. Go ahead, do it now to get a better view.
Note: A couple of paragraphs below, you can download this software implementation process in PDF.
As you can see, there is a ton of effort put into a large software project. But did you also see where the Four Phase Training and Implementation Plan fits in?
The implementation plan commences at Process Refinement and ends at Month-End Support.
That’s almost the entire project.
I’m going to break down each one of those circles and also highlight the appropriate phase for each activity.
To provide some context and background, I’ll be referencing my guidebook to software implementations that explains exactly how to use the four phases along with some prerequisites and a cutover plan.
Step 0) Business Justification
Prior to doing anything on a software project, there has to be a definite business need, a solid value proposition, along with a gain or benefit after implementing the software. Typically this benefit will come in the form of a return on the investment (ROI) the company made to procure and install the software. The formula for ROI is as follows:
Since ROI is calculated in percentage, multiply this result by 100.
Example: let’s say a manufacturing company decides to implement new software. The estimated total investment for this software is $15MM USD. The anticipated cost savings (or gains) from implementing this software is $25MM USD. Therefore, the anticipated ROI for this project is 67%. I say “anticipated” because this calculation is based on assumptions and those assumptions may or may not happen.
Calculating the benefits of implementing software is always the first step; a business case, or justification, has to occur before anyone talks about buying new software.
Am I right? I mean, no company would go out there and just spend money willy nilly without having any idea of what the anticipated benefits would be would they?
With the business justification out of the way, let’s say top management likes the ROI and everyone gives the green light to proceed with the project. Who wouldn’t like a 67% return on a software investment for the company?
Step 1) Vendor Selection
With the business justification made and management agreeing to commence with the project, it’s time to select the software vendor. Epicor has a pretty simple process for selecting vendors and it closely mirrors my experience in how companies complete their selection.
Create an evaluation team. Assemble a team within the organization who will assist in the evaluation of the software vendor. This team should comprise of members from top management, functional experts and end-users. If you can find one, bring in a neutral consultant to help evaluate.
Business Assessment. Conduct an assessment of the current state of the business. Look at critical processes and note what is being done well and what benefits a new system can deliver for these processes.
Software Criteria. Develop a selection criteria to evaluate the available solutions. Criteria can include features, price, platform, and anything else the evaluation team can think of. Group the criteria according to importance to your business, i.e. very important, important, and less important. Assign a score (such as 1-5) to each to make the evaluation easier.
Some of the criteria can include:
- Industry Expertise. How well does the ERP vendor understand your industry? Does the vendor offer industry best practices or pre-deﬁned processes that are generalized or horizontally focused? ERP solutions should at the very least address your mission critical business requirements speciﬁc to your industry.
- Total Cost of Ownership (TCO). Determine the long-term TCO for hardware, software, and support—pre and post implementation.
- Multi-Site Operations Support. If you need to collaborate with multiple operations then ensure your ERP vendor can support multi-site operations. Can your ERP vendor support all your locations with a small centralized IT staff? Do they require complicated architectures?
- Customer Support. Does the ERP vendor have its own in-house support or does it outsource? You’ll gain the most out of your investment if you have access to a customer care center that can answer your key application and technical questions and advise on best industry practices
Ask for specific references. Don’t let them send you a list of “pre-screened” references who will surely tell you all the great things about this particular vendor. Instead, ask them to provide references of companies who are in the same industry as yours and faced similar business challenges. If desired, ask to visit these customer to see what they like and dislike about the software and whether or not it is working as expected.
Step 2) Project Kick-off
With the vendor selected, it’s time to get the project started with a good kick-off! The first part of kicking off the project is to assemble the team. This will take some time and is a crucial step in the implementation process.
This is the time to identify key resources to oversee the project and ensure its success.
Governance structure. To ensure accountability and success of the project, a governance board or steering committee needs to be put in place. This purpose of this committee is to help the project sustain its potential to deliver its promised value.
The committee must also help managers assess the project’s current state and adjust content and direction if necessary. They should also allow management to refine the definition of success to maintain alignment with evolving business strategy.
Typically this committee is comprised of the project manager, project sponsor, project management office (PMO) and most importantly senior business unit managers with a vested interest in the success of the project. The last group is important because they will be representing the users within each function of the company.
Executive sponsor. An executive sponsor is a C-level administrator who has a vested interest in seeing a project to completion.
Ideally, the executive sponsor should be the highest-ranking manger possible, relative to the size of the project. Successful sponsorship requires a deep understanding of organizational culture and awareness of how the project will help the organization achieve its goals. Part of the sponsor’s job is to promote the project within the organization, making sure everyone understands the benefits the project will provide.
In some organizations, the executive sponsor is the person who is responsible for financially authorizing a project and creating the project charter. The sponsor should work closely with the project manager, but is probably not the project manager’s boss. Typically, the project manager is responsible for day-to-day execution and the sponsor only steps in to make decisions when change requests might affect the project’s scope.
Project Management Office (PMO). The primary goal of a PMO is to achieve benefits from standardizing and following project management policies, processes and methods.
For the software implementation project, they will be the source for guidance, documentation, and metrics. If necessary, they will get involved with project-related tasks and follow up on project activities through completion. They may report on project activities, problems and requirements to executive management (CEO, CFO, CIO, etc.) to keep these decision makers moving toward consistent, business focused goals and objectives.
Project Manager. The individual responsible for the project’s overall performance and success. He or she will liaise between the functional/technical leads and the PMO/Project Sponsor/Steering Committee. It is a huge role and filling this position should be a collaborative effort within the organization.
Functional Leads. Don’t underestimate the value of your functional resources on a software implementation project. Choose the wrong resources for this role and risk not having the business requirements translated to technical requirements for the software.
Recruit people within the organization. Make sure they have at least the following: leadership, management, strong communication skills, charisma, knowledge of software systems, ability to write clear documentation, likes to help others and wants to see the project and company be successful.
Technical Leads. If you can source these individuals within the company, do so. Otherwise, vet these candidates with the same scrutiny you would for your functional leads. Ask for examples of work. Talk to references. Allow the functional leads to participate in the interview process since both teams will be working together closely for months to come.
Change Management. This could either be an individual or a team — depending on the scope of the project. Having a change manager on the project is not required but might be depending on organizational culture and number of users affected by the implementation.
The role of a change manager for a software project is to increase employee adoption and usage of the software by applying a structured methodology.
As previously mentioned, utilizing the four phase training and implementation plan I’ve developed has proved to increase employee adoption and usage through a structured method. Incidentally, the plan itself acts as a change manager within the organization during the project.
Announce to Organization. With the project team assembled, It is time to announce this endeavor to the organization! This kick-off and announcement to the organization should be held like the opening of the Super Bowl.
Get as many employees together as you can, set up a common area, serve food, play music and end it all with a kick-ass motivational speech by the CEO. Make it special for the organization.
Do this and both the project team and employees will be energized to make the project successful.
DON’T simply send out a BORING memo! No one will be excited and energized by a memo.
Step 3) Process Refinement
With the project kicked-off, it’s time for the project team to get to work! Send out the functional leads to meet with the business process experts and start identifying all business processes to be included in the software.
Work with these experts and other superusers to analyze the processes to see if any improvements can be made to them. Can you modify a step in the process to make it more efficient? Does this process touch other parts of the business? How critical is this process to generating revenue or satisfying customers?
Once the processes have been identified and scrubbed/reengineered, it’s time to document. Again, keeping it simple, just create the process like so:
Step 4) First Software Build Out
After refining the business processes, it is time for the first software buildout. This is where the functional leads transfer the business requirements to the technical team and the technical team begins the work of programming and configuring the meet the business needs.
Keep in mind this first build out should be largely representative of what the company needs to do to keep the business running. Depending on timelines and/or constraints, the software may only be 85-90% built with the remaining to be completed before User Acceptance Testing (UAT).
Step 5) Conference Room Pilot’s (CRP) and Software Configuration
With the first buildout of the software completed, it is time to validate if the team is on track with its configuration of the software.
In a large software implementation there will be three CRP’s. For the first CRP, get all of the Subject Matter Experts (SME) together along with other business process experts and superusers. Talk about each business process and how they were transformed to reside within the software.
Demonstrate the process in the new software then allow the users to complete the task individually. Be sure to provide a job aid and data sheet for each process to be tested so each user knows where to click and what the expected results are.
Note all of the passes and fails of each step and also be sure to note any lack of functionality, software bugs or key usability issues. Make sure both the functional team and technical team are facilitating these sessions.
Software configuration. Based on the issues discovered during CRP1, make a list of the top 10-15 critical items to be fixed before the next CRP session. Have the technical team make all of the necessary fixes and bug squashing.
Rinse and repeat.
Conduct a second CRP session with the users and note the passes and fails of each step along with any lack of functionality, software bugs or key usability issues. Make appropriate changes to the software application.
Rinse and repeat.
Conduct a third CRP session with the users and note the passes and fails of each step along with any lack of functionality, software bugs or key usability issues. Make appropriate changes to the software application.
Step 6) User Acceptance Testing (UAT)
With three CRP’s completed and multiple configurations made to the application, it is time to demonstrate the software is ready for the users. With the incorporation of Phase 2: Mini-CRP and Web Calls, iterative changes can be made without the need of a full blown CRP. Therefore at this stage in the project the application should be ready for enterprise use.
Conduct a thorough end-to-end testing of the software with every business process from every function of the company.
As with CRP sessions, ensure job aids and data sheets are used during the testing. Every end user should attend this session in person.
After the system has been tested by the users, you may formally or informally have them “sign-off” on system readiness.
However, should there be any issues uncovered during the UAT, complete one final round of software configuration before go-live.
Step 7) Cutover
Time to begin the process of transitioning from one system to a new one. The organization needs to plan, prepare and execute the cutover, by creating a cutover plan to describe all cutover tasks to be completed before go-live. This plan is designed to minimize the ongoing risk of moving from one system to another.
It also includes the task of migrating code from a development or test instance to the production instance.
Once these activities have been identified, they become tasks assigned to key stakeholders of the project. These stakeholders can be anyone from a project lead to a controller who has to ensure the books are reconciled prior to moving to the new system.
When developing a cutover plan, identify key activities well in advance so the project team and stakeholders can agree on the tasks and be aware of when they need to be completed.
Examples of cutovers tasks are:
- Prepare production environment
- Date for last transaction in old system
- Data conversions
- Complete final month end close in old system
- Preparing the Service Desk for user support
- Setting up a command center prior to go-live
- Developing a user support plan
Also ensure there is a contingency plan in place should something go wrong during the cutover process; no need to shut down business operations.
Ensure there are checkpoints along the way and communicate the passing of each item on the list.
Step 9) Go-live
The big day is here. Time to “turn-on” the new system and allow users to transact.
I’ve said this many times but it still bears repeating: every software project needs to deploy the functional resources to key locations to provide on-site support at go-live. Providing in-person support for the users at go-live is a morale boost for the organization and is vital to the success of the launch.
Step 10) Month-end Support
As with go-live, deploy the functional resources to key locations to provide on-site support at go-live. Providing in-person support for the users provides a huge morale boost. Send key personnel to sites a couple of days before month-end and have them return just after the close.
Post Mortem: Project Closure and Lessons Learned
Project Closure. With the software fully launched and business returning to normal operations, the project manager will complete a final checklist resembling something like this:
- All deliverables accepted and signed off by client or sponsor
- Final project status reports complete
- All financial processes and reports complete
- Project review complete
- Staff performance evaluations and reports completed
- Staff employment on project terminated or reassigned
- Announcement of completion of project (internal, external and public relations contacts)
- Completion and storage of project file
Lessons Learned. Use Google Forms to create an online questionnaire to solicit objective responses from the project team.
Categories should include the following:
- Management Sponsorship
- Project Objectives & critical success factors
- Project Plan and Schedule
- Project Team
- Client/End User Involvement
- Use of Technology
- Project Monitoring
- Project Communications
Allow space under each topic and create questions to be answered on a scale like this:
0 = Don’t Know or Not Applicable
Scale from 1 to 5
Where 1 = Strongly Disagree
And 5 = Strongly Agree
Friends, I hope this clarifies where the Four Phase Training and Implementation Plan fits within a software project.
What does your software project’s structure look like at the moment? Is it similar?
Leave a comment below as I love learning how others manage their projects.