The challenge of preparing enterprise resource planning (ERP) implementation proposals solicited through request for proposals (RFPs) in Latin America (LA)

Abstract

Information Technology (IT) acquisition and purchasing decisions are often conducted in a context of not-always met expectations, political agendas, vendor promises, and excitement with brand names. Decisions are frequently driven by executive mandates, or choices are made by colleagues/competitors within the industry or through insufficient analysis based on lengthy and rudimentary requirement spreadsheets. This may result in the collection of a gigantic amount of data, and, consequently, the aggregation/consolidation of such data may be overwhelming for the company evaluating new enterprise resource planning (ERP) software. Some challenging situations faced by vendors when responding to request for proposals (RFPs) for the acquisition and implementation of ERP software in Latin America will be shared in this paper, as well as risk mitigation strategies and recommendations on how to make the ERP selection process more successful and cost effective.

This paper is intended to be a learning experience with regard to the following:

  • Understanding the current scenario of preparing and responding to RFPs in Latin America for the selection and future implementation of ERP software.
  • Awareness of some typical situations and challenges posed by RFPs according to the ways they are prepared today.
  • Obtaining recommendations on how to improve the ERP selection process.

Introduction

Information Technology (IT) acquisition and purchasing decisions are often conducted in a context of not-always met expectations, political agendas, vendor promises, and excitement with brand names. Decisions are frequently driven by executive mandates, or choices made by colleagues/competitors within the industry or through insufficient analysis based on lengthy and rudimentary requirement spreadsheets. This is likely to be a recipe for failure. It may result in the collection of a gigantic amount of data, and consequently the aggregation/consolidation of such data may be overwhelming and daunting for the company evaluating new ERP software. The above-described scenario has particular nuances in Latin America. Quite often, there are no “generally-followed” standards for the creation of RFPs in the ERP selection arena; RFPs may be prepared through methods ranging from single invitation letters asking for the number of employees of each software vendor to lists with thousands of functional and technical requirements, which frequently match the functionality of the current legacy system that will be decommissioned.

Some challenging situations faced by vendors when responding to RFPs for the acquisition and implementation of ERP software will be shared in this paper. The impact these have on some of the knowledge areas of A Guide to the Project Management Body of Knowledge (PMBOK® Guide)---Third edition (Project Management Institute [PMI], 2004) will be discussed, including scope, risk, quality, cost, and human resources. A few risk mitigation alternatives, from the vendor's perspective, will also be discussed, to address areas such as

  • Penalties and Service Level Agreements (SLAs)
  • Commitment to assign named consultants to the implementation project
  • Vague or conflicting functional requirements
  • Customizations
  • Integrations with future and/or unknown systems
  • No scope control process
  • Warranties

This paper will conclude with a few recommendations on how to make the ERP selection process more successful and cost effective. Although there may be over 20 qualified vendors, the selection process should be based on a shorter list, with more emphasis on post-implementation stages as well as requirements gathering, which is an activity often neglected in the overall selection process and can result in disastrous projects.

Key Features of “Classic” RFPs

The “classic” RFPs usually have either one of two key characteristics: they tend to be overly extensive (or, “large”) or they tend to be dictatorial.

The “Gigantic” RFP

Very large RFPs were formerly seen as an excellent signal---by vendors, especially in the ERP arena---of a possible opportunity to reduce uncertainty and as a great way for vendors to demonstrate their ability to propose a complete and compelling solution footprint to prospective customers. However, there is nothing like a disastrous implementation project to make us rethink the old myths. The possibility of failed projects is a growing concern, as we have identified that the very long lists of functional and technical requirements contained in such RFPs have at least one of the two following biased sources:

  1. Functionality of the current legacy systems that are to be replaced
  2. Reused RFPs prepared by consultancies to customers belonging to other industries

Attempting to Replicate a Legacy System

Although trying to change too quickly is one way to jeopardize your enterprise application implementation process, trying to avoid change can be damaging, as well.

