Seven (7) Key Factors for a Successful SAP Implementation Revolution Technologies

Confidential and Proprietary to Revolution Technologies, LLC

Page 1

Table of Contents
Seven (7) Key Factors for a Successful SAP Implementation ........................................................ 1 Abstract ........................................................................................................................................... 3 Overview of an Implementation ..................................................................................................... 4 Key Success Factors ........................................................................................................................ 4 Project Planning .......................................................................................................................... 4 Risk Management and Planning ................................................................................................. 7 Resource Planning and Management .......................................................................................... 9 Blueprinting .............................................................................................................................. 12 Transport Management ............................................................................................................. 16 Testing....................................................................................................................................... 18 Cutover Planning ...................................................................................................................... 21 Summary ....................................................................................................................................... 24

Confidential and Proprietary to Revolution Technologies, LLC

Page 2

Abstract In an SAP implementation, risks and pitfalls to success exist around every corner. All successful implementations have seven factors in common. Those factors include: project planning, risk management, resource planning and management, transport management, blueprinting, testing and cutover planning. This document will identify the components involved in each of these factors that allow for success as well as provide some cues that can be used to manage risk as it arises during the implementation. It is important to note this is not an implementation guide but does provide guidelines and steps that will allow for a higher degree of implementation success without increased cost or implementation duration.

Confidential and Proprietary to Revolution Technologies, LLC

Page 3

Overview of an Implementation All SAP implementations start out the same way. The decision is made to implement SAP, hardware is purchased, project leadership is assigned and a budget is established with a targeted delivery date. From this point on, all implementations will follow the defined methodology for the implementing organization. The key differentiator is that some organizations will achieve success and other organizations will experience delays, cost overruns and in extreme cases, full project failure. It is the successful implementations that carry the same key success factors regardless of the methodology used for the completion of the implementation.

Key Success Factors Those organizations that do achieve success deliver seven aspects of their implementation successfully. The success factors are project planning, risk management and planning, resource planning and management, transport management, blueprinting, testing and cutover. The next section of this document will analyze each of the defined success factors providing insights into what drives success and risk cues that can be used to course correct when recognized.

Project Planning Successful project management from an SAP implementation perspective consistently exhibits the same characteristics regardless of the implementation scope. Those characteristics are: 1. Established project controls and processes successful projects will establish controls and processes that will be followed and adhered to before the project Confidential and Proprietary to Revolution Technologies, LLC

Page 4

formally begins. This ensures that there is adequate time and ability to train and orient the project team to the way business will occur and what will be required of each team member in support of the project management team ensuring success. A key point of note here is the first project control that will be formalized and managed in this document is the project charter. That project charter can then be used consistently to ensure that everyone is working towards the same goals and objectives in the delivery of the project. The affiliated processes will be well documented and be able to be referenced throughout the duration of the project. The project plan itself will be baselined and version controlled so the plan can be audited and measured over time. 2. Defined plan ownership and management accountabilities as part of the documented processes will be role identification and project ownership accountabilities. This will clearly define for management and program participants what the roles are and the affiliated accountabilities of each role from project sponsor to configuration specialist to developer to technical writer. This allows the various team members to be measured on delivery per the accountabilities of their role. It provides a level of ownership of responsibility to each individual since they will know what is expected of them throughout the project lifecycle. 3. Modular task plans integrated with the milestone project plan to expect maintenance of one project plan at a task level required in an SAP implementation is not feasible. Instead, successful plans consolidate into a milestone and risk management plan those key items identified by each modules task plan. That Confidential and Proprietary to Revolution Technologies, LLC

Page 5

means that the task plans are maintained and managed at a tower/module level and the leadership of each area manages and ensures integration with key risk points and integration points as well as delivery points accounted for in the milestone project plan. Each module plan, like the overall project plan is baselined, includes risk identification and management steps and is version controlled ensuring reference capability and audit controls. 4. Inclusion of risk management in plan maintenance though risk management has been identified in the preceding points it is stressed here relative to the plan itself. What this means is that the project plan and affiliated project management processes need to include risk planning and management. The plan needs to identify risk points and include the necessary steps that should be tracked to ensure the resolution of risk relative to the delivery of the system. If this is not included from the project management aspect the project will fail. 5. Senior leadership active participation in project reviews though this item comes as the final point on the list, it is the key driver to project management success of an SAP implementation Potential failure cues can be identified in the project management arena by different events through the life of the project. These events include but are not limited to: lack of version control on the project and task plans, meetings without agendas, a lack of regularly scheduled project management meetings, missing task plans, constant questioning of roles and responsibilities. When these things occur on a regular basis during the implementation, a high

