Having effective executive sponsorship is a key success factor for any business solution implementation. There are countless books and presentations that have communicated this best practice to the marketplace. Executive sponsorship may guarantee financial support but it does not guarantee organizational acceptance and adoption.
For example, Panorama Consulting conducted a study of 2008 Enterprise resource planning (ERP) implementations from over one thousand organizations across the globe. The study focused on the top ERP challenges. Respondents indicated that lack of employee adoption as the biggest challenge (33%). Surprisingly, not a single respondent identified lack of executive support as the biggest problem.
Trickle down acceptance falls short
A key assumption made on several packaged software implementations is that if the executive management selects Commercial Off The Shelf (COTS) software, then the organization would adopt the executive’s intentions. When executive management selects packaged software, they are making the following statement: A custom software solution is not strategic for the organization.
It is interesting to note that the above statement is not publicly reiterated throughout the life of the implementation project. It’s like a little secret that is implied but hardly repeated. Unfortunately, the key business process owners and other stakeholders do not always respond to “trickle down” acceptance. Their expectation is based on their past software experience, which is usually getting what they want without any questions asked. Packaged software makes for an expensive custom solution. If the project team does not reset existing business software expectations, then it will be extremely difficult to be successful. If the project team makes no software changes and use packaged software as delivered then end user adoption and satisfaction will be harder to develop. If the project team focuses on building a custom solution then the Total Cost of Ownership (TCO) will be significant and will result in less executive satisfaction due to the increased cost. Successful COTS software implementations are those that are able to balance (negotiate) tradeoffs that result in minimizing TCO and maximizing organizational acceptance.
The following section will discuss the key areas that the project team should address as part of their negotiation strategy.
Developing an effective negotiation strategy
An effective negotiation strategy for packaged software implementations is where all parties are aligned in supporting the success of the implementation. It is also importantfor the project team to perform certain activities to promote alignment and adoption. The first step in developing an effective negotiation strategy is to establish realistic expectations to close the gap between custom software and packaged software.
Paradigm shift in business software expectations
One of the key mindsets that the project team have to make with the stakeholders and end users are expectations of business software. Typically, stakeholders and end users see business software as a simple tool that can easily be adapted to support their activities. It is rare for stakeholders and end users to understand the complete ramifications of their requests. There are times when stakeholders and end users do not care to know what efforts are required to make the business software do exactly what they want. Regardless of the underlying drivers, the project team must make the effort to educate and influence stakeholders and end users to develop areas of compromise.
Case Study
I was the functional consulting lead for a packaged software application to replace a customer’s legacy time reporting system. The customer’s process consisted of electronic spreadsheets coupled together with a data load process to a staging table for payroll processing. When I started working with the customer to define their business requirements, it was apparent that there was a difference between executive and business stakeholder expectations. The customer insisted on having the exact functionality that they had in their existing systems. I knew that no matter how good the developers were, we would not be able to cost-effectively build the existing flexibility into the packaged software. It would totally invalidate the justification for going with a packaged software solution in the first place. The customer was used to getting exactly what they wanted from software to the point where software replaced the need for training (i.e., dummy-proofing). I did an initial gap analysis and identified over forty (40) gaps that required changes to the packaged software.
I came to the realization that if I proceeded with a traditional approach to gathering requirements that: (a) I would spend a lot of wasted effort gathering non-value-added business requirements and (b) the fit/gap session would be much longer than anticipated. It was a no-win situation. The best approach was to reset software expectations with the customer up-front. I met with the customer to discuss the reasons for selecting packaged software and the inherent advantages and disadvantages with packaged software. This was not a one-time discussion and required several additional discussions.
In the end, the customer’s expectations adapted, which enabled us to accelerate our fit/gap session. We still identified ten gaps. Of the ten gaps, we negotiated to have only five addressed via a software change and the other five gaps were handled manually due to the frequency of occurrence. Our negotiations resulted in an 87% reduction from the initial estimate and were only made possible by establishing a suitable environment for effective negotiating. If either party has unrealistic expectations then effective negotiations would have been extremely difficult.
Paradigm shift in organizational acceptance
The second paradigm shift that the project team has to make is in how to gain organizational acceptance. This area is addressed in organizational change management. Organizational Change Management is good at defining the tactical steps that you need to perform in preparing the organization for a new business solution. However, a more aggressive approach needs to be taken. The entire project team needs to sell the solution to the organization. I’m talking about a concerted effort—no soft selling here. The project team needs to have real influence with the stakeholders and end users. The project team needs to lead discussions with stakeholders and key end users; negotiating a business solution that balances their needs (not wants) with the strategy of using packaged software. The project team needs to persuade their customers that they have the customer’s best interests at heart and will produce a competent business solution.
Understand when and where to negotiate
Negotiating on business requirements is a certainty that must be planned for by the project team. The majority of projects do not have a proactive strategy in place to negotiate with stakeholders on business requirements that are not satisfied by the delivered packaged software. Many projects take a reactive approach to negotiating business requirements. This approach typically results in confusion, analysis paralysis, and decisions that undermine the objectives of selecting packaged business software. Following are the key points that the project team needs to address in understanding potential areas for negotiation:
- Identify areas within the packaged software where software changes are typically made by customers. With the correct implementation partner, the project team may have the opportunity to leverage their software change library to streamline the modification efforts. With the correct packaged software provider, you may have the opportunity to partner together and share the development effort.
- Identify areas within the packaged software where software changes will have minimal Total Cost of Ownership impact. For example, making a software changes to generate an exception report has less of an impact than building a new application page or process. Determine where the business software provider provides the most support for software changes within their application and lead with these options in the negotiations. For example, reporting is an area that most packaged software providers anticipate their customers modifying, and provide tools and templates for streamlined development and upgrades in this area.
- Identify areas within the packaged software where software changes will have an adverse impact to the Total Cost of Ownership. For example, software modifications to compiled executables can have several downstream impacts to other components within the packaged software. These software changes can not only negatively impact the Total Cost of Ownership but can also result in unstable business software, and invalidate software support and quality agreements. It is also important for the project team to understand the boundaries of the technical constraints inherent with the packaged software.
- Determine what to challenge and what to accept regarding business requirements not supported by the packaged software. In general, the project team should focus on maximizing enhancements and minimizing customizations. In the case where customizations must be addressed for project success, implement the customizations with the least impact to the Total Cost of Ownership.
As the project team engages the key stakeholders and end users, do not lead with the functional areas that the team plans to address via software changes. Allow the stakeholders and end users to justify the reasons for negotiating and building software changes. What I learned from these software negotiations is that every party needs to perceive that they have won something. In theory, one can look at this as an inefficient process; however, it reflects human nature and a certain reality that the project team must address. The project team, should as well deal with these types of negotiations in a practical manner. Too often, I have witnessed project teams get stuck in theoretical absolutes that add no business value and slow down the project.