The following example is drawn from my own experience. A customer acquiring an ERP product and project repeatedly said “we want an implementation with a minimum of customizations, leveraging the business practices embedded in the selected ERP product.” (This was a typical statement from top management and those who chose the ERP). However, we later noticed that there was a lack of consistency between that pitch and the philosophy from the team who wrote the RFP functional requirements and was assigned to the implementation project by the customer, who stuck to the RFP in a brave manner.

Some people just do not like change, and the idea of leaving behind the way they have done things in the past. These people, when they are part of an implementation team, come into the project with their own paradigms and their own ideas of how things should work, which are often based on the old system. Frequently, it does make sense to “go live” first on just enough functionality to replace the legacy system, but resistance to change of this nature may threaten any implementation.

A desire to replicate an existing environment is normal and not surprising at all. Team members may even have a specific idea of what screens and reports they should see, and what buttons they should click. People who are reluctant to move away from their legacy system focus on the functions of the software rather than on the business requirements behind those functions, and they often request numerous modifications to the new environment, which can increase implementation costs without real business benefit.

An applications vendor or consultant should understand that anything the customer does in its current process is likely done for a good reason, and it is the consultant's or vendor's job to learn what that reason is and then to find the best way to satisfy that underlying need in the new software. The goal should not be to replicate the way things are done in the legacy system. Indeed, in most of the cases, an implementation may bring a slightly different process flow, different screens and reports. People assigned to a company's ERP selection and implementation teams have to be able to “think outside the box” and to realize that their business requirements are being met even if the screens and buttons are not exactly the same. The likelihood of success depends on the degree to which the right people are assigned to the ERP selection and implementation teams, who are able to look beyond the superficial elements of the legacy system and to envision how the new application will be made to meet their underlying business requirements.

Implementation team members must be comfortable opting for a slightly different approach or a slightly different process in order to meet the strategic goals that a new enterprise application is meant to achieve. In some cases, team members should even be empowered and unafraid to suggest organizational changes outside the application that will better accommodate a new process flow and make for a smoother implementation. Perhaps certain departments should be merged, or people who had worked on opposite sides of a building should be moved closer together to facilitate better the new way in which things are to be done. When there is too great an attachment to the past, it is hard to realize a more productive and streamlined future.

Using Reused RFPs

One popular belief is that “no one can present himself directly to another of our friends. There must be a third person to do it.” If a software product has been selected to be on the short-list thanks to certain direct connections to partial third parties, a company may have met with a world of trouble. This happens more often than one might think.

It is unlikely that consultancies are “product-independent” and will guide you in an unbiased manner towards the selection of ERP software. It is a costly process to train consultants in all available ERP packages, and so it is to be expected that those consultancies will have broader competencies with package A or B, and therefore will guide you to select the option for which they have the greatest resources.

The “Super Classico Law”

Using a combination of (I) and (II) above will not result into a cost-effective approach to selecting ERP software. The “Super Classico Law” explains this.

For those who are soccer lovers, Super Classico is the term used to describe the match between the Spanish teams Real Madrid and Barcelona; two South American examples of Super Classicos might be Gremio versus Internacional---the “Grenal” in the Brazilian State Rio Grande do Sul---or Boca Juniors versus River Plate in Argentina. At the very end, it is highly possible that one of the contenders of each Super Classico will be the champion, no matter what happens with other teams during the competition.

It is easy to get caught up in the “wish list” features of a product. The massive collection of data performed during the evaluation of ERP software can be a burden for any organization, and the aggregation/consolidation of such data can be even more challenging (and perhaps frightening). However, the ERP selection has become more and more a type of “Super Classico”---and therefore, the comparison of answers to thousands of functional requirements of two final contenders is far from being a cost-effective process.

No one should underestimate the strategic importance of an ERP implementation process. Although this is a very broad topic, failure to understand the various ways in which an enterprise application implementation is strategically critical to a business can cause a number of problems. One of the most common results of this cognitive failure is assigning the wrong type of professionals to an implementation team, which in turn causes problems to surface. Companies usually think of their information systems strictly as an IT issue, which is handled by the technical IT personnel. On the other side, IT teams are protective of their territory and assume that they completely understand the business needs of the company. This type of thinking often leads to a solution that is technology-driven, not business-driven, and is ultimately detrimental to the business.