Confidential and Proprietary to Revolution Technologies, LLC

Page 6

level of risk exists around the project plan and the affiliated processes that if not managed will cause failure and delivery jeopardy.

Risk Management and Planning The key to successfully managing and planning for risk in an implementation includes the following steps occurring on a regular planned basis: 1. Risk identification process project successful in managing and planning for risk have a defined process for identifying risk. Now, this process does not need to be excessively complicated or even involve a management process. Instead a successful risk identification process usually involves three key factors: 1) identify, 2) document, 3) notify. That says the risk is identified, it is thoroughly documented so it can be evaluated and allocated out appropriately for resolution and that the leadership team is notified so they can adequately care for and monitor the identified risk 2. Standard rating scale for risk this component of risk management on a project gets a bit more subjective. Several organizations will use a Six Sigma based FMEA for risk rating and ranking. That is a great way to handle it. In a non-Six Sigma based organization where there is not a formal risk management process already in place, the project team will typically establish a one through five (1-5) rating scale with a risk of five indicating that there is risk but the project can move on and this can be dealt with or managed over time and a rating of one indicating that the risk poses jeopardy of failure impacting the go live. When a consistent scale is put in place Confidential and Proprietary to Revolution Technologies, LLC

Page 7

and used than everyone begins to look at and measure risk by the same standards which eliminates the squeaky wheel effect where the group that complains the most gets the attention and support in the risk process. 3. Integration a critical component of successful risk management and planning may sound obvious but bears addressing integration. Once the risk has been identified and rated, the entire team must look at and assess the risk across the entire project. Risk management by silo is important but if the other teams do not know about issues as they arise, where system components touch one another failure will occur. The integration is typically best cared for by regularly scheduled risk management meetings where representatives from each team are present and work to resolve and determine potential cross over issues 4. Risk planning following on to the integration component, once a risk has been identified and rated, a plan for resolution must be developed and agreed to by the team to allow for success in moving forward. Risk plans will typically include a document that will define the steps and processes and any technology adjustments that will be used to resolve the risk. This can in turn be included in the project plan and measured for success by re-rating the risk after the implementation of the planned solution. By planning the resolution of each risk all team members across functional areas can also be aware and plan for the impact the changes may have on their silo thus reducing the risk of introducing new risk. 5. Project management and controls once again though this may be obvious, it does need to be pointed out. The project management team must ensure all risk Confidential and Proprietary to Revolution Technologies, LLC

Page 8

management processes and procedures are in place and followed by the team. The project plan should reflect identified risk and resolution of the risk. The project management team should ensure regular check controls are in place to ensure identified risk that has been resolved has been re-rated and ranked and has truly been resolved across all aspects of the project. There are several different cues on a project that can be used to identify the fact that risk is not being successfully managed and planned for. The key project cues however can be either very obvious or very subtle. The cues to be on the alert for here are: 1) lack of participation in meetings, 2) incomplete or inadequate documentation, 3) risks being identified may be documented but there is no proposed resolution, 4) phrases like its hard to say and Im not really sure or we havent thought about that and 5) lack of identified risk based tasks in the project plan.

Resource Planning and Management To many, this point of success for an implementation seems relatively straight forward. It may be straight forward but it is the most ready failure point on the majority of projects. Why? It is not just about putting people in place to do the work, it is about putting the right people in the right place at the right time with enough time to do the job the right way. Too many times organizations do just in time planning and resourcing which increases risk for failure. In organizations where the resource planning and management is successful, the following can clearly be seen:

Confidential and Proprietary to Revolution Technologies, LLC

Page 9

