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

By Grady Brett Beaubouef
    What do you get with a Packt Subscription?

  • Instant access to this title and 7,500+ eBooks & Videos
  • Constantly updated with 100+ new titles each month
  • Breadth and depth in over 1,000+ technologies
  1. The Silo Approach is Alive and Well

About 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.

Publication date:
December 2009
Publisher
Packt
Pages
232
ISBN
9781849680028

 

Chapter 1. The Silo Approach is Alive and Well

For the past fifteen years, I have been what you call a "hands-on" student of the packaged software industry — specifically, Enterprise Resource Planning (ERP) software. One of the hard-learned lessons of early packaged software implementations is that we should not take a functional silo approach to implementing an integrated business solution. Enterprise solutions support business processes, and business processes typically span multiple functional areas (silos). Having a functional silo perspective typically results in underestimating integration considerations. ERP, or any packaged software, is only as strong as its integration across the functional areas that support a business process. As an industry, I can see that we are maturing to take a more holistic approach to packaged software implementations. However, there is room to grow.

Consider the following: business software providers are evolving their applications to be more business process centric. There has also been a resurgence in the subject of business process re-engineering and business process management. "Focus on your business processes!" is the advice that you will hear from analysts and implementation partners alike. Too bad that this advice focuses on only one component of a business solution.

Why do we need to change?

Based upon a survey of customers who have implemented ERP solutions, the overwhelming message is that customers are not satisfied with the business results. The following surveys provide statistical data on the rate of failure of ERP implementations:

  • Robbins-Gioia Survey

  • Conference Board Survey

Robbins-Gioia Survey

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:

  • 51% viewed their ERP implementation as unsuccessful.

  • 46% of the participants noted that while their organization had an ERP system in place, or was implementing a system, they did not feel their organization understood how to use the system to improve the way they conducted business.

  • 56% of survey respondents noted that their organization had a program management office (PMO) in place, and of these respondents, only 36% felt that their ERP implementation was unsuccessful.

Conference Board Survey

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

Key Findings:

  • 34% were very "satisfied"

  • 58% were "somewhat satisfied"

  • 8 % were unhappy with what they got

  • 40% of the ERP projects failed to achieve their business case within one year of going live

  • The companies that did achieve benefits said that the achievement took on average six months longer than expected

  • Implementation costs were underestimated for the year following implementation by an average of 20%

  • Support costs were underestimated for the year following the ERP implementation by an average of 20%

Nearly 90 % of ERP implementations are late or over budget 1 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.

Business solution defined

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:

  • People

  • Processes (business processes)

  • Technology (software and technical infrastructure)

What is the most important component of a business solution?

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.

What is wrong with existing packaged software implementations?

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.

IT does not matter? Think again!

I would like to take the opportunity to note that I do not prescribe to the "IT Doesn't Matter" crowd. It's like saying "I can travel San Francisco to New York without any mechanical means". This is a true statement but how realistic is it in today's competitive landscape? Conversely, the IT community should continue to evolve their support approach where IT supports a business solution — not only software. Software by itself generates no business value. What software can do is enable efficiencies of people in order to produce business results. There is a healthy and optimal balance between the three components of a business solution that is required to generate maximum business value. Each customer and implementation partner must work together to find this balance. One thing is for certain: as part of your implementation, you must focus on all three components in parallel.

Is technology changing Business?

I do not believe that technology is changing business, but rather that technology is finally catching up with leading business practices. For example, back in the early nineties, I read a book on the e-business revolution. The major premise of the book was that technology was transforming existing business models into an e-business model. The book provided an example where inventory stocks could now be checked in retailer stores and inventory orders could be generated to maintain a desired stock level. The book explained that this is an emerging requirement due to new e-business technology.

I have to humbly disagree with this analysis. The above requirement had always been a desire of business. I remember back in the 1950's when my father would make the rounds as a salesman to his retailer customers to see their inventory levels and manually created orders to maintain the retailer's inventory levels. Many businesses did not perform this process because (a) it was manually-intensive work, and (b) it reduced focus on higher-priority business activities. Technology is now providing a cost-effective vehicle to accomplish this business requirement. Everyone has heard the phrase "build it and they will come". This philosophy may have worked out in the era of "green screens" and emerging client/server technologies, but not in today's world. Technology driving the business is like — forgive the cliché — putting the cart before the horse.

It is important to understand and appreciate what technology can and cannot do for a customer. Often, the true problem lies not with the COTS software itself (granted, there are always software bugs and fixes) but rather the demand for quick fixes and rapid cures to the challenges posed by the underlying business model. If the packaged software did not improve the performance of the underlying business model, then executive management would conclude that the implementation was a failure. This statement leads us to the first principle of implementing a business solution:

Focus on Business Results!

 

Why do we need to change?


Based upon a survey of customers who have implemented ERP solutions, the overwhelming message is that customers are not satisfied with the business results. The following surveys provide statistical data on the rate of failure of ERP implementations:

  • Robbins-Gioia Survey

  • Conference Board Survey

Robbins-Gioia Survey

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:

  • 51% viewed their ERP implementation as unsuccessful.

  • 46% of the participants noted that while their organization had an ERP system in place, or was implementing a system, they did not feel their organization understood how to use the system to improve the way they conducted business.

  • 56% of survey respondents noted that their organization had a program management office (PMO) in place, and of these respondents, only 36% felt that their ERP implementation was unsuccessful.

