Your message has been sent.
This article has been saved to your account.
Go to my account
This article has been emailed to your Kindle.
Send this article
This article by Grady Brett Beaubouef outlines the negotiation strategy required for implementing the Commercial Off The Shelf (COTS) software that will maximize the ownership experience.
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.
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.
eBook Price: $23.99
Book Price: $39.99
Utilize your packaged software provider
A true partner is someone who is interested in other's success. Therefore, it is reasonable to expect that the packaged software provider is interested in the success of the customer's implementation and should be making investments to ensure implementation success. For example: the customer is making an investment in the success of the packaged software provider by paying for license and maintenance fees. However, it is important that the customer leverage their packaged software partners effectively. A deep software discount does not improve the customer's chances for implementation success. What is required is an analysis of the short-term and long-term opportunities for which the packaged software provider can partner with the customer, in order to ensure a successful implementation.
Short-term opportunities are those activities (investments) that your packaged software can provide to assist the customer during the initial implementation.
Leveraging Packaged Software Partners
Software configuration best practices across customer base
Collaborate with similar customers
Access to product strategy and development
Quick-start Implementation guides & tools
Strategy whitepapers on industry best practices and best practice configurations
Co-development of key software enhancements
Beta customer program
Following is a brief overview of the key short-term investments that the packaged software partner can make in order to increase business implementation success:
- Software configuration best practices – doing things from scratch costs more than starting with a predefined configuration model. One strategic advantage of a packaged software provider is their customer base. Within the customer base is a wealth of knowledge and experience regarding best practices in utilizing the provider's COTS software. The packaged software provider should glean these configuration best practices from their existing customer base and develop guidance to aid new customers. Providing this configuration guidance will enable customers to accelerate their implementations and generate Return on Investment (ROI) faster.
- Collaborate with similar customers – having the ability to collaborate with other customers who have already implemented the packaged software is another resource where new customers can identify possible challenges early in their implementations, and plan for these appropriately.
- Quick-start implementation guides and tools – is not a call to replace implementation partners. However, it provides a starting point which will enable the customer to (a) implement faster and (b) be better prepared in order to fully leverage their implementation partner when they are engaged.
- Co-development of key software enhancement – is not about getting free software development. It is an approach that provides greater assurance that the customer's software enhancements will have a longer lifecycle. It promotes better alignment with the future direction of the packaged software product.
- Beta-customer program – is a great opportunity to accelerate rapid delivery of new functionality in a shared-risk environment.
Following is an overview of the key long-term investments that your packaged software provider can make to increase the chance of continued business implementation success:
- Opportunity to include enhancements into core product – is a key value proposition for going with COTS software. However, it will require the customer to develop a compelling sales pitch to the packaged software provider. If the customer can show a broad audience for the software enhancement, then the packaged software provider will likely be more interested. Remember that to be a partner means that the customer is interested in the success of their partners. Selling more software and retaining existing software customers is a key success factor for the packaged software provider.
- Access to product strategy and development – is the opportunity that the customer needs in order to develop and foster the partnership. Being aligned with the COTS product strategy organization provides the customer with insight into the opportunities for co-development and influence over future software product direction.
- Strategy whitepapers on industry best practices and best practice configurations – provide the thought leadership needed in this hyper-demanding world. Packaged software providers cannot develop software to support a successful business solution if they do not understand the business. When the customer selected a packaged software provider, they were selecting an organization that had a deep appreciation of the underlying business model and leading best practices. It is this knowledge that enables packaged software providers to develop best-of-breed business software.
An effective negotiation strategy for packaged software requires the project team to ensure that the packaged software provider is an active participant during the implementation—not just during the sales/procurement cycle.
A reality that we all must accept is that it is better to negotiate from a position of power. In the next section, we will review key tactics the project team can undertake in order to ensure successful negotiations.
Ensuring Successful Negotiations
Please note that the following recommendations focus on building a cooperative environment for successful negotiations. It will take more than an executive mandate to create this cooperative environment between the project team, business owners, and end-users.
eBook Price: $23.99
Book Price: $39.99
One of the known disadvantages with a traditional big bang deployment approach is that business value generation (i.e., software in production) is slow. People naturally like to be identified with successful implementation projects and stay away from projects that are not going anywhere. When a project gains momentum, then it is harder to derail the effort.
The project team does not need to build momentum and excitement after the implementation project but during the project! The best method to accomplish this is to generate quick wins early in the project. The result has be something tangible and that generates some level of value to the customer. It could be building a proof of concept that demonstrates that the packaged software will support the customer's business. It could be an implementation of the business software for a strategic department or region. It could be an implementation of the basic functionality of the packaged software. Whatever the project team determines as the quick win, it must meet the following objectives:
- The result demonstrates that the packaged business software can competently support the business.
- The result demonstrates that the project team can deliver a business solution for the organization.
- The result is perceived as valuable by key stakeholders.
- The project team can build upon the initial result.
- The result generates excitement and organizational adoption.
Point #1: Customers gain confidence with packaged software based on how the software performs during a sales demonstration. That confidence grows exponentially when customers witness how the packaged software performs with their own data in their own environment. With that growth in confidence comes growth in support and trust.
Point #2: The chances are that this implementation is the first time that the project team (Business, IT, Implementation Partner) has come together to implement packaged software. Just as you need to build confidence outside the project team, you also need to build confidence inside the project team. No challenge is too big for confident and committed people.
Point #3: The project team has to deliver a result that is deemed valuable by the key stakeholders. The odds are that a completed requirements specification document is not perceived as a huge value generator to a business owner. Key stakeholders see working software as valuable. But herein lies the trap. In general, packaged software is logically built and designed to integrate with other software. There are technical dependencies that dictate the sequence in which the packaged software is configured and implemented. Certain packaged software features may depend on other features being implemented as well. In situations where these dependencies are not well documented, the project team will naturally gravitate towards a big bang approach to reduce implementation risk. In order to be able to create these quick wins, the implementation partner must understand the documented and undocumented technical dependencies in order to carve out a feature set that can be implemented quickly.
Challenge to implementation partners. Carving out a subset of software features can be a challenge given the dependencies inherent in packaged software. However, by providing guidance on packaged software feature scope, you enable the customer to take a more iterative, risk-adverse approach with their implementation. You also help the customers to realize the value from their software investment sooner rather than later. For customers, if the implementation partners cannot provide you with this guidance, then this would raise a question regarding how well the implementation partner knows the COTS software.
Point #4: The project team agrees upon a result, but this result has to be one that can be expanded upon. The result must empower the project team to make decisions faster and be better focused on the end solution.
Point #5: The result has to be something that is visible and has a measurable impact. Implementing a set of back-office (i.e., administrative, not customer facing) features may be necessary but by itself will not have a huge impact. A customer of mine said it well, "We need to balance 'Give them what they want' with 'Give them what they need'" to generate real adoption and excitement.
Building project momentum through early successes is a key tactic for developing trust between the negotiating parties. When the decision to select packaged software is communicated to the customer's organization, then stakeholders' current perceptions of packaged software will initially drive expectations. What is required is a marketing effort to align perceptions to focus on the inherent advantages of packaged software.
Marketing your solution
Marketing is all about managing and developing perceptions. The perceptions that your stakeholders and end users have regarding the proposed business solution is the reality that the project team has to manage. The project team has to make the effort to ensure that their business solution is seen and positioned in the best possible light. Historically, this has been addressed through a project communication plan, yet communications plans typically focus on building perceptions and not changing perceptions.
Knowledge is power, and power is personal. Implementing packaged software will result in a shift in knowledge and power. This change can be perceived as a personal threat. Given this perceived negative impact, it is important that the project team balance this impact with the opportunities and positive impact associated with a new business solution. Historically, project communication plans have only dealt with the negative impact of a business solution implementation. The project team needs to ensure that a balanced message that fosters adoption and excitement is communicated!
Effective marketing of your business solution to project stakeholders will include the following areas:
- Highlight your business solution's advantages. When change is communicated, people can easily identify the negative impacts to them personally. Make sure that there is a balanced message between the impacts and benefits of a new business solution.
- Establish a project image/logo. A picture is worth a thousand words. While I concede that a project image/logo is not the best use of effort for a small midsize company—it is something to consider for larger companies that are matrixed and have a sensitive political landscape. Image counts when it comes to advertising and promoting your business solution.
- Don't try to be everything to everyone. No business solution will appeal to everyone. Adoption will never be 100%. Focus on the key stakeholders and the user groups that will have the greatest impact on your business solution's success.
- Monitor your marketing/advertising. Is the project team effective in setting expectations for the project? How is the project being perceived by the organization? Are you building trust or confusion? Most implementations spend more effort on communicating and less effort on listening to see if adoption is taking root.
An effective marking strategy is based upon the realization that the project team will have to negotiate with their stakeholders to foster effective adoption and support. Just as your packaged software partner had to sell their solution to the customer, now the project team needs to position and sell their solution to the internal organization. Nothing encourages acceptance more than success.
Packaged software functionality will never exactly meet the customer's existing software expectations. Packaged software is designed to meet a broad set of common business requirements for a particular market or industry. 2 While tradeoffs are common in any "software" engineering endeavor, tradeoffs in this case are driven by the desire to leverage components from the marketplace. This is a change in philosophy that not only the project team must make, but also stakeholders and end users, if real adoption and acceptance is to be obtained.
Successful packaged software implementations are those implementations that are able to balance tradeoffs, resulting in minimizing the Total Cost of Ownership and maximizing organizational acceptance. The first step in finding this balance is to understand when to negotiate on business requirements. The second step is to lay the groundwork for effective negotiations. This effort includes sending a balanced message (impacts, opportunities) along with setting appropriate expectations (achievable goals) for the new business solution. Throughout this effort, the stakeholders and end users must view the project team as trusted advisors. Trust is something that is earned and there is no better way to earn trust than by focusing on quick wins. Quick wins build momentum, organizational support, acceptance, and confidence. Confidence will enable the project team to lead the organization in the implementation of a business solution.
About the Author :
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.