1. Defined resource plan defining the resource plan is key to a successful implementation. A good resource plan identifies what skill sets are needed, for what duration, at what points in the project and how many persons with that skill set are required. The key to the resource plan success is timing. The plan needs to be developed with enough time to adequately staff the positions and ramp up the project. This timing must be accounted for in the project plan itself making the resource plan a component of the project plan. 2. Resource plan balanced against project plan the resource plan must be integrated into and balanced against the project plan. Resource balancing is a delicate act at best and a cumbersome process at worst but it is one of the keys to success of the project. If the resources are not balanced then there is the potential for overstaffing in some areas and understaffing in others which in turn jeopardize the ability to get the work completed on time and on budget. 3. Task reviews this component takes the resource management out of the planning stage and into the delivery process itself. During the implementation there need to be regularly scheduled task reviews. These reviews can be between team lead and implementation team members, project management and team leads, project sponsorship and project management or a combination of these but they need to occur. In the task review not only are the task plans themselves reviewed for success, failure, delay and reschedule points but ability to deliver and work completed is assessed and evaluated. At this point the implementation team at all levels can receive feedback both positive and negative that allows them to adjust as Confidential and Proprietary to Revolution Technologies, LLC

Page 10

necessary to meet delivery requirements. It keeps team members motivated and on task as they are receiving direct real time feedback allowing them to correct issues and continue driving success points. 4. Budgetary reviews periodic scheduled budgetary reviews of resource dollars expended against plan need to be conducted. These reviews will allow the leadership team to determine if the right blend of staff is being used and account for any adjustments that need to be made within the planned budget before overruns occur. It is recommended that to this end supporting the budgetary review process controls be put in place to control expense. These control measures would then be part of the budgetary review process. Some basic controls easy to put in place include: a) process for pre-approval of overtime, b) weekly time reviews by team lead and c) time sheet signature process including both consultants and employees. 5. Roll-off processing this may seem like an odd item to include here but it is very important to a successful resource management process. Many organizations keep people, both employees and consultants, too long on the project thus impacting the budget. Putting a process in place that triggers the off-boarding process is a good way to avoid this cost overrun expenditure. This can include something as simple as an automatic notification to HR or Project Management based on hours worked if a time system is used that can provide workflow, or something as complicated as a bi-weekly headcount review with program management and HR. Whether simple

Confidential and Proprietary to Revolution Technologies, LLC

Page 11

or slightly more complex a process needs to be put in place to ensure roll-offs are being handled completely in a timely manner without unintended extensions In the area of resource planning and management there are some easily identifiable as well as slightly more obscured cues to risk being introduced into the project. Some of the more readily identifiable cues are: a) no plan that can be provided to HR and resource managers to build the team for delivery, b) difficulty onboarding a complete team per the scheduled timeframe, c) budget and staffing review meeting cancellation and/or lack of participation. Obvious though they may be, these cues are often overlooked as a contributing factor to cost overruns and implementation delays as the assumption is just when the staff gets in they can make up the time. It does not work that way. That is an unrealistic expectation and needs to be dealt with up front. The subtle cues are slightly more difficult to identify and rectify. These cues include items such as a periodic occurrence of unapproved overtime, a timesheet submitted for approval late and identified risk not being included in the resource plan for coverage. Though the typical response is these things happen occasionally and it was only once or twice often accompany these occurrences, if each happens twice on each team required for the implementation it becomes a cost issue. Putting processes in place and controlling those processes though people may not like it will save the implementation undue expense and potential delivery failure.

Blueprinting As most organizations follow the ASAP methodology for implementation the concepts, constructs and steps for blueprinting are very well understood. When it comes to blueprinting Confidential and Proprietary to Revolution Technologies, LLC

Page 12

however, there are certain components that if not managed fully will prevent success. The key factors of the blueprint process that will allow for success in the implementation include: 1. Clearly defined goal statements or charters by module this item may seem a bit odd since the overall goal is a successful system go live but it is very important. By clearly defining a charter or goal statement by module, each person working on the blueprint for the various modules is working to the same objective. Without a concrete goal by module the various teams will tend to drive to their perceived goals as opposed to a specifically defined goal. What this tends to do is increase the ability for the participant population to expand and change the goal which tends to increase cost. Key determined statements need to be used in the statement process such as Implement Organizational Management using standard reports and processes with no more than one custom object, relationship and evaluation path supporting the implementation. This tells the team as well as the participants what the goal is and what parameters exist for defining that goal. This allows the team during the process to keep steering the team back to the goal when necessary. 2. Sign off protocols put in place and managed to if only one component of the blueprint process can be said to be the key factor in determining project success, this could very well be it. Sign off processes and protocols need to be in place and managed to in order to ensure everyone understands what is going to be delivered. If the review processes that support sign off are not in place or if the wrong level of individual is completing the sign off process there will be failure. Typically to allow for success in the implementation, at the start of the project a sign off process Confidential and Proprietary to Revolution Technologies, LLC

