Geeks With Blogs
Microsoft Dynamics GP (Great Plains) and CRM Implementations with Ryan McBee of iSolutions Partners Microsoft Dynamics GP (Great Plains), Management Reporter, eConnect, SQL Server 2016, Reporting Services

Driving for Success:
Leadership Essentials
for Software System Implementations

As the most critical success factor in major software implementations, project management is a crucial topic. It is also a large one, and it has inspired Analysis Team to begin a series of articles on relevant project management functions.

This introductory article analyzes key success factors and pitfalls in systems implementations. The main emphasis is on proven techniques that work. There is also a candid view of where these projects commonly go wrong and why poorly conceived projects are doomed from the beginning.

Thinking about the systems project proposal on your desk

If you are faced with a proposal to implement a software system, whether it is enterprise-wide or much more limited in scope, how can you decide whether the project is worthwhile? If you are being asked to analyze a systems implementation plan, how can you judge the project’s likelihood of success? Does your organization have a strategic plan for IT that helps you assess the fit of the proposed system to the business strategy? How good are project management skills in your IT department? Does management perceive that the company is getting a positive return from IT investments? Do these questions deserve your most careful consideration? Consider some facts.

Several years ago, Gartner reported a study of the performance of Fortune 500 companies in large-scale systems implementation projects. At the Financial Executives Institute “Forum on Business and Technology” in Dallas, Texas March 3, 1997, a Gartner consultant cited the following statistics. 20% of these projects were rated successful and 25% were failures. Failure in many cases meant walking away from multi-million dollar investments. The other 55% that were less than successful, but not outright failures went something like this: they took 98% more dollars and 122% more time than budgeted. When they were complete, they delivered about half the functionality that had been expected in the project justifications.

The Technology Survey for Financial Executives published annually since 1998 by Financial Executives International and Computer Sciences Corporation found that ERP implementations at an increasing proportion of companies have taken substantially longer to complete than planned. Although there has been some improvement recently in actual cost of ERP implementations compared to budget, last year 21% reported project costs that were more than 30% over budget and 29% spent 10-30% more than expected. Project management is the number one IT staff weakness, regardless of company size. The survey consistently finds that substantially more than half of companies do not have a written plan for IT (including many large companies) and that roughly half of the financial executives rate their return on IT investments as negative or unknown. More information on this FEI/CSC Study is available at the Financial Executives International web site.

Not persuaded by the numbers? Here is a cautionary tale:

A March 12, 2003 Los Angeles Times headline read “Cal State Over Budget on Software.” The article was based on an Audit Report that is available on the California state website. The newspaper reported that back in 1999 they budgeted $440 million for a “management software system, intended to track personnel, financial and student records on 23 campuses.” This was “one of the largest software projects ever undertaken in higher education.” The Common Management System was “to replace a mishmash of incompatible software systems dating back in some cases to the 1970s.” The software came from PeopleSoft.

Spending is now projected to be $662 million. The report said that “They didn’t put together a feasibility study and say ‘OK, what are we hoping to accomplish with this system and what will be the benefits and what will be the costs?’” The report from the state auditor attributed most of the excess costs to a failure to include spending on “maintenance, operations, implementation and other work by their [the university’s] employees.” Some university officers protested that including maintenance expenses in the appropriation would be “unorthodox.” Faculty and unions are complaining that the high cost of the software is diverting money from academic programs leading to layoffs. The Cal State Chancellor said “CSU was vindicated by the audit in that it found no criminal wrongdoing and mostly focused on procedural matters that the university agrees need improvement.”

Now that I have your attention, here are proven methods to maximize your chances of success. There is a rich management literature on most of these steps. Whether your management group has all the skills or whether a consultant is needed should be assessed before proceeding with a substantial systems implementation.

Project Initiation
  • Document Processes
  • Define Project Objectives and Metrics
  • Assign a Full-time Project Manager
  • Draft Project Plan
  • Perform Risk Assessment
Document the relevant business process in flowcharts. The team appointed to do this must be cross-functional if more than one function is involved in the processes. Include all activities, transactions and information flows that will be encompassed by the system. Be particularly careful to document exactly what happens when information flows from one department or function to another.

Analyze these flowcharts with relevant managers to identify ways to improve. You are not done until your team has arrived at a consensus around the most important process improvements. Collectively, these improvements must be strategic in nature and clearly linked to the business plan which explains how the enterprise expects to succeed in a competitive market.

Once the analysis of potential benefits is complete, it will be possible to quantify a number of them, either in terms of cost reductions, quality improvements or lead time reductions. This will help establish project metrics, but bear in mind that it is difficult to quantify some of the most important benefits of information systems such as easier access to information, more relevant information for decision making and better customer service.