Conference Board Survey

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

Key Findings:

  • 34% were very "satisfied"

  • 58% were "somewhat satisfied"

  • 8 % were unhappy with what they got

  • 40% of the ERP projects failed to achieve their business case within one year of going live

  • The companies that did achieve benefits said that the achievement took on average six months longer than expected

  • Implementation costs were underestimated for the year following implementation by an average of 20%

  • Support costs were underestimated for the year following the ERP implementation by an average of 20%

Nearly 90 % of ERP implementations are late or over budget 1 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.

Business solution defined

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:

  • People

  • Processes (business processes)

  • Technology (software and technical infrastructure)

What is the most important component of a business solution?

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.

What is wrong with existing packaged software implementations?

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.

IT does not matter? Think again!

I would like to take the opportunity to note that I do not prescribe to the "IT Doesn't Matter" crowd. It's like saying "I can travel San Francisco to New York without any mechanical means". This is a true statement but how realistic is it in today's competitive landscape? Conversely, the IT community should continue to evolve their support approach where IT supports a business solution — not only software. Software by itself generates no business value. What software can do is enable efficiencies of people in order to produce business results. There is a healthy and optimal balance between the three components of a business solution that is required to generate maximum business value. Each customer and implementation partner must work together to find this balance. One thing is for certain: as part of your implementation, you must focus on all three components in parallel.

Is technology changing Business?

I do not believe that technology is changing business, but rather that technology is finally catching up with leading business practices. For example, back in the early nineties, I read a book on the e-business revolution. The major premise of the book was that technology was transforming existing business models into an e-business model. The book provided an example where inventory stocks could now be checked in retailer stores and inventory orders could be generated to maintain a desired stock level. The book explained that this is an emerging requirement due to new e-business technology.

I have to humbly disagree with this analysis. The above requirement had always been a desire of business. I remember back in the 1950's when my father would make the rounds as a salesman to his retailer customers to see their inventory levels and manually created orders to maintain the retailer's inventory levels. Many businesses did not perform this process because (a) it was manually-intensive work, and (b) it reduced focus on higher-priority business activities. Technology is now providing a cost-effective vehicle to accomplish this business requirement. Everyone has heard the phrase "build it and they will come". This philosophy may have worked out in the era of "green screens" and emerging client/server technologies, but not in today's world. Technology driving the business is like — forgive the cliché — putting the cart before the horse.

It is important to understand and appreciate what technology can and cannot do for a customer. Often, the true problem lies not with the COTS software itself (granted, there are always software bugs and fixes) but rather the demand for quick fixes and rapid cures to the challenges posed by the underlying business model. If the packaged software did not improve the performance of the underlying business model, then executive management would conclude that the implementation was a failure. This statement leads us to the first principle of implementing a business solution:

Focus on Business Results!

 

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.

 

Summary


"Divide and conquer" was a strategy that was ingrained in me during my studies in Computer Science. It is a strategy that I continue to use today to tackle challenges like implementing a business solution. However, what I have learned is that you cannot simply divide a business solution implementation into neat, discrete individual silos, execute in these individual silos, and gather all of the individual results in order to create a successful business solution.

Every business solution implementation is a unique instance that requires research into possible adoption methodologies, as well as how to apply these disciplines during the implementation. The investment strategy that you should invoke in a business solution implementation should be prioritized based upon which areas have the greatest impact on implementation's success. Of the three components of a business solution (people, business processes, and technology), people have the greatest capacity to act, grow, react, learn, and evolve. Investment in your customers, your IT partner, and your Implementation Partners should be the cornerstone of your business solution implementation strategy. Technology and methodologies play a supportive role in successful business solution implementations, yet it is people that have the greatest impact on your success.

A successful business solution generates the desired business results. In the next chapter, we will discuss how to ensure that packaged software implementations focus on value-added business results.

 

References


  1. 1. Martin, M.H., An ERP Strategy, Fortune Magazine, February 1998, Page 95-97.

  2. 2. Highsmith, Jim., Agile Project Management, Addison-Wesley, Page 52.

  3. 3. Project Management Institute., A Guide to the Project Management Body of Knowledge, 2000 Edition, Page 201.

About the Author

  • Grady Brett Beaubouef

    Grady Brett Beaubouef is a project manager and solution architect for enterprise packaged software solutions. Brett has over fifteen years of packaged software implementation experience across several implementation roles include Project Manager, Solution Architect, Functional Lead, Technical Lead, Business Analyst, Software Quality Analyst, and Trainer. Brett also worked in a thought leadership role for the #1 business software maker focusing on implementation methodologies, project assessments, and accelerated implementation services. Brett has a B.S. in Computer Science from Louisiana State University (LSU) and is both a Project Manager Professional (2004) and Certified Information Systems Auditor (1995). He has also produced several presentations and white papers on industry solution best practices, implementation best practices, and accelerating packaged software implementations.

    Browse publications by this author
Maximize Your Investment: 10 Key Strategies for Effective Packaged Software Implementations
Unlock this book and the full library FREE for 7 days
Start now