Page 13

for blueprint will be established and include by module who must participate in the final blueprint review and sign off. This allows people to know up front what their accountability is. That in turn makes it easier for them to take an ownership mentality in all preliminary review processes and to guide participants as necessary during the process. 3. Integration management during the blueprint process integration requirements must be defined and managed. What does this really mean? It means that where cross-module touch points exist participants from both modules must participate in the blueprint process. By defining the integration points and managing the blueprint process participation around those integration points issues that could cripple the project later can be identified and dealt with up front. When integration discussions wait until the realization process, often times what happens is the implementation itself will get brought to a stop as the integration teams will need to go back and figure out how to handle the process changing the blueprint. Dealing with this up front reduces costs related to integration failure during the realization phase of the implementation. 4. Blueprint staffing this key factor may be obvious but still it bears stating. The blueprint process must be staffed with the right people in order to allow for success and these people must be empowered to make decisions. If the right people that can make decisions are not in place the implementation will fail because either during realization or UAT when the decision maker gets access to the system the entire blueprint will be negated and the team will be back to square one. The profile of Confidential and Proprietary to Revolution Technologies, LLC

Page 14

the right person to participate in the blueprint is typically an empowered decision maker that has been guided to modify current processes where required to be able to utilize standard SAP while ensuring that planned processes allow for continued business success and advancement in their area of expertise. That means as an example from a production planning perspective to a session on scheduling, include the line manager accountable for making sure the production schedule is fulfilled as he can identify risk and help figure out how to optimize what can be done versus what is being done today. 5. Top down buy-in this critical aspect of blueprint success means that senior organization leadership believes in what is being done, has expressed that belief to participants and is providing support and back up to the participants as required. This in turn empowers individuals to change the way the organization will do business in the future making both the system and the people successful. Without this buy in and support organizations will typically see current state processes replicated in the new SAP system with expensive difficult to maintain customizations included to allow for business as usual to occur. While monitoring the blueprint process some cues to watch out for that can be used to identify risk to the implementation are items such as: a) incorrect participant representation, b) integration participants late or no shows at defined sessions, c) lack of senior management participation and input, d) customization requests accompanied by statements like Today we.. and e) a lack of participation in sign off or a request for provisional sign off as opposed to full

Confidential and Proprietary to Revolution Technologies, LLC

Page 15

sign off. When any one of these items occur it implies a potential jeopardy, if more than one occurs, the project risk increases exponentially.

Transport Management Transport management though technical in nature is still a key contributing factor to the success of an SAP implementation. Many organizations have a technical process for releasing and migrating transports and even have soft processes that support the technical release but the failure point tends to be in coordination of the two steps. Successful SAP implementations work to integrate the following factors into the transport management to ensure success: 1. Integration review of transports prior to migration many organizations set up and run transport review meetings but the meetings are not integration focused. To see success in the transport management process the transport reviews must be integrated. That means rather than addressing what is the transport number is, the meeting must address what is in the transport, what it does and what other areas may be impacted. This gives the other module team members a chance to understand what is going in and determine pre-migration if there is a potential point of conflict with other development and/or configuration that will need to be cared for to prevent other issues. When this is done it cuts down drastically on the volume of defects in the implementation. 2. Standard naming conventions it may seem simple but establishing a simple naming convention at the start of the project for transports make it easy for everyone to identify the module migrating transports and basic detail relative to the content of Confidential and Proprietary to Revolution Technologies, LLC

Page 16

the transport. This in turn helps people prepare for the integration meeting to determine where there may be greater levels of integration with the work of their team that needs to be examined in the meeting. 3. Release note process very important is to create a release note process. This process should define a basic template to be used by team members that defines in greater detail what the transport is, why it is being transported, what it does and who (what type of users) are expected to be impacted by the transport. This information helps in training plans, integration review preparation and issue identification prior to migration of the configuration or development. 4. Scheduled transport process during the implementation, many organizations will allow changes to migrate between environments daily, some weekly, others biweekly. Regardless of the project transport schedule, the key is to establish an actual schedule on which transports occur. That means if it is five oclock every afternoon it is five oclock, not five-fifteen or five-thirty, five oclock. This starts to put everyone in a mind set of scheduled migration which in turn begins to eliminate the need for emergency transports. The schedule should also be established to that it provides the testing team with adequate time to maintain a stable environment to conduct testing without constantly introducing new configuration and development which can skew testing results. A typical successful implementation team will see transports during the realization phase moved twice per week. 5. Emergency transport process and protocols the emergency transport process and protocols should be defined with an eye towards usage beyond go live. That means Confidential and Proprietary to Revolution Technologies, LLC