The Dictatorial RFP

A typical dictatorial RFP follows the principle “appointments must absolutely be respected.” This means that a prospective buyer makes sure all vendors on the short-list understand that they will be penalized for not respecting document submission deadlines, for anything from RFP responses to reference checks.

Selecting an ERP solution is one of the most critical decisions a business can make. However, overanalyzing and overthinking will cause information to become outdated and the selection process to lose momentum. In order to avoid facing this problem, before beginning the selection process, the ERP evaluation team must develop a specific and realistic time-line of objectives, goals, and deliverables. Without outlining a clear path on how or when to move forward, the ERP selection process may take longer than it should and possibly expose the business to unnecessary risk.

However, situations still frequently occur in which the strategic importance of the RFP implementation is neglected and the above-mentioned aspects of efficiently carrying out the ERP selection process are not taken into consideration. The following examples, demonstrating the mindset of some ERP buyers, are excerpted from real-life RFPs and represent typical challenging (and virtually impossible) conditions that may confront vendors.

“Your proposal response must be received by the date defined in section X.Y “Schedule of Activities” at the address <address provided> before 5:00 PM Eastern Standard time. Proposals submitted after this due date may be rejected by <customer>.” Normally, the first due date stated in the RFP is too close and, in a significant number of cases, the prospective buyer is willing to change the due date without changing the RFP (all bidders are notified through e-mail). It is normally the first unnecessary stressful situation faced by vendors responding to an RFP. (Unfortunately, many organizations still make it a goal to squeeze vendors beyond the limits.)

“The delivery of the proposal implies automatically that all of the scope, the technical and commercial conditions, and all of the Vendor's responsibilities, defined in this RFP, together with its chapters and appendixes, are fully accepted and committed to by the Vendor, with no exceptions and regardless of anything presented in the Vendor's proposal and/or any other previous, present, or future Vendor's documentation.” It is very rare that all of the conditions stated in an RFP will be accepted by the vendors. Here the Scope Management, Cost Management, and Risk Management knowledge areas of the PMBOK® Guide must be considered: the RFP conditions may imply unlimited risk/exposure/liability to the vendor (PMI, 2004). Exposure delimiters and/or a section in the proposal called “RFP noncompliance items” may be included to mitigate vendors' risks.

“The Vendor shall guarantee the capacity of the recommended equipment according to the needs presented in Appendix 24. If the capacity stated by the Vendor does not reach in the operation the offered values of performance and capacity, the Vendor shall install all of the necessary extra-capacity in infrastructure without cost for <customer>, including services, support, and all extra cost referred or esteemed to it.” The responsibilities for the capacity sizing are a typical gray area. Many variables are outside the control of the ERP provider (e.g., hardware, communications), and it is unlikely this condition will be accepted “as-is.” For the same reason, it is unlikely that commitments to predefined response times of online transactions or window time of batch processes will be accepted.

“<Customer> expects the Vendor's project manager to prepare status reports indicating time spent by consultants in the activities. The project will be contracted on a fixed fee basis, and the vendor will be required to inform the number of consultants assigned, the hourly rates, and the total amount of hours that determine the overall price.” This is an inconsistent request often found in Latin American ERP RFPs, and in this situation, the Cost Management and Time Management knowledge areas of the PMBOK® Guide should be considered.(PMI, 2004) As the vendor accepts the risk inherent to a fixed fee contract, he or she does not have to disclose the hours spent with the prospective customer. In addition, these data are completely irrelevant to the ERP selection process.

A Service Level Agreement table is shown in Exhibit 1.

Service Level Agreement (SLA) table

Exhibit 1--Service Level Agreement (SLA) table

Although the first level of the SLA as shown in Exhibit 1 appears the most challenging, the remaining levels are in fact quite tough, since the penalties at these levels are unlimited and therefore are unlikely to be accepted by the vendors, as there are many variables beyond their control. This nuance is related to the Cost Management, Quality Management, and Risk Management knowledge areas of the PMBOK® Guide (PMI, 2004).

