Top Navigation

Part 1 – “We Said, They Said“

Introduction

There is always a sense of excitement when you start a new business relationship. Both the customer and software vendor have embarked on something new and have shared in an altogether satisfying experience during the pre-selection and then selection/award phases. The customer is going to get a new system or application that will make their organization better. The software vendor has just received a new revenue source, growing its market share. In our management consulting practice, this is what we call the Barney phase of a client / software vendor relationship, the “I love you, you love me” phase. But, this phase does not last long and often ends abruptly when configuration or implementation starts. During implementation is where many relationships falter and sometimes dissolve in acrimonious failure. There is more than enough evidence to suggest failure is more common than not:

• Gartner: 75% of all ERP projects fail – But why?
• Study: 68 percent of IT projects fail 
• 21 Shocking Project Management Statistics That Cost Business Owners Millions Each Year
• Why Your IT Project May Be Riskier Than You Think 
• Why IT projects still fail 

System replacements are hard, made even harder if you are trying to replace systems while still using the old ones – changing the wheels on a moving bus. In some cases, it can be more like changing the jet engines of an airplane on the runway as its moving to depart, but thousands of companies do it every year. Lots of work has been done to identify the root cause of project failures. We have said a few things on this topic as well. In this paper, however, we want to examine the different viewpoints of each of the involved parties (customer and software vendor), having consulted on both sides of this, and determine if there are lessons to be learned and recommendations to be made in understanding each perspective. Let us know if these sound familiar.

Example 1. “It can do anything you want but what do you actually want to implement?”

Customer: “When we spoke to Bob, the enterprise sales rep, he told us the application could do that and so much more. Why are you telling us now it can’t?”

In many software organizations, sales can be disconnected from professional services or the implementation team. While an account representative or manager can provide continuity from phase to phase, information in the transitions can be lost. It is the responsibility of both the customer and software vendor to document the discussions from pre-selection through statement of work development to ensure all of the requirements are understood and met.

While there is sometimes the perception of false pretenses, it is usually the case that sales departments are not lying when they say the software can do anything. With enough customization (which translates to more time and money), you can make a lawnmower into a motorbike [click here to see how that’s done], but that is not the original purpose of a lawn mower – it was meant to cut grass. Both parties want to ensure that the right tool is doing the job. If you really need a motorbike, buy a motorbike.

Lastly, here is where the executive leaders and a steering committee can provide guidance to ensure the system being built aligns to the objectives of the company.

Software Company: “The customer wants this customization to our system. While we can implement it, it has never been done before and quite frankly, we don’t really understand why they want it. This will definitely delay our project and increase the cost to implement by adding scope but more importantly it will make upgrades harder. Do they realize that?”

Software vendors need to also filter out the customer looking for motorbikes and focus on those that need lawn mowers, if they in fact sell lawn mowers. Enterprise software companies, especially the “new in category” ones, can have a hard time distinguishing between core and non-core features. If a potential customer in your target market segment wants a specific product feature that you do not currently provide or have, it is tempting to add this new product/service to your roadmap. The strategic race for market share may make it hard to turn away potential customers and revenue.

We have witnessed clients chase features that were not core to the software companies competencies or corporate strategies, at the time. The end result was the creation of “snowflakes” or one offs. If you are eventually building to a true multi-tenant platform, this will not work. Even if you intend to host separate instances, you still need to be concerned about paths to upgrade and the total cost of support for software that needs to be retrofitted or taken off the release schedule. Continuous support of customized software is expensive, time consuming and creates an environment of conflict with your customers. The customer will never be satisfied if they wanted a motorbike but instead was sold a lawn mower.

The Request for Proposal (RFP) Dating Game

There is no magical algorithm that can suggest which customers are suited best by which software vendor – there is no magical swipe. The RFP process is an established practice that most companies use to evaluate and select software vendors. Your IT group and CIO are probably the most familiar with vendor selection, since systems are now changed out more frequently – digital transformation and the speed of technology advancement has necessitated that IT shops keep abreast of continual modernization.

However, we continue to see projects fail and many of these failures can be attributed to a lack of due diligence during software selection. The more time you spend here, the better. A comprehensive RFP process takes time and planning, but the time taken at the beginning will help to reduce the amount of money, time and frustration later. System replacement is a major medical operation – it is painful and can take your organization a long time to recover. Your goal is to be better after you have recovered than you were before.

Writing the RFP is only the beginning of the process for the customer. (For more about drafting an RFP, see Seven Insights: RFP 3.0 – Streamlining your Technology Evaluations). The RFP process should also be a time for both parties to ensure it is a correct match. At any point, either party should be able to disengage from the relationship. The following are a few recommended activities in which both parties may collaborate after an RFP is received and a “short list” of vendors is established.

1. System Demonstrations. These sessions are typically for the vendor to showcase the features of the software platform. It is meant to generally demonstrate that the application will meet the requirements of the customer. However, we have found that it is more useful for the customer to have critical requirements prepared for the vendor to specifically address in these sessions. This will take some time and preparation by the customer but once completed, it can be reused for other vendors. In fact, in preparing for the system replacement, the customer should have analyzed and prioritized all requirements. The vendor must be able to demonstrate that the core features of the system will meet these aforementioned requirements through use cases, processes and/or workflows – a clear signal to both sides if critical requirements cannot be met.
2. Documentation, Documentation, Documentation. Record everything. Your system demonstration sessions can be repurposed for future training. Both parties will need to note potential gaps and issues before implementation or configuration starts. Lastly, documenting all discussions will ensure that there are no miscommunications or misunderstandings for future reference. All of this documentation will be reused again. Gaps and issues will become your Risk and Issues backlog and you will have begun work prior to any start.
3. Project Resource Analysis. All project personnel should be identified prior to any project start. For the customer, it means that functional department leads will need to allocate resources accordingly and plan to backfill those individuals. In our past observations, partial allocation rarely works. Full time is best, however, the reality of implementing in the midst of “business as usual” makes it difficult to solely dedicate personnel to the project. Project staff augmentation is a possibly method to alleviate the burden of over utilization but the customer must find temporary or contract workers that understand the company’s processes and business domain. For the vendor, it is suboptimal to have resources not fully utilized. There is tendency, therefore, to overbook project resources. The vendor should plan for multiple contingencies.

Example 2. “Where are the requirements?”

Software Company: “The customer can’t seem to get the specific requirements to us on time and it is causing delays to the project. We need to start preparing for our next iteration and need to get these requirements and use cases ahead of time. Plus, every time we get these requirements back from the customer, they don’t have the spreadsheet filled out correctly.”

Established software application platforms have entire manuals and trainings in support of gathering requirements. In most cases, you are configuring a system – toggling switches up or down, or filling in the blanks of the system. Part of your responsibility as the vendor is to make sure your customer understands how your system works – why it needs the information in this format. Without a configuration tool or service on a software platform, most software vendors will use written documentation: workflow and process diagrams, templated spreadsheets or text forms/documents. 

In the not so distant past, it was functional specifications to technical specifications to development. Nowadays, vendors use terms like “accelerator worksheets” to describe documents that need to take a business’s functional requirements and translate them into something an engineer or developer can code or configure. In our experience, there is something lost in this handover. Customers do not understand how to use the document templates the vendor has provided. They have no context and quite frankly do not think this way. Change is already difficult for the customer, you are training new users on your system and they are learning new processes and new ways to do things that they did not do before. Hiring business analysts to assist your customers in translating their business requirements into your platform is an effective means to not only train the customer but also build collaborative relationships.

Most people are resistant to change. It will help if you find those champions within the customer’s company that will advocate your cause. They are most often the users that will use the system the most and also at times the major constraint to getting the requirements in a timely manner. Moreover, working with the customer on premise and in person is always helpful as it gives the customer a go to person, for questions about the system and the process.

Customer: “We sent the requirements but the vendor doesn’t seem to understand our process or our business really. We are not like every other company. Also please explain how this requirements gathering spreadsheet works. It doesn’t make sense to us and we don’t know why we are filling it out. Instead, we can send over a diagram or workflow.”

While it is never going to be a perfect match, customers need to realize that there is a reason why this particular software application was chosen. It is now your system. It will behoove you to research and understand the vendor’s implementation methodology (that also needs to be part of your RFP process – do they have one?). Each of your users needs to be trained on it sooner rather than later. Additionally, every iteration, you should review the vendor’s use cases or user stories and ensure that these make sense. You will want to schedule multiple discussions to review these stories and the requirements needed.

Example 3. “We are delayed because of testing… again.”

Software Company: “Our iterations keep getting longer and longer, because the customer doesn’t have all of the testing done from previous sprints and is adding to the defects backlog items that should have been fixed two sprints ago. Moreover, we are not sure they understand what a defect is, what an enhancement or new requirement is, or what is not in scope for the sprint or project. This is delaying the project as a whole and swallowing up our development resource time – they are spending too much time fixing defects and not working on the next iteration.”

Agile methods, especially those that divide the work into cycles or iterations is dependent upon a comprehensive and predictable test approach. Engineers and developers need to ensure that their work is unit and functionally tested before allowing the customer to begin its testing. Automated functional testing can assist in reducing test times. While it is still incumbent upon each developer to test, our more sophisticated and mature software clients have dedicated test teams that develop and execute pre-built automated test cases built into the platform.

Additionally, a growing defects backlog could be an indicator of other project process issues: customer and vendor resource constraints, lack of customer user knowledge, sub standard software development or configuration for example. Both the vendor and customer project managers should monitor the defects backlog and the rate at which new items are open and the rate at which defects are closed. Both should flag those items that require more than one cycle to fix – e.g. vendor fixes an item, it is retested and fails again.

Customer: “The system seems pretty buggy. The vendor gives us the user stories but when we try to test them, we can’t even get passed the first few steps. No one has shown us how to work around these things. In some instances, we just can’t. Also we continue to see defects from past cycles and don’t know if they are going to be fixed or have already been fixed (it may be that they tried and it failed again). Lastly, they really don’t give us enough time for the test, fix and retest part of this iteration, so we keep pushing out the end dates thus delaying the project further.”

During the RFP process, you should ensure that the selected software vendor possesses a standard set of user stories and test cases. You will have to build upon these to tailor them for your specific buildout but it is a great starting point. Larger enterprise customers typically have testing teams that will support the  development of test scripts and additional cases. However, if you do not have these resources, bringing in outside assistance is always an option. You may also leverage your or the vendor’s business analysis group.

Delays are inevitable in a project. Your leadership and project manager should develop contingency plans and look for opportunities to accelerate progress. Testing is not only function that will delay your projects.

In the sequel… Part Two: Going Live and more!

About the Author

Will Yen is a founding partner at Kenny & Company and has 20+ years of experience delivering consulting and business solutions for Fortune 1000 companies. His range of experience includes Supply Chain Strategy, Marketing and Product Management, IT Strategy and Planning, Financial Services, SaaS/Cloud Platform Solutions and Wireless/Mobile Computing. Will has been published in Baseline Magazine, Computer Technology Review, and PS Village, and is the author of several research whitepapers and blogs. Will is also a former US Army Officer. He holds a Bachelor’s of Science in Managerial Economics from the University of California, Davis, a Master’s of Science in Applied Economics from University of Georgia, Athens and a Master’s of Business Administration from Duke’s Fuqua School of Business. Will has volunteered his time for organizations like ALS San Francisco, where he was the acting Director of Web Strategy, and RAFT. 

References

1. https://www.cio.com/article/3174516/project-management/it-project-success-rates-finally-improving.html

This article was first published at michaelskenny.com on August 3, 2018.  The views and opinions expressed in this article are provided by Kenny & Company to provide general business information on a particular topic and do not constitute professional advice with respect to your business.

Software Implementation Successes and Failures – The Tale of Two Perspectives by Will Yen, Kenny & Company is licensed under a Creative Commons Attribution-NoDerivs 3.0 United States License .