Although you cannot provide information about intangibles that will be reflected in the cash flow analysis, it is still very important to put such benefits into writing. This will be part of your detailed implementation plan, which should be included in outline form in the project justification. A systems implementation is usually expensive and risky. There must be compelling reasons for the project; otherwise you are better off continuing with the current systems and focusing on other major business issues.

For an expensive and managerially difficult project to succeed, there must be buy-in by all senior managers and there must be a high level champion for the project, ideally the CEO or one of the most powerful corporate officers. This is the Executive Sponsor. Without this individual committed to the success of the project, inevitably there will other matters that compete for people’s attention and undermine the systems project, perhaps fatally. When serious problems develop, as they always do with a major enterprise, the Executive Sponsor must be there to determine what is necessary and lead efforts to muster the resources to get the project back on track.

Before the first step is taken to choose and implement a system, it is essential to have a project plan and charter. If possible, prepare this for management to review at the same time they are considering approval of the project. This is the time for everyone to define what they are committing to in every respect. This will enable management to assess the risks associated with the project and obtain everyone’s commitment to activities that are essential to the project’s success – before the project is approved.

The plan should define improvement metrics for each business process, project leaders, the scope and timing of implementation steps, status reports, project review meetings and the principles that will be followed during the implementation. Principles will set forth the rules to be followed in such matters as custom programming, purchase of completely integrated systems from one vendor or best of breed from several vendors, commitment to make people available for training, the role of consultants and the like. The project plan will require a major revision once the vendors have been selected but before the final funding is approved.

Regardless of how carefully the plan is developed, in virtually all projects, large and small, there are some unpleasant surprises. Some of these relate to risks which are known or can be identified at the outset. As the implementation plan and the project’s financial approval request are prepared, there should be a risk assessment. Management, consultants and even some hardware and software vendors can help identify risks. The assessment may include contingency plans for certain risks that are clear and substantial. For each risk that is identified, there should be a clear statement about how management may learn about a developing problem at the earliest possible time – an early warning system.

The end result of the analysis must be a report that documents business processes and spells out exactly what the deliverables will be from the completed systems implementation. There must be a thorough financial analysis of the investment, maintenance costs, employee time to both implement the new system and of how operations will be affected by the change from the old system to the new.

The implementation will require significant management resources, commitment and milestones to be achieved. There is no way for senior management to make a good decision about a technology investment without some understanding of the implementation plan. The project justification should identify the project manager and the implementation team, the involvement of any software consultants, training or other people requirements. If the project is substantial in nature, such as enterprise-wide, the project manager must be virtually full-time, an employee of your company and have impressive project management skills for the project to succeed.

The communication plan is also a key element of this early phase. There should be provision for a weekly meeting of the project manager with senior management to discuss the details of how the project is going relative to plan and what additional resources or support are needed to get to back on track when problems occur. A hands-on approach by all the relevant managers will be essential at that stage. Note well that completing all prerequisite steps successfully does not guarantee success; it just makes a successful implementation possible.

At this point, you are ready to begin consideration of software and hardware that may help achieve significant improvements or, conversely, to determine that there is not enough potential with new systems to justify significant investment. If you do not have documented processes and an agreed list of important and specific improvements that are needed, then you are in no position to make sensible decisions about investment in information technology.

Project Preparation
  • Perform Software Research
  • Perform Readiness Assessment
Take a look at one or two leading software products that seem to have good potential. Try to pick vendors that cater to companies of your size. Collect cost information, but the main focus should be on functionality and reliability. The software must be proven and reliable if the project is going to deliver value to the enterprise. Is there clear evidence that breakthroughs in productivity, cost reduction, quality improvement or decision support are possible with one of these products? What major changes would you have to make in your processes in order to use the software? Armed with a good understanding of your processes and exactly how you want to improve them, it is not very difficult to make a preliminary assessment of a system’s potential.

Following this assessment, your team should consider whether the company is ready for the major changes that will be necessary with the kind of system you have just analyzed. This is another key reason that it is essential for top management to buy into the project. Without their commitment, your project management skills will be undermined by constantly changing priorities and lack of resources. Are the preliminary cost figures consistent with the budget? Does it appear that sufficient benefits are possible to justify the investment? Are the benefits aligned with your company’s strategic goals? Will the impact to your employees be significant enough to warrant organizational change management?

Data Audit
  • Identify Platform Requirements
  • Assess Data Condition — Cleanse and Optimize
There are several database management systems that underlie most systems. At this date about 75% of systems rely on database management systems from three companies and the combined market share of these three companies is increasing. Some of the companies in this business are prospering and others will disappear during the next few years. You do not want to be stuck with an application system where the database management system is not keeping pace with the competition or a vendor whose market share will dwindle.

Before you look at application systems, it is best to determine which database management systems are adequate for your current and anticipated needs. This will greatly narrow the search for promising application systems.

With the close collaboration of your systems department and line managers, it is essential to determine whether your current database is clean and in a condition ready to transfer data to a new system. Cleaning up a messy or overly complex database is one of the most underrated and challenging projects in systems implementation. This can be a parallel project while all the other steps listed here are progressing. Until the current data and history are moved successfully from the old to the new database management system, it is impossible to use the new system. Data cleaning and conversion issues are among the major causes of implementation delays and disasters.

Vendor Evaluation
  • Finalize Requirements Analysis
  • Prepare Request for Proposal (RFP)
  • Evaluate Vendor Responses Using Objective Methodology
  • Research Vendor Track Record, Vendor Stability, and Software Installed Base
  • Remain Realistic
Now that you have some understanding of your processes, your priorities, what a state-of-the-art system looks like, database systems and you have management’s commitment, you should be ready to look at application systems in depth. This will be a very time-consuming project. You may have to document additional processes that you now understand are relevant. You may have to change priorities based on your understanding of processes, input from top management and input from information technology vendors.

At this point, you must have a clear understanding of all your requirements and you must have weeded out feature and functionality requests that are not essential. Your list of requirements, even for an enterprise-wide system, should be no more than a few pages long. Much more than this may cause you to get lost in the assessment and be unable to make a good decision.

But while your list of requirements should be limited, your formal Request for Proposal (RFP) should be very thorough. It should be divided into sections that require specific responses from vendors on such concerns as hardware requirements, functionality, technical support, implementation process, and training. This document is your specification, and it is your job to assess for each question whether the vendor exceeds, meets, or fails to meet each point of specification.

There will be fierce competition among your short list of software vendors. Take advantage of this to gather all the information you can that may have an important bearing on the decision. Take all the time and care you need to assess what you are hearing. This can be a politically charged process with various people promoting their favorite vendors without much regard for the result, and software vendors pointing out failures with competitors’ products. It is essential to be thorough, realistic, and specific on each point of the specification, and to deploy an objective methodology to tabulate the results.

This can be quite challenging and a poor analysis at this point can doom the project. During the fray, be mindful of the requirement for a consensus around the system that will be selected. When a decision is made, people have to be able to collaborate during the implementation as they perhaps never have before if the project is to be successful.

Customer satisfaction, vendor stability, and the installed base of the product release under consideration are also critical concerns. Reference customers should be contacted and, on the more complex projects, visited. Be careful to choose appropriate references; if your company is a middle market firm and all the references are Fortune 500 companies, or vice-versa, you may not be receiving the information you really need. Review financial reports of the vendors and try to assess whether they will be around to support their product. Some companies will fail. Others will be acquired by larger companies who are only interested in the maintenance contracts on the installed base. Either way, customers are the losers.

The viability of the software itself should also be investigated. How many customers have implemented the system you are considering? Is this customer base large enough? Is it growing? Talk with people who are leaders in the users group. Are the new releases buggy? Do they deliver value for the expensive maintenance contracts? Is the specific product under consideration gaining or losing market share? Bear in mind that this question is different from the one about financial survival of the vendor.

Some business systems vendors offer ancillary products that work with their core systems. For example, some make information retrieval, analysis and reporting easier. It is usually worthwhile to consider whether products from other vendors who are specialized in these supplemental systems may have something that is much more suitable, such as an on-line analytical processing (OLAP) system, or a payroll and human resources system, or a reporting system.

You should decide much earlier, probably during project initiation, whether or not to consider these modules. If you do decide to consider them, include them in the RFP and make it a level playing field for all the vendors. Considering them does not mean you are obligated to buy them. It is critical to make decisions based on analysis, not emotion. Vendors will try to make the decision turn on emotion if it is to their advantage. For instance, if a deal appears lost, tactics designed to discredit decision makers in the eyes of their superiors are not unheard of.

Bear in mind that doing a good job with the analysis here is only useful in anticipating what will happen with the vendor for a year or two. You should go into this project with the realization that the competitive landscape is likely to be radically different within five years and you may have to change software vendors at that time.

Pre-launch Review
  • Re-assess Plan
  • Identify Risks
  • Validate Original Assumptions
At this point, consider your chances of success if you have not successfully completed the steps discussed above. Before you sign the vendor contracts and launch the project, if you do not believe all the steps can be completed successfully you must ask yourself, “Do we really want to go ahead with this system?” When the project begins to stretch out, cost more, and there are problems with functionality and competing priorities, what are you going to do?

When this happens, most managers are in a hopeless position. They do not understand their processes, they are not clear about their objectives, they may have made a poor choice of software or hear that they have, and they do not have management support. They know that, if the project is completed, it will cost more, have taken more time and will not deliver significant functionality that people expect.

