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.

As you can see, there is a ton of effort put into a large software project & mobile app development 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.

Practically 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 1) Business Justification

Prior to doing anything on a software project or mobile app development 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 mobile app development 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 top mobile app development company in india, decides to implement new software. The estimated total investment for this software is $5MM USD. The anticipated cost savings (or gains) from implementing this software is $15MM USD. Therefore, the anticipated ROI for this project is 67%.

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 mobile app development 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 mobile app development company?

Step 2) 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-defined processes that are generalized or horizontally focused? ERP solutions should at the very least address your mission critical business requirements specific to your industry.

Total Cost of Ownership (TCO).

Determine the long-term TCO for hardware, software, android app 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 outsourcing software development? 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 3) 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.

Prior to announcing the project to the organization, the CEO ought to get the entire project team together to: a) announce who is filling each role on the project b) allow the team to meet each other c) motivate the team and d) set expectations of the project team

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 4) Process Refinement

With the project kicked-off, it’s time for the software developers 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 corresponds to the “Prerequisites” phase in the Training and Implementation Plan

Step 5) 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 corresponds to Phase 1: Face to Face Training of the Training and Implementation Plan

Step 6) 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.

Due to the duration of Step 5, this step corresponds to Phase 2: Mini-CRP and Web Calls and Phase 3: Monthly Proficiency Tasks of the Training and Implementation Plan

Step 7) 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 corresponds to Phase 4: Final User Training and Certification of the Training and Implementation Plan

Step 8) 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 8 corresponds to the “Cutover” section of the Training and Implementation Plan

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 9 corresponds to “Supporting the Organization” section of the Training and Implementation Plan

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.

Step 10 corresponds to “Supporting the Organization” section of the Training and Implementation Plan

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

What’s Your Project Structure Look Like?

Friends, I hope this clarifies where the bAnalyst.co Training and Implementation Plan fits on a software implementation project. If not, leave a comment or reach out to me. I’d love to help you!

By the way, what does your software project’s structure look like? Is it similar?

What’s the ONE thing you want to improve on your project (either current or past)?

Leave me a comment below!

If you are looking to build your next (or first) mobile app and need help with one or more of these steps, you’re in luck! The moPharma Group welcomes app owners at any stage in this process. Whether you are a startup or Fortune 50 company, we have the team and knowledge needed to deliver a fantastic mobile app. Please don’t hesitate to write us today.