Page 17

that the process established to support implementation for emergency transports should also support a live environment. This process should typically include an expedited integration review, concurrent agreement by all parties of the jeopardy imposed by not transporting immediately and project senior level management approval prior to migration. This allows for the necessary integration and documentation with management controls on the volume of occurrences as if all parties do not agree to the emergency situation, the transport will wait to the next scheduled cycle for migration. There are three key cues to failure in the transport management process that can lead to increased expense and implementation duration. Those key failure cues are missing release notes, lack of or no participation in integration review release meetings and excessive volumes of emergency transports. If one or all of these cues are visible in the implementation that means risk is being introduced into the project that now needs to be managed.

Testing Testing is the final step before the actual cutover from legacy systems to the SAP system. Organizations tend to take very different approaches to the testing step in the implementation. Regardless of the approach and the organization however, to be successful the following must be highly identified and managed through this stage of the implementation: 1. Test script creation and management to ensure success on an implementation test scripts need to be formally documented whether testing is being done and managed through a tool or standard MS-Word documents are being used. The test script Confidential and Proprietary to Revolution Technologies, LLC

Page 18

should identify the goal of the script, what role or roles will be used to test the functionality and then the steps required to complete the test. Additionally, any data that must be setup in order for the test to be executed successfully should be identified. Once all of the scripts are documented, a management process should be established to track and monitor the scripts for changes, executions and related defects. This provides the team with a catalog of tests based on processes that can be reused over time as required and identifies by test script discovered and resolved defects. 2. Testing sign-off process a process needs to be put in place prior to the formal testing cycles begin stating what sign off is, how it is achieved and who is responsible for gaining and delivering the sign off. This ensures that there is clear direction going in as to when sign off is requested and of whom it is requested. This can in turn be used as a stage gate to move the project forward through the various testing phases. 3. UAT charter and processes established and managed at the start of the project, there must be a clearly defined charter for the user acceptance testing period along with the process for how UAT will be executed. By having this defined and available up front schedules can be cleared and the appropriate participants can be trained and ready for the UAT process. Control processes need to be established and managed for the UAT process to ensure what needs to be tested is tested and the appropriate level of participation is received. UAT will usually include key stakeholders in the system as well as the expected power users of the system. A Confidential and Proprietary to Revolution Technologies, LLC

Page 19

defect identification and management process also needs to be established and documented that allows for tracking and monitoring of defects, their resolution and the retesting process for sign-off. 4. Defect management process - mentioned previously specifically as it related to the user acceptance testing process, the project must have a clearly defined and documented defect management process. In order to ensure success, a solid defect management process will typically be defined by the ability to trace defects to specific tests scripts along with the data in the script. It will also provide the ability to track defect resolution related transports, transport migration date and retest results. The process should be reportable and during each test cycle reports should be generated on a regular basis and supplied to project management and senior management as a measure of visible success and/or failure that can be used to adjust the schedule and manage the implied risk as required to allow for success. 5. Final sign off gates established and managed this may sound obvious, but it is often a skipped step in projects. Successful implementations define at the start what the sign-off gates for each phase of testing (unit, integration, string, load, UAT) are. This way the stage gates can be reviewed, monitored and measured allowing for meeting the timeframes required to bring the project in on time and on budget. The gates should be defined, documented and appear as milestones to be managed to in the project plan. Project management should conduct stage gate readiness reviews beginning on average three to five weeks prior to the scheduled stage gate finalization date to be able to manage risk appropriately. Confidential and Proprietary to Revolution Technologies, LLC

Page 20

As stated previously, testing in different organizations will always look different and will always reflect the organizational testing protocols. It is important to note however that risk can be identified in implementations when the following cues become apparent: a) no or a lack of formalized test scripts, b) defect management process being ignored/avoided or not existing, c) lack of stabilization period in which to conduct testing typically represented by several emergency transports occurring over time, d) unclear stage gates or confusion around the sign off process and e) team members testing their own configuration and/or development outside of the unit test cycle. This last cue is the most dangerous and most costly an implementation can see.

