Maximize Your Investment: 10 Key Strategies for Effective Packaged Software Implementations

Robbins-Gioia, LLC, a provider of management consulting services located in Alexandria, Virginia, conducted a study of the perception by customers of their ERP implementations. The study included 232 survey respondents, spanning multiple industries, including Government, Information Technology (IT), Communications, Financial, Utilities, and Healthcare. A total of 36% of the companies surveyed had, or were in the process of, implementing an ERP system.

Key findings:

This survey interviewed executives at 117 companies that attempted ERP implementations.

Key Findings:

Nearly 90 % of ERP implementations are late or over budget ¹ and the ERP implementation success rate is only about 33%. What are the causes for such dismal results? I am firmly convinced that our expectations and approaches to ERP or any Commercial Off The Shelf (COTS) software implementations are the primary drivers. I will spend some time on a few of the key areas that we need to address in order to improve upon the packaged software implementation experience. First and foremost, what I am talking about is the implementation of a business solution.

Today, the majority of business software vendors say that they provide business solutions. The term "business solution" is one of the key buzz words used to try to uniquely identify a software product offering. And as such, it is being misused and basically getting "watered down" — just like the term "business process".

I believe in the term "business solution"; however, no software can provide you with a "business solution" — only the vehicle to get your organization from point A to B. Before we can implement a business solution, we must first understand what a business solution is. I like to view a business solution as three components:

Now, here is something interesting to consider: "Do you need all three components to have a solution for your business?" Let me address this in another way, "Do you need software in order to conduct business?" I am persuaded to say that the answer is no. Business was being conducted before the invention of the computer. However, I am quite aware that not having software as a part of your business is not practical in today's competitive marketplace. I do want to demonstrate that software only supports, and therefore can only have a certain level of benefit to, a business. Packaged software does not have the capability to make key business decisions. It is key business decisions that drive business results. Business software can provide information and data to assist people in making business key decisions. Seen in this light, one can conclude that people are the most important component of a business solution. Case in point: I have been on successful business solution implementations in spite of software limitations. I have been on successful implementations in spite of not having all of the business processes clearly defined. However, in my fifteen years of implementation experience I have never been on a successful implementation where the people (i.e., organization) were not ready for the new business solution. People have the greatest impact on the success of a business solution. Is it not interesting to note that the majority of packaged software implementations focus mostly on products and technology.

I have listed the components of the business solution in the order of priority and significance. Very often, you will see business solution implementations deal mostly with products and technology during the first three-quarters of the implementation and only at the ending phase of the implementation is there any consideration of the other components of the business solution. Software and technology are important; however, your implementation strategy should not fixate on a single silo. The optimal implementation strategy will focus proportionally on each component of the business solution based upon the impact that each respective area (technology, business process, and people) will have on the implementation's success. To accomplish this change in our implementation strategy, we must first address a couple of popular perceptions in our industry today.

I remember working on my first ERP implementation (in 1994) for a customer where we were implementing a solution for human resources, benefits, and payroll. I was the functional lead consultant for the payroll application. The customer's payroll manager and I were discussing how confident we were with the payroll capabilities of the new ERP system, before the go-live event. I said that I was confident that the payroll process would be handled correctly within the ERP solution but I was unsure about the payroll expense accounting entries generation (which was going to be handled by an in-house utility). Therefore, the payroll manager said we have a payroll issue. I reiterated that the ERP payroll solution is complete and that we could create paychecks. The customer's payroll manager said "I don't care if this ERP payroll system creates paychecks in thirteen different colors! We have a broken payroll process because we cannot complete the final payroll activity: booking to the general ledger!" I must admit I was pretty "wet behind the ears" at the time and this customer's statement stuck with me throughout my career. Customers do not care how wonderful and streamlined the intermediate steps are if the process cannot produce the desired business results! The majority of business results that a customer is interested in are not even produced inside the software itself. For example, running a report is not a business result. A business analyst making a decision based upon information in a report — now that is a business result (the decision).

If the desired business results are not produced, then the implementation will be considered a failure by the customer — regardless of whether the business software was moved into production successfully.

Customers — one of the key factors that will have a huge impact on your implementation's success or failure is your implementation partner. On average, an implementation of packaged business software costs at least three to six times the cost of the COTS software. This fact is resulting in customers spending more time selecting the best implementation partner possible. However, this should not be the extent of the customer's investment with the implementation partner. Every customer I've worked with has insisted that their implementation was unique — and this is a correct statement!

