Book Image

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

By : Grady Brett Beaubouef
Book Image

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

By: Grady Brett Beaubouef

Overview of this book

Using packaged software for Customer Relationship Management or Enterprise Resource Planning is often seen as a sure-fire way to reduce costs, refocus scarce resources, and increase returns on investment. However, research shows that the majority of packaged or Commercial Off-The-Shelf (COTS) implementations fail to provide this value due to the implementation approach taken. Authored by Grady Brett Beaubouef, who has over fifteen years of packaged software implementation experience, this book will help you define an effective implementation strategy for your packaged software investment. The book focuses on Commercial Off-The-Shelf (COTS) implementations, and helps you to successfully implement packaged software. Using a step-by-step approach, it begins with an assessment of the limitations of current implementation methods for packaged software. It then helps you to analyze your requirements and offers 10 must-know principles gleaned from real-world packaged software implementations. These 10 principles cover how to maximize enhancements and minimize customizations, focus on business results, and negotiate for success, and so on. You will learn how to best leverage these principles as part of your implementation. As you progress through the book, you will learn how to put packaged software into action with forethought, planning, and proper execution. Doing so will lead to reductions in implementation costs, customizations, and development time.
Table of Contents (19 chapters)
Maximize Your Investment: 10 Key Strategies for Effective Packaged Software Implementations
Credits
About the Author
Acknowledgement
About the Reviewers
Preface
Summary of Challenges

Ten principles for implementing a business solution


Following are the ten guiding principles I have developed and utilized in my fifteen years of implementation experience for packaged software:

  1. 1. Focus on business results

  2. 2. Customers — make an investment in your implementation partners

  3. 3. Implementation partners — enable your customers to lead during the implementation

  4. 4. Perform business solution modeling

  5. 5. Determine the correct implementation approach for your unique business solution

  6. 6. Implement to the current business process maturity level

  7. 7. Maximize enhancements and minimize customizations

  8. 8. Negotiate for success

  9. 9. Have a business solution architect role on the implementation team

  10. 10. Accelerate decision making by generating more knowledge and less information

Principle #1 for implementing a business solution

Focus on business results

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.

Principle #2 for implementing a business solution

Customers — make an investment in your implementation partner

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.

Principle #3 for implementing a business solution

Implementation partners — enable your customers to lead the 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.

Principle #4 for implementing a business solution

Perform business solution modeling

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:

  • Centralized

  • Decentralized

  • Country-specific

  • Organization-specific

  • Customer-specific

  • (Even) User-specific

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.

Principle #5 for implementing a business solution

Determine the correct implementation approach for your unique business solution

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?

Battle of camps

In the software development camp, there is a relatively new movement and approach (AGILE) that focuses on iterations and embracing change throughout the software development lifecycle. Proponents of the AGILE movement feel that legacy software development and project management lifecycles are too document-intensive, and result in greater cost and less value for the customer. The Project Management Institute (PMI) is considered the authorative source of project management discipline. PMI proponents say that AGILE leads to inconsistent results (not repeatable) and depends greatly upon highly-experienced developers.

Methodologies are not the issue; it's how they are applied that is the issue.

Example: PMI does not stress that a project manager must have some competent level of technical expertise in the area (business) that he/she is managing. In theory, this is in the realm of possibility; however, in today's competitive environment, this can put a project manager at a clear disadvantage. As an exercise in exploration, let us rationally discuss the challenges with having a non-technical expert project manager lead a project. The following represents the assumptions that we are making for this exercise:

  1. 1. The project manager is ultimately responsible for delivery of the project. Project scope, cost, and time are the primary responsibilities of the project manager.

  2. 2. The project manager is competent in managing projects.

As a project manager responsible for project delivery, and being unfamiliar with the subject matter (technical expert), the opportunity exists for a greater application of project management processes and controls. Until the project manager is comfortable with the approach and the project team, a heavy application of project management techniques will be applied. Recall your first attempt in a new field (e.g., skiing). Were you cautious? Did you take additional steps to ensure success and not failure?