“Please nominate all consultants who will be working in the implementation project.” The typical cycle of an ERP selection project lasts 6 to 12 months (and, in fact, I know of one Latin American ERP selection process that lasted five years). It is virtually undoable, for any consultancy, to have resources “reserved” for so long, since consultant utilization is a key performance indicator of any consultancy and because it is likely that resources “promised” in an RFP response will need to be assigned to other engagements. In order to prevent inappropriate expectations, and to be more transparent, the consultancy should not commit to assigning nominated resources to a project that may not even be sold. This situation is related to the Human Resource Management knowledge area of the PMBOK® Guide (PMI, 2004).

“The ERP provider is expected to certificate the deliverables created by the system integrator in charge of the implementation project.” This is a complicated---not to mention vague---request. The ERP providers are not certification bodies, and such a request may create a liability to the ERP provider related to the implementation carried on by another consultancy. This feature is related to the Quality Management and Risk Management knowledge areas of the PMBOK® Guide (PMI, 2004).

“The ERP provider is expected to assure/ensure/guarantee the perfect functioning of the system.” Words like “assure,” “ensure,” “guarantee,” or “technology transfer” are known as “deadly words” because they may imply unlimited liability to the ERP provider in order to fulfill customer expectations.

Recommendations

The following are some “take-home ideas” that you can use regardless of whether you are considering acquiring an ERP or if you are in the ERP industry.

Recommendations for Potential ERP Buyers

1.  Define a course to gather the information and requirements. This should be top-down driven and bottom-up executed. Companies should know what their core competency is and should define and articulate a solid long-term business strategy in a series of executive workshops. They should not get caught up in the “wish list” features of a product (a significant number of software projects are unsuccessful in objectively defining requirements); in order to gather the essential functionality requirements, companies must assign key people to document detailed scenarios of their critical business processes that the vendors' systems must be able to handle. In many software selection processes, not enough emphasis is given to the importance of this phase, resulting in many failures and even resulting in disaster for companies during and after implementation.

2.  Review output with first-line management. This may or may not be an eye-opener to the individuals who actually have to “make it happen.”

3.  Check references. A company must ask the vendors to provide them with references that can be visited, in the same marketplace, with a reasonably similar number of employees and users, are located in close proximity, with similar functional and technical requirements, and have been using the specific ERP software in question for at least one year.

4.  Put together an effective evaluation team. ERP selection is not an IT decision; it is a business decision. As a result, in order to identify the right solution for the business, a team must be formed that represents all functions of the business. For an evaluation team to be successful, one manager must be chosen to be accountable and responsible for the success of the team, with the authority to make decisions and be a link to top management.

5.  Compare the contenders of the “Super Classico.” People assigned to a company's ERP selection team need to be able to “think outside the box” and realize that their business requirements are being met even if the screens and buttons are not exactly the same. The likelihood of success depends on the degree to which the right people are assigned to the ERP selection team, who should be able to look beyond the superficial elements of the legacy system and to envision how the new application will meet their underlying business requirements.

6.  Select one solution and negotiate. Before beginning the negotiation process, companies need to define the desired goals of the negotiation. Unfortunately, many of them skip this step and their only goal is to squeeze the lowest absolute price from the vendor. This approach may save up-front costs, but in the long-term it will certainly cost more. Relationships work better when both parties have an interest in seeing the other one succeed (win-win). In the negotiation stage, instead of focusing on paying the lowest amount, companies should be looking forward to getting a fair deal, so the vendor would have the necessary resources to provide higher quality service over the life of the project.

Recommendations for Vendors in the ERP Industry

1.  Consider penalties and Service Level Agreements (SLAs). Although the vendors do not happily accept them, penalties and SLAs may be considered in contracts and RFP responses whenever they are known and capped. The profit and loss (P&L) analysis of the project made by the vendor should take into consideration the likelihood that such penalties will materialize.

2.  Do not commit to assign named consultants to the implementation project. Resumes of consultants fulfilling the skill sets required by the implementation may be included, but with a disclaimer that states that the assignment of those consultants is not guaranteed.