Revisiting our definition of a business solution, it has been my experience that every implementation is unique in the following areas:

No implementation partner will have a complete appreciation of the customer's business solution until the customer makes the investment to perform knowledge transfer with the implementation partner. The greater understanding and appreciation that your implementation partner has of the customer's existing business solution, the greater the probability of the success of the customer's implementation partner and the enterprise solution implementation.

I am an avid hiker. I love to hike and I try to find ways to coax my family to hike with me. I remember the first time that we went on a long family hike, which my wife lovingly refers to as a "death march". I was in the lead, setting the pace. It was a good pace for me but it was difficult for my wife and daughter. You see, my wife and daughter do not hike as much as I do. Needless to say, their experience was unpleasant and it was some time before my wife and daughter would go on another hike.

I suspect that many customers have similar experiences with their initial packaged software implementation. In most cases, the implementation partner was in the lead and most likely had several packaged software implementations under his or her belt. For many customers, the implementation of packaged software was new ground for them. Given the pace, most customers only had time to focus on execution and not on truly appreciating the purpose or objective of their actions. It was a "death march" mentality that resulted in poor customer ownership and user experience. Customers had such a bad experience that afterwards it was extremely difficult to get the customers to upgrade their existing packaged software. Upgrades are a key method to extend the investment and generate additional business value from packaged software. Without periodic upgrades to existing packaged software, the customer will eventually experience a negative Return on Investment (ROI).

I decided to take a different approach on our next family hike. I decided to let my wife and daughter lead the way and I would be in the back, supporting. To my surprise, we made it up the mountain and we enjoyed the trip without losing a substantial amount of time. Even more important was the fact that my family was willing to hike with me again!

The first day of any implementation is the first day of transition from the implementation partner to the customer. Several implementation partners treat transition as the last step in a go-live event. This approach by implementation partners results in a customer not being ready for, or confident in supporting, their business solution. A customer should never feel that way! Allowing the customer to lead will naturally drive the implementation partner to be more focused on knowledge transfer to the customer, which will result in a better success rate for customer preparation.

For any business solution implementation, gathering business requirements is paramount, and is one of the hardest activities to conduct successfully. And where do you look for business requirements? Business processes, of course. Business processes can be:

How do you gather these business requirements in a meaningful way that will result in defining a complete business requirements model? How will you identify business requirements that may be in contradiction with one another? How can you validate your business requirements early and provide proof that the proposed business solution will be successful? One of the most important strategies for COTS implementations is maximizing the delivered capabilities of the software. Historically, the majority of packaged software implementation approaches utilize the testing phase as the critical point for solution validation. Unfortunately, this resulted in little or no time to react to unexpected results or circumstances.

Business solution modeling is an approach that will enable you to provide a proof of concept and validation of requirements early in the implementation lifecycle. Business solution modeling delivers hard numbers and results, so that you can quickly demonstrate the validity of the solution. Don't guess what the end result or organization impact will be — prove it! The greatest value that business solution modeling will provide to you is the ability to understand the implications of the decisions that you make as a project team.

To survive in today's competitive landscape, every implementation partner has their own proprietary implementation methodology. Many customers' internal IT organizations also have their own internal software development methodology. The spectrum of these methodologies range from heavy-weight (i.e., many rules) methodologies like Waterfall to light-weight (i.e., few rules) methodologies like AGILE. For the implementation of a business solution, there are several methodologies involved during the implementation. On top of the software development method is the Project Management Life Cycle that provides guidance on project management activities. If that is not enough, there is Organization Change Management (OCM), Business Process Management (BPM), and Quality Management processes like Six Sigma and Total Quality Management (TQM). All of these processes are relevant and necessary for the implementation of a business solution. How is one to manage all of these different disciplines and build a cohesive implementation approach?

As discussed earlier, the most important component of a business solution is people. The critical path to any successful business solution implementation is having people prepared and ready to use the new business solution. One of the hardest areas to manage during an implementation is organizational change. A key implementation strategy is to minimize the organizational impact, which will result in a greater probability of success with end-user readiness activities.

The implementation of COTS software will open up new functionality and business activities that the customer may not perform today. Resist the temptation to add new functionality, and only focus on what the customer needs to do today. Limit organizational change, and focus on building a solid foundation. The key to this requirements-gathering approach is to be able to identify the maturity level that the customer is executing within their business process. Capturing and managing requirements to the customer's current maturity level is the accelerated approach for requirements management. Technology alone will not enable a customer to move on to the next business process maturity level. If the organization is not feeling the specific boundary pains of trying to break through to the next business process maturity level, then focus on requirements that will meet the existing business process maturity level. There will be enough organizational change occurring during the implementation. Don't force the technology, or the technology will force you into a corner!