Practically speaking, project managers without the relevant business acumen can control business solution implementation projects, but will have limited opportunities to lead these projects. The market has a way of validating one's conclusions. Specifically, speaking to the ERP implementation market, we are seeing a steady trend in the requirement for project managers to have both software product and industry experience, in order to provide hands-on support and leadership to the project team.

Another example: AGILE, as a software development methodology, is very resource-dependent. A fundamental premise of AGILE is that you have people who are experienced in software development, and experienced at working within teams. AGILE also promotes personal interaction over documents. This can be a challenge when the project team is not co-located, which is becoming more of a reality in this global economy. Would you use the AGILE approach with a team of developers who just graduated from college? The odds are that the answer is no. The point is that there are many factors to consider in selecting the appropriate methodology and determining how to apply the selected discipline.

Soap box — Bashing methodologies

Is there anything wrong with AGILE software development or PMI's project management guiding principles and best practices? No. Both disciples are sound, and have proven track records of success. There are also examples where these methods did not produce the desired results. This does not imply that there are flaws or gaps in either discipline. On the contrary, I have great respect for both groups and their expertise in developing a great source of knowledge that can generate tremendous business value.

Personally, I have a general concern with people who criticize a given discipline without fully understanding the purpose of a specific methodology. Any methodology is based upon a specific environment, which means that you need to have a competent understanding and appreciation of the assumptions, risks, and constraints that a specific methodology inherently has. The project team must conduct an analysis to determine how to apply selected methodologies for a specific project. There is no "cookie-cutter" approach to implementing a business solution.

Customer-specific implementation

Just as an enterprise business solution is specific to a customer, the approach must also be tailored in order to successfully implement the solution. In this book, we will discuss the major implementation approach and provide you (the reader) with insight and variables to consider identifying the "right fit" for your implementation.

In his book on Agile project management, Jim Highsmith makes the following profound statements: "Reliability is results driven. Repeatability is input driven."2 Too often I feel that we, as implementation partners, focus more on repeatability (driving down price) and less on reliability.

Principle #6 for implementing a business solution

Implement to the customer's current business process maturity level

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!

Principle #7 for implementing a business solution

Maximize enhancements and minimize customizations

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.

Principle #8 for implementing a business solution

Negotiate for Success

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

Building custom software solutions are not strategic to our organization.

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.

Principle #9 for implementing a business solution

Have a business solution architect role on the implementation team

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:

Business Model Perspective

Packaged Software Perspective

Solution

Enterprise

High Level Business Process

Systems

Detailed Business Process

Products

Business Activity

Product Feature Set

Business Task

Product Feature(s)

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

  • Project Manager

  • Functional Leads

  • Technical Architects

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.

Observations

During my five-year tenure with PeopleSoft's Services Research and Development organization, I had several opportunities to troubleshoot problem implementations of new enterprise-wide packaged business software. A recurring problem with every troubled implementation was that there was not a dedicated functional resource who could focus specifically on the business process and solution level. The business solution architect is a specific implementation role. This role is responsible for understanding how the COTS software supports the entire business process, and provides guidance and validation of software product configurations to ensure that the software configuration will consistently support business activities and objectives across the underlying business model.

Principle #10 for implementing a business solution

Accelerate decision making by generating more knowledge and less information

Making decisions during an implementation is based upon:

  • The information available

  • Assumption

  • Constraints

  • The experience of the decision-maker(s)

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:

Estimate (Understanding)

Performed Where

Confidence

Order of Magnitude

Scope Initiation

-25% to 75%

Budgeting

Early stages of planning

-10% to 25%

Definitive

End of planning

-5% to 10%

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:

  • Aggressively gather information for the key decisions that you know the customer needs to answer

  • Present the information in terms that the customer understands, and ensure that the customer appreciates the decision at hand

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:

  1. 1. Keeping your options open (i.e., not making decisions) will slow down the implementation project and increase your risk of failure.

  2. 2. Of all the three components of a business solution (people, business processes, and technology), technology is the least adaptable and flexible. People have the greatest capacity for adaptability and flexibility.