3.  Avoid vague or conflicting functional requirements. Vague or conflicting functional requirements are why ERP vendors are reluctant to respond to the functional requirements matrixes of RFPs---for instance, the ERP software may meet two requirements separately (make-to-order or make-to-stock manufacturing), but meeting them simultaneously could be a nightmare (complex customization). It is better and clearer to have scope statements based on core ERP functionality plus customizations than the itemized nature of RFP requirements.

4.  Consider your approach to customizations. Customizations are a typical gray area of ERP implementation projects. Whenever possible, a phased approach bid should be followed, with one phase/contract ending with the detailed functional specifications of the customizations and another phase/contract covering the remainder of the project. Another alternative is delimiting the customizations effort to a predefined bucket of labor days, to be managed through a scope control process. The key here is limiting customizations to the business processes that are differentiators of a company's business, and not replicating the functions of the current legacy systems.

5.  Be prepared for integrations with future and/or unknown systems. Because of their highly unpredictable nature, unknown interfaces are nightmares for those who manage risk. Either they are better understood during the requirements definition stage or their efforts are delimited to a predefined bucket of labor days, to be managed through a scope control process.

6.  Make certain a scope control process is in place. Fortunately, it is not common for there to be no scope control process---but it was seen once in a Latin American RFP. The argument stated by the buyer was “managing scope is a difficult and stressful process, so let's reserve 10% of the project budget to change requests and not talk about this in the future.” Although it is true that managing scope is difficult, scope changes are more frequent in ERP implementations than in other types of projects and industries and must be faced (after all, project managers are paid to manage scope). The contract templates of ERP vendors contain standard clauses for change control and should be respected as a healthy project management practice.

7.  Consider need for Warranties. Some confusion exists among warranty, technical support, and additional managed services. The contract templates of ERP vendors contain standard clauses for warranty that follow the IT industry standards; technical support is related to software updates and assistance in the resolution of technical requests, usually apart from the implementation contract; and managed services can be contracted additionally to the implementation services, intended to provide companies with post-production assistance.

References

Project Management Institute. (2004). A Guide to the Project Management Body of Knowledge (PMBOK® Guide- (3rd ed.). Newtown Square, PA: Project Management Institute, Inc.

Technology Evaluation Centers (TEC). Enterprise software selection. Four ways to botch your ERP implementation; Five common hurdles during the ERP implementation. Retrieved from http://www.technologyevaluation.com/

Oracle Corporation – ERP Requests for Proposals (RFPs) and Consulting Proposals

This material has been reproduced with the permission of the copyright owner. Unauthorized reproduction of this material is strictly prohibited. For permission to reproduce this material, please contact PMI or any listed author.

© 2008, Antônio Amaral Júnior
Originally published as a part of 2008 PMI Global Congress Proceedings – Sao Paulo, Brazil

Advertisement

Advertisement

Related Content

  • PM Network

    Rookie Revelations member content locked

    PM Network asks the project management community to share their mistakes made at the beginning of their careers.

  • PM Network

    Interior Motives member content locked

    By Wenger, Fred Project managers are accustomed to looking outside their projects for risks—at competitors, clients, suppliers, the economy, even the weather. But experience has taught me that all projects face a…

  • PM Network

    New Digs member content locked

    By Waity, C. J. Ore deposits are hardly the only factor project leaders use to determine future mining sites in Latin America. Everything from geopolitical turmoil to local labor markets can impact a mining…

  • PM Network

    Past Is Prologue member content locked

    By Hendershot, Steve Organizations can't escape the past when they pump money into tech upgrades. Before they start rolling out cool new tech, project teams need to identify and mitigate the risk of putting fancy new…

  • PM Network

    Bank Breach member content locked

    Dankse Bank A/S came under scrutiny for failing to prevent suspected money laundering at its Estonian branch, and a shelved IT project may be to blame.

Advertisement

Publishing or acceptance of an advertisement is neither a guarantee nor endorsement of the advertiser's product or service. View advertising policy.