Cutover Planning The final step in the SAP implementation is the cutover. Before the cutover can occur however, a successful cutover plan must be put in place and managed to. In successful implementations the cutover planning process will incorporate the following: 1. Defined cutover timeframe a critical success factor in the implementation is the definition of the cutover period. Most organizations will define cutover as the conversion period and when that happens key items required for a successful cutover wind up getting skipped. Projects that define the cutover period in such a way as to allow for production preparation and readiness, final transport cycles, conversion and monitoring establishment processes see a much higher level of cutover success. The key to the cutover period being defined and including items such as those previously mentioned is to alert the team and those teams upon which Confidential and Proprietary to Revolution Technologies, LLC

Page 21

the implementation is dependent that the final stage is present and go live support requirements are imminent. 2. Definition of cutover deliverables mentioned indirectly in the previous factor to a successful cutover are the deliverables of the cutover. While these can be highly subjective based on the scope of the implementation and the organization implementing, the step is not subjective. In order to be successful the project team must identify all items and system dependencies and interdependencies that must be completed and in what order to allow for cutover success. As an example, the deliverables include sunset accounts payable system including sub tasks of receiving file for conversion, file validation, converting file and data load validation 3. Cutover specific task plans once the deliverables are identified along with the order in which they need to occur, the specific tasks along with who needs to execute each in order to ensure success can be identified and managed in a task plan by sub team in the implementation. The task plan would include (working from the previous example): files must be generated by AP team and reviewed by AP analyst before they can be provisioned for conversion. Net services will migrate the files to the centralized project repository for receiving files. Once received, the provisioned files must in turn be received and logged into the project server, loaded to a defined server location and then reviewed by the AP conversion developer to validate the file format, the conversion can then take place. After the conversion, the error reports can be generated by the AP functional analyst. The data can then be reviewed, the loaded data can be reviewed and spot checked by the cutover team AP Confidential and Proprietary to Revolution Technologies, LLC

Page 22

analysts and finally the file conversion can be signed off. Each of these is a separate task for which a specific individual is accountable for completion in a successful cutover process that if skipped, missed or not tracked could cause a failure. 4. Cutover specific task plans each team within the overall project will be managing task plans for delivery against the larger project plan along the way of the implementation. The cutover task plan is a bit different in that where the implementation task plans can be successfully managed in a decentralized fashion, the cutover task plans need to be managed centrally in order to ensure milestone completion. If it is managed in a decentralized fashion, often times checkpoints one person thought were completed are actually not confirmed prior to moving to the next step causing post go live maintenance risk. 5. Definition of success for each task each task in the task plan will have a clear indicator that can be tracked to state success has been achieved or failure has occurred. This allows for a clear understanding to all involved how each step in the cutover task list is resolved. That allows for immediate risk management to occur in the most critical period of the implementation that is targeted, specific and defined. 6. Go/No Go decision process supporting the cutover plan on successful implementations will be a clearly defined go/no go decision making process that is used at defined times in the cutover period. The process will include involvement by the appropriate team members and support staff that will be accountable for future state operations and receiving the productive system. The go/no go decision Confidential and Proprietary to Revolution Technologies, LLC

Page 23

process should be clearly defined with parameters and measures that leave no room for subjectivity. Making the final decision dependent on concrete parameters removes emotion from the process and provides for a greater level of success. Identifying risk cues in the cutover process can be a difficult process because of the high level of detail involved in a successful cutover. There are however some more general things that when they occur rapidly or often can be used to identify risk that requires management. Those items include: a) a lack of ability to identify what actually needs to be done, b) lack of cross functional participation, c) inability to determine interdependencies and d) a lack of legacy system tasks being identified and included in the cutover plan. When the identified failure cues are identified risk mitigation is required to ensure project success.

Summary The thing to remember about planning the implementation with an eye towards success is to plan, execute and deliver against a measured plan. Having documented processes in place with strict controls to measure those processes reduces risk. Reduced risk allows for cost savings during the implementation cycle. With the goal being successful on time on budget delivery a risk minimized process is the best method to achieving that success.

Confidential and Proprietary to Revolution Technologies, LLC

Page 24