I consider myself to be a practical person, so I am not under the delusion that packaged software provides for all of the customer's needs and that software changes should not be allowed. I also realize that commercial packaged software will have gaps when compared to the customer's business model, because the marketplace in general drives packaged software requirements, development, and product roadmaps. By default, any software change that you make to packaged software will result in a higher Total Cost of Ownership. The question is: "Is the software change worth the cost?" I like to view software changes in two categories: enhancements and customizations. Enhancements are software changes that result in generating material business value to the customer. Customizations are software changes that result in generating minimal business value. In some situations that I have seen, technology has been used not as an enabler but as a crutch to support customer's non-value added business requirements.

Competitive and transformational requirements are, by their nature, specific to a customer. Enhancements add real business value. Customizations add overhead and complacency. Remember that using packaged software requires a fundamental shift in software expectations. Packaged software makes for an expensive solution! The best practice is to leverage delivered capabilities to their fullest, and focus on software enhancements that generate material value to your business model.

When executive management selects packaged software they are making the following statements:

However, what is said at the executive level and what is expected among the rank and file can be totally different. Unless you have executive management that can dictate across the breadth and depth of the organization, the project team will have to persuade end users that a complete turn-key solution is not in their best interest. Nothing is free, and this applies to end-user acceptance as well. Negotiating on business requirements is a certainty that must be planned for by the project team. Successful COTS software implementations are those implementations that are able to balance tradeoffs that result in minimizing Total Cost of Ownership while maximizing organizational acceptance.

If you are asking yourself the question: "Who is a business solution architect?", then this principle is for you. Let's review a business system solution from two different views:

Typically, implementation partners cover all levels of the software with the following roles:

As you make packaged software configuration decisions, you need to evaluate across the five levels of the business model to ensure that a configuration decision does not have an adverse impact on the overall business model. A project manager experienced in a specific business solution will be able to offer insight and guidance at the solution level. Functional leads should have expertise at the product feature level. Technical architects should have expertise regarding the underlying technical foundation that will support the business system.

Who will cover the business process levels? Typically, the implementation partner will leverage the functional lead role to cover the business process levels. Functional leads usually focus on a specific software product. It is important to note that it is very rare to have a single COTS software product supporting an entire business process. Therefore, you need a functional lead that has experience across multiple software products. Many have taken the approach of using traditional project roles to focus on both the products and the business processes, in order to save money. What they fail to realize is that during the implementation the functional leads must eventually focus on the individual software products that they are responsible for configuring. Focusing on business processes cannot be a one time event.

Making decisions during an implementation is based upon:

As an implementation partner, I found myself frustrated many times at the lack of speed with which customers made decisions. However, if I step into the shoes of my customers, I can see that from their perspective they had more assumptions and disjointed data than solid information to make an informed decision. Also, the customer was bearing most of the risk of not making the right decision.

By taking an approach of aggressively gathering information, implementation partners can enable customers to make more timely and accurate decisions. For example, let's visit the PMI PMBOK in the area of cost estimating3 or what I like to call "levels of understanding". Estimating is based upon our level of understanding regarding effort, scope, assumptions, constraints, and objectives. Generally, for implementations, there are three levels of understanding:

As you move further into the implementation, you are able to better estimate (understand). Question: Why does the confidence range decrease as we move along with an implementation? Answer: We have more proven information on which to base our estimation. Do you think this cause and effect would apply to other areas of an implementation (for example, requirements gathering, testing, or development)? Naturally, would you like to make decisions when you have more information?

For the implementation partners — if you want to enable your customers to make decisions quickly then you need to focus on two areas:

I use the term, aggressively, because an experienced implementation partner should know up-front the critical-path implementation and configuration decisions that a customer has to make for COTS software. More importantly, the information must be presented in the appropriate manner and at a level that will result in the customer making a decision.

For the customers — we live in a society where we like to keep our options open. Many say that keeping your options open will make you flexible to future opportunities. Many customers have applied this concept to technology and business systems. I have seen this philosophy trickle down into a customer's implementation decision-making patterns. Customers want to have a business solution that is adaptable and flexible. It is totally understandable to require a business solution that is adaptable and flexible. However, customers need to keep two things in mind: