It is critical to establish executive level sponsorship from the outset and throughout the project.

Management from every level of the organization that may be affected by the new system should be invited and encouraged to participate and provide their insights into the selection of the product that best fits the needs of the company.

The selection team should include a mixture of management and operational/functional experts. In addition, a Selection Team Facilitator (typically a project manager) should be appointed.

A steering committee should be formed (usually comprised of executive and/or upper-level management) to provide resource guidance and risk mitigation as well as act as gate keepers for established milestones within the selection process.

An initial budget should be established for Selection, Implementation, and post Implementation activities. The budget should be based on a range identified through preliminary research of publicized similar projects or gathered through industry resources.

It is essential to establish a communications team that is responsible for developing a communication plan that tracks and reports the ongoing progress of the project from start to finish. Communications should target the entire company from management to line-level employee.

Every organization has areas of operational frustration. Processes that are time consuming. Automation that requires multiple clicks and screens to enter data. Paperwork that is outdated but somehow is still required. Reports that never give all of the information necessary to make a decision. These pain-points should be recognized and documented.

Documenting current business processes will not only help discover bottlenecks in efficiency but will also highlight areas that need improvement through new automation.

When replacing existing systems, important software functionality should be documented to ensure that the new system will match or exceed the current capabilities.

Often an organization is unaware of all of the possible sources of data that are available. Creating a data source catalog of all existing sources will be very beneficial in identifying data consolidation and transformation activities during the implementation phase.

Current decision support capabilities including operational reports, spreadsheets, online reporting, and informative dashboards (if they exist) should be documented and cataloged according to function. This information will be used as a baseline for the future system.

Using the business process reviews gathered in the Current State Analysis Phase, a process reengineering effort should take place. This will include the elimination of unnecessary processes, the combination of similar processes, the total redesign of certain processes, and the addition of new processes.

New functionality requirements should be developed using the vision of a desired future state by referencing the information gathered from the business pain-points review, current process review, and current functionality review.

Typically, existing data resources are fragmented and often duplicative. Using the data catalog developed in Phase II, a future state with centralized control of all data resources can be defined.

One primary endeavor during a new enterprise system acquisition is to replace as many home-grown and/or outdated applications. In addition, newer enterprise solutions cover multiple applications and provide a tighter integration and common user interface that is superior to using multiple applications to accomplish similar tasks.

A primary goal initiating new technology is to introduce automation modernization including mobile device compatibility, use-anywhere capabilities, and easier state of the art user interfaces.

Enhanced data capabilities should be a primary goal of the new system. Moving from a reactive operational decision making capability to a proactive or prescriptive business intelligence capability will be a business game-changer.

The new system should provide application programing interfaces (APIs) that allow easy integration with in-house and external 3rd party applications.

The final step in the Future State Analysis phase should consider the return on investment (ROI) that is expected by implementing a new system. This analysis should consider the enhanced functionality, increased efficiencies, and innovative decision support capabilities that the new system is expected to deliver. The end result should help justify the total cost of ownership and implementation budget developed and approved in Phase VI.

The business process reengineering effort that took place in Phase III should help generate business process diagrams that illustrate the desired future state. These diagrams along with descriptive narrative should be included in the RFP to give perspective vendors an understanding of your process requirements.

Using the new functionality requirements developed in the Future State Analysis, an itemized list with requirements specifications for each item of functionality should be included in the RFP document. This list should be segmented into appropriate topic areas for easy interpretation and overall clarity.

A document specifying the preferred technology stack and embedded security processes and protocols should be developed and included within the RFP. Technology preferences can specify software development methods, language, web and mobile capabilities, and network connectivity. Security preference can specify single sign-on, Active Directory authentication, remote access capabilities, and encryption standards.

Using the Data Capabilities developed in the Future State Data Analysis phase, a detailed description of desired Business Intelligence (BI), decision support, and data access functionality should be documented and referenced within the RFP.

Systems today can be delivered in many configurations including on premise using existing or new hardware, off premise cloud (Software as a Service SaaS model, and/or a hybrid combination of both cloud and on premise. The RFP should include a desired delivery configuration.

How the new system will be maintained and supported will partially depend on the Software Delivery method. Guidelines of the desired support levels including operational and user support along with escalation and preferred reaction time should be itemized within the RFP. In addition, disaster recovery, backups, and business continuity requirements should be included. These items should later be addressed through Service Level Agreements (SLAs) detailed during Contract Negotiation.

Once the RFP has been created, it is essential that the final document is reviewed by the Selection Team and Selection Steering Committee. Often a legal review may be appropriate as well.

Use specific market research to identify potential systems that might meet a majority of the desired system requirements specified by the RFP. In addition, attending software and industry trade shows will often provide leads identifying potential software and systems.

During or after identifying available systems that might meet system requirements, conduct preliminary vendor research including vendor size, product offerings, and popularity. Take note of apparent pros and cons of both product and vendor.

Once you have a list of possible system solutions and vendor candidates, reach out to each vendor to identify willingness to participate in the RFP process. Often this includes a letter of intent to participate from the vendor as well as mutual non-disclosure agreements when appropriate.

After receiving each vendor's formal response to the RFP, the Selection Team should create a matrix that easily creates a comparison between the individual vendor responses. This will identify strengths and weaknesses of the individual vendors based on the categories of the RFP requirements. In addition, the RFP should contain a cost/pricing estimate from each of the respondents that itemizes licensing, support, and implementation costs. This can be used to finalizer the implementation budget and calculate a predicted ROI.

As part of the RFP vendor response there should be a list of current customers that can be contacted for reference information. If possible, interview each of the customer references without the presence of the vendor. Ask pointed questions about “what went right” and “what went wrong” with their implementation. Ask about ongoing support and responsiveness. Try to get a feel for the relationship between the existing customer and the vendor. Is it a partnership or antagonistic?

The RFP review and customer references should provide enough information to shorten the list of vendors to a manageable number to move on to the presentation phase. In cases where there are a small number of vendors participating because of the unique nature of the system requirements, then it is recommended that this step be bypassed.

Before inviting vendors to present their product offerings, it is important to create a demonstration script that closely mirrors the RFP requirements. The demonstration script should include functionality to be shown and an allotted amount of time to demonstrate the requirement. In addition, a score sheet should be developed to allow the Selection Team to rate each vendor’s individual capabilities as well as their overall presentation score. The demonstration script should be sent to each of the vendors well in advance of the presentation in order to give them proper time to prepare.

Based on the score sheets and selection team feedback on the vendor demonstrations, it is often necessary to create a final short list of vendors you wish to enter into the final phase of selection before an award is made. This is a recommendation but not a requirement.

It is a good idea to a final presentations from either the selected vendor or the final short listed vendors. A new demonstration script and score card should be created for this final presentation that focuses on the aspects of the vendors product that may need clarification or were not given enough time in the original presentation. Again, it is important to score each vendor immediately following the presentation.

It is a professional courtesy to notify each vendor that a selection has been made and that you will be entering into contract negotiation with the winning vendor. In addition, before entering into formal contract negotiations, it is important to remind the successful vendor of your expectations concerning product functionality, pricing, implementation timeline, service requirements and support.

The vendor’s RFP responses, presentations and promises made should be formally documented and discussed prior to legal review. Details concerning the full product, customer expectations, implementation plan, pricing, and support should be clearly and fully developed. Once the final product agreement is negotiated, a full legal review should take place. The final contract should be reviewed by the Selection Steering Committee and approved by the appropriate executive.

The implementation timeline and list of deliverables should have been part of the formal contract or at least referenced as an addendum to the formal contract. There may be small changes necessary especially based on initial resource availability. The timeline should contain multiple milestones and performance reviews that can be used by the Implementation Team, Implementation Steering Committee and Executive Sponsor to monitor the progress and success of the project as it moves forward.

Using the agreed to costs including license fees, implementation, and service and support costs, a final budget should be established and approved along with an expected Return on Investment (ROI) that can later be used to measure the success of the project.

An Executive Sponsor for the implementation should be appointed. This can be the same resource used for the selection process.

An Implementation Steering Committee should be formed from management and executive level personnel to monitor the project scope, schedule delays, cost, and milestone achievements. The Implementation Steering Committee should act as gatekeepers scope creep and cost variances.

Form an Internal Implementation Team consisting of individuals oriented towards project management and include “subject matter experts” from throughout the organization. Appoint a project lead that can communicate effectively and has the knowledge and commitment to guide the project from beginning to end.

The vendor will provide an implementation team that compliments the internal team. The two teams must work closely together as partners to ensure the success of the project. The Implementation External Team will also have a project lead or manager that will guide the project from beginning to end.

A sandbox or initial installation of the project should be one of the first steps in the implementation process. Depending on the product delivery model (on premise, cloud, or hybrid) a system should be brought online to start initial planning and testing.

Members of the Internal Implementation Team should be given thorough training of the Sandbox environment. This train-the-trainer exercise will later be designated as Super Users. During this initial training a Functionality Review and Process Mapping will occur.

The selection process was used to narrow the field and help select the enterprise system that was a best-fit for the organization. However, now that the product is chosen and a Sandbox is available to evaluate, a thorough review of the system’s functionality including reporting and decision support capabilities should be compared to the organization’s requirements to uncover possible shortcomings requiring remedial action.

Use the business process definitions and diagrams developed in Phase III and Phase IV to compare against the new system processes demonstrated within the Sandbox environment. This will highlight possible process changes that were previously mapped.

Perform a gap analysis using the Product Functionality Review and Process Mapping results. The analysis will indicate possible change requirements to the product, operational process changes, and/or additional integration efforts.

The appropriate Data Resources discovered in Phase II will be evaluated, scrubbed of inaccuracies, exported, transformed to match the new system requirements, imported into the new system, and tested for accuracy.

Most enterprise systems will require integration with multiple external applications and systems. Integration efforts typically require a large amount of development and testing time so it is recommended to start these efforts early in the implementation process. Although the Sandbox system can be used for integration testing, it is recommended that a second instance strictly assigned to technical testing be used for this exercise.

Using the Gap Analysis and Product Functional Review results, new operational reports, graphs, and decision support tools should be developed and thoroughly tested. It is recommended to start these efforts as early as possible following the Gap Analysis.

Preferably use a dedicated testing system for this exercise; otherwise, flush the Sandbox and load it with current legacy production data. Develop a testing plan that uses actual business scenarios. Run tests against each piece of system functionality including reporting and process flows. Document any discrepancies and retest if a bug correction is required.

A training Plan should be developed and followed using a Train the Trainer approach. The Sandbox should be refreshed with the latest legacy production data and each user should undergo extensive training within their functional area. Management will most likely require additional decision support training.

Prior to going-live with the new system, develop and perform a technical testing plan that includes backups, and system failure scenarios. Measure actual response and system restore times to expected results. Alter system configurations as necessary.

Develop and execute a Cutover Plan that includes methodology, support, and testing. The go-live methodology could be piecemeal or all at once depending on the complexity of the system. It is recommended to use the Big Bang approach if possible. Often, a piecemeal approach to going live will increase cost and could lead to scope creep. Once a go-live date is scheduled, ensure that there is appropriate technical support available both internally and by the vendor. AS part of the Cutover Plan, perform testing and make corrections as necessary.

It is highly recommended to perform a lessons learned exercise after an implementation. What went right and what went wrong with the project? What improvements can be made in the process? Are we on track to meet the desired ROI?

Now that the system is in production there will be on-going training and support requirements. New users will be added, existing users will change roles, and support issues will arise. Continually update the Training Plan as needed and utilize a support ticketing system to monitor product issues and resolutions for continuous improvement.

Post implementation activities typically include realizing the need for additional functionality, processes, and decision support capabilities. Try to avoid any large changes to the new system for at least 6 months. Enterprise systems are complex and the amount of change the organization has experienced will require time to assimilate. Adding new features to quickly could cause product instability and lost user productivity.

Everyone involved in the enterprise system acquisition and implementation should be congratulated. Successful implementations require a dedication of resources, will-power, and stamina from everyone involved. Unfortunately, now that the system is installed the work is not over. Continuous monitoring and improvement of the system components and the business processes will ultimately provide the necessary return on investment that the organization requires to truly call the project a success.