The finger pointing begins, collaboration and trust are lost. The software vendor has your money and may no longer be committed to the project. Your consultants are prospering perhaps much more than they expected to. If your company is not prepared to do this systems project right, do you want to stake your career on such a project?

User and Enterprise Validation
  • Conduct Conference Room Pilot
  • Prepare Detailed Implementation and Rollback Plan
  • Back up Data
There are two widely used system validation techniques – running the two systems in parallel and the conference room pilot. The first is impossible with systems of any complexity or large-scale because no two systems of this scope produce exactly the same results. Further, processing transactions twice will burn-out people unless it is of very short duration. In such a risky project, there is no way to be sure how long the parallel transaction processes might be needed. Generally people who choose this approach are in a poor position to make such an assessment.

The second approach requires that selected users of each system module first be trained, then work with a test database to try to process all the kinds of transactions that they will when the new system goes live. When users are comfortable with this across the spectrum of transaction types, consultants from the software company validate that the specified results have been achieved. Management and everyone else involved in the project assess the result.

If everything is OK, over the weekend you pull the plug on the old system and you are up and running on Monday morning. Even at this point, there are often dire problems, so just in case something goes wrong, it is essential to maintain backups of data and have foolproof procedures to restore the system to some previous state.

Although the conference room pilot technique has been used successfully for many years and is clearly the best way, software vendors often do not express a preference for this if management wants to run in parallel. If you ask, they can provide references to companies that have used the conference room pilot successfully.

Post-Implementation Review
  • Conduct Review of Project Costs and Return on Investment
  • Publish Results
Throughout the project, a capable project manager will be constantly comparing results with the plan. At the conclusion, the project manager, the IT manager and a financial analyst should do a post-implementation review. This is partly financial, but also includes careful consideration of the non-financial project deliverables.

Much can be learned from this that will affect future IT investment decisions and systems implementations. It is important that the right lessons be learned and the relevant facts be presented objectively to everyone with a stake in the project. In very complex systems implementations, there are inevitably a lot of differing and strongly held opinions about how things went and the value of the new system. A fact-based audit can help clear the air, focus on the positives and help ensure rationality in future decisions.

Important Issues to Beware
Avoid customization (or carefully control it) so you can implement vendor upgrades: As you make your decision, there will be areas where the software does not perform exactly as you would like and there will be the temptation to do some custom programming that can seriously impair ability to implement new releases from the vendor. Changes in the appearance of screens and in certain reports can usually be accommodated without such impairment.

Use the software vendor or someone they have previously worked with to do this in a way that facilitates implementation of new releases. Even here, it is important to keep such changes to a bare minimum and document them well because they will be revisited every time you implement a new release, apply a patch, or troubleshoot a problem. Even when you do everything right, there is a substantial price to be paid in the future for every instance of customization. The initial cost of programming the customization is just the tip of the iceberg.

Right sizing hardware: What often happens with large scale systems projects is that the software and hardware vendors that are working together will low-ball the required computer capacity and certain other hardware requirements for naïve customers, knowing that by the time management realizes a larger computer is needed, they will be too far into the project to switch to the competition.

It is a common error is to buy a lower cost computer at the top end of the range that barely meets your requirements, instead of the higher priced one at the low end of the range of bigger computers that can handle growth. Later when you begin to reach capacity and the system performance slows unacceptably, you have no choice but to replace the hardware since you can not upgrade certain components of your computer. Hardware vendors prosper from decisions like this.

Your systems department should work with potential hardware vendors to determine exactly what hardware will be required to support the new system. If you do not have the expertise in-house, it is well worth it to bring in an outside consultant to right size the hardware objectively and accurately – and to keep the vendors honest.

New System Acceptance: At the completion of the project, when the time has come to abandon the old system and begin using the new one for all transactions, with integrated systems you are facing an all-or-nothing proposition. You can rarely continue to use parts of the old system where the new one is failing and use the parts of the new system where the implementation has gone well. If everyone understands this at the outset, they should be more committed to success.

Many businesses and non-profit organizations are not nearly as effective as they could be due to failed or less-than-stellar systems implementations. Even with the best plans, however, systems implementations (especially those that involve all the principal processes) are fraught with peril. When a large systems project gets in trouble, senior managers are often clueless as to how to get back on track. Usually this is due to a poor analysis of the processes encompassed by the systems, lack of realistic process improvement metrics and lack of careful implementation planning. Projects that are in trouble spiral out of control and become major failures.

Here we have analyzed these risks, shown how to avoid them, and defined the essential elements of successful systems implementation management. These are the best tools possible for assuring a successful implementation. But don’t stop there; at the conclusion of a project, we recommend an analysis of the results and an effort to learn from what happened.

Dewey Norton

Posted on Friday, May 26, 2006 12:39 AM Dynamics GP | Back to top

Copyright © Ryan McBee | Powered by: