A Best Practices Approach to Buying Enterprise Software

Software selection is science, not art. It is a solid process with a beginning and an end. Many companies continue to struggle with this issue. Virtually every reader has heard of or been involved with at least one software purchase "horror story" in which the software either didn't work as advertised, or never paid out. Software vendors always get the blame, but is it really their fault? Buying software is a two way street. A successful deployment will involve an equal effort on both sides. Many companies buy a software product such as TPM or analytics and honestly expect it will implement itself -- it won't.

The return you get from enterprise applications is, in many cases, a direct proportion to the preparation, process and people power you put into it. If you buy it correctly, software will be an investment that will provide your company a substantial return year after year. But in my experience, most companies still look at a software purchase as an expense without the belief of any financial returns. In fact monetary returns can be quite large, but again you have to set the table correctly in order to see them.

I have spent the better part of my 25 year career in the consumer goods (CG) vertical. In that time I have learned much about the software business from both sides of the desk. I have seen many mistakes being made with both sellers and buyers, most stemming from lack of preparation. As you read my comments, keep in mind I am talking in generalities and percentages. There are always exceptions in every situation, so my comments reflect the majority of cases I have personally come in contact with (50 or so large software sales).

I started my career on the manufacturer side and spent 15 years in sales and marketing. One day--against my will -- I found myself named to an internal team chosen to select a software vendor for both trade funds and category management applications. I have to admit that I and many others on that selection team were in way over our heads. The fact is we had no experience in the software selection process. We didn't really know what we were looking for or how to go about getting it. All we knew was we had a problem which we hoped someone had a solution for. We limped through our process and wound up deciding to build our own product internally. Little did I know then that this would be the beginning of my transition to the software side of the business.

In the years that followed, we took what we had learned and designed, built, marketed, sold and implemented our own software solution to the CG industry. Seeing the process from both sides of the table has proved to be very enlightening and given me a tremendous respect for those companies who have actually had a successful implementation the whole way through. Many manufacturers don't realize how much more difficult it is to not only sell an enterprise software application, but implement it successfully.

Unlike selling a box of Advil which is ready to be delivered to the customer at the time of the sale, software has so many moving parts; a constantly evolving product, rapidly changing technology, people shifting, and many different client environments. Designing, building, selling and implementing products, while keeping clients happy the entire time, takes a strict process, dual commitment, product and industry expertise, good people and plenty of luck. The fact is even the most perfect software product could be a disaster within any company's walls if it is not properly implemented.
What follows is my attempt to provide you with a best practices approach to buying enterprise software, which if followed, will allow your organization to have a smoother selection process, which in turn will allow you to pick the best product, and get it implemented in a way that improves your ROI and ensures long term use.

"Houston, we have a problem." Recognizing that your current process is broken and/or your current software application is not efficient is the first step to admitting your organization has a problem which needs to be addressed. I can say beyond a shadow of a doubt that if you are currently utilizing Microsoft Excel to handle any process, you need to be looking yesterday. No matter how much you "dress up" Excel, it can't replace an enterprise application. Also, if you are requiring that your sales force send in reports which you have to tally and distribute, it's also time to begin your search.

Is an internally built product best? For any company thinking about creating their own application based on a recommendation from their internal IT personnel, I can tell you that unless you have extremely talented people with this specific type of build and support experience this is a very bad idea. Yes, there are some exceptions I have seen that are working, but this is the extreme exception. Many companies think the result will be an application customized just for them. While that is true, today's flexible technology allows many vendors to achieve the same level of "configuration" with in their products. The difference is that they have build in many industry wide best practices which the client would not otherwise have access to. Once thing I can say without question is that building your own application will not save you money in the long run. Quite the opposite -- expect it to cost your organization at least twice as much over a five year period.
There are many reasons why "home built" software applications don't usually work, the biggest issue is lack of proper documentation on the build-out. This will prove to be the applications downfall once any key member of the team leaves you for greener pastures. Trying to figure out there unique coding style will drive you crazy and sink the project.

I once had a person leave our company and the next day our application was down for all our clients. We found out that this guy was writing a mini-program to keep the application going almost every day instead of figuring our how to fix the issue permanently. Now with him not there, the application wasn't running and clients were calling frantically. It took us two weeks to fix the issue the right way. So yes, you may have excess IT capacity and your internal team may see this as a "fun project" (much better than supporting your current applications). Chances are their skill set will not be there to build and support the application long term.

Another huge issue is that while a good software vendor's application continues to evolve based on their market knowledge and continued learnings from their ever growing customer base, yours for the most part will stand still, keeping your organization isolated, and falling farther and farther behind industry best practices. Product evolution is much of what you pay for in the applications you buy.

Let's say you have recognized you have a problem and have decided you need to start looking for a software product. The very first thing you need to do is to put together a selection timeline and stick to it. Depending on the complexity of the applications you are looking for a sample timeline high-level timeline might be:
> Documentation of infrastructure, processes and requirements - four weeks
> RFP development - two weeks
> Send and receive RFP's responses from vendors - three weeks
> Evaluate and score vendor responses - two weeks
> Final three vendors "dog and pony shows" - two weeks
> Due diligence on final two vendors - two weeks
> Contract negotiation - one week
> Contract in legal review - two weeks
> Signed contract - 18 weeks from start date
Here, it's estimated, at a minimum, it will take you a little over four months to make your selection. You would not want to do this in much less time nor a great deal more. Efficient companies know the key is sticking to their timeline. Once you have admitted that you need help, making your selection on time is one of the most important parts of your entire process and one where most software buyers do not understand the value. The fact is there can be a tremendous negative financial impact if a decision is not made in the timeframe initially laid forth. There are many reasons for this.

Software vendors like all companies plan both resources and revenue. On the resource side, many have a few implementation teams (some a specialized in different areas). Obviously you want their "A" team in your specific area, which in most cases they will want to plan to give you. They will slot them for you if given enough notice, but miss the time window and you will find more times than not that team will be reassigned to another sale. In addition, a vendor might plan for a price discount to ensure the sale happens in the timeframe specified. Miss their window and you might find the vendor not as willing to make those financial concessions. In many cases your delay winds up costing your organization much more.

The very next thing to address is documenting your infrastructure, processes and requirements. One thing that has always amazed me is approximately 70 percent of all buyers who are actively looking for a software solution to solve a problem, have not documented these important items. This is a huge mistake for several reasons. The old adage "if you don't know where you are going, any road will take you there" couldn't be truer. Without detailed documentation of your current environment and needs, you will have no framework by which to judge your potential solutions. I can't tell you how many times I have sat in front of potential buyers of my software asking them what they are looking for, only to hear this response: "We are not sure what we need, so we are looking at everything in the hopes of getting a few ideas."

Not knowing in detail what you need before you start looking, is the worst possible situation for a software buyer. Recognize that any good software salesman makes their living reshaping your vision. Easier yet to shape an organization that lacks an understanding of what they need. If you see five well trained software vendors be prepared to have your vision shaped differently each time. In the end you will wind up looking for months, totally confused, and have little or nothing to show for it. Keep in mind that no two software vendors have the same functionality regardless of their line of business.

Every module is unique to that vendor and may contain hundreds of functional processes. In addition, each vendor has different module offerings which are tightly intertwined making it literally impossible to tell which functionality belongs to which module. The key is to find the vendor which offers you the best combination of functionality, compatibility and growth options. And don't think too far into the future for what you need now. Three years out will be fine.

Once you have completed the documentation of your current environment, you must fashion those needs into an RFP which should be sent promptly to your perspective vendors. Putting together an RFP is vitally important. You must define your project and what issues you will be looking for the vendor to solve. Ask questions in key areas such as:
> Technology
> Integration
> Experience with this type of product and functionality
> Future product direction
> References
> Financial viability
> Implementation process and planned team
> Upgrade plans
> Project risks
> Ongoing support
> Estimated fees and costs over three year period

Your RFP must be very specific. One huge issue is that many RFP's are not specific enough. They need to document your current business and technical environment and your current processes. One of the "inside jokes" on the software side of the business goes something like this..."how does one avoid lying to a software buyer?" The answer is -- to answer their questions exactly as asked. Translation is that most buyers don't ask questions that are specific enough.

Once you have a good RFP developed, you should implement a ratings system for each area and each question: Apply percentages within each key area of your RFP for example --technology counts for 30 percent; within each area of the RFP rate each questions; rank vendors responses once based on their written RFP response (to get down to your top three), then again when the vendors come in for their product demo's; keep track of how each vendor deviates from their initial score; make sure you include a separate line item for "ease of use".

One major mistake companies make in their RFP process is not giving the vendors enough time to reply to them. Vendors need to be given about 3 weeks to respond to a detailed RFP. In my experience, software companies are usually given little more than a week. This is not nearly enough time to put together a well thought out response. The result will be you will not get a good understanding of the vendor's product or their ability to support your needs. Remember you are not the only company looking for software. A vendor needs some time to get their detailed response together.

One final note, it is important to be available to your vendors during the three week RPF response process to answer any questions they have personally. No matter how clear you think you have been in your RFP, there will always be interpretation questions.

WHAT ABOUT NEW PLAYERS?
In any functional area there will always be new vendors to the space. Many times companies are quick to eliminate these new players because they lack the customers or experience. My feeling is that each and every company should be judged by their ability to meet your specific needs. I believe that the best judge of a company is to look at their application because it represents their vision. You will be able to see right through the "pretenders" based on the applications they put in front of you.

Don't put stock in promises that the application's next release is right around the corner and all the stuff you want will be in it. You can only judge what you can see just make sure what you are seeing is not "vaporware". How can you tell? The first thing you can do is give your vendor some data for them to use for the demonstration. Make sure you can follow the numbers on the screens and look to see if they change or disappear altogether. Secondly, that all important reference site visit will take care of any doubts. Be aware there may be a new version of the product which has just been released, if so, you must check on the vendor's last release. Ask questions to customers who were the first to implement it. If they had no major problems, chances are you won't either.
It is important that you use the responses to your detailed RFP as the major decision making factors to whittle down your vendor list. Use other resources such as analysts to fill in the blanks on the second go around for vendors

GETTING DOWN TO THREE FINALISTS
You will field your RFP responses from your potential vendors, then score the responses and decide on three vendors to come in for a face to face product demonstration. Once you have those final three vendors, it is important that you provide a both a small sampling of your data, and a functional script you would like to see demonstrated in their software. This too should be very detailed directions on what you wish to see in their tool.

You do this for two reasons: It forces the vendor to show their functionality the way you will be using it and seeing your data in the tool allows you to follow along better it also allows you to watch the data carry through the tool.

Each vendor should be given at least four hours for their product demonstrations. If you have set up your scripts correctly, you should be double checking each item on your RFP. Remember that even the best written RFP questions may be differently interpreted by each vendor which means their responses may be incorrect. You need to check each and every important vendor response in your RFP. Once you have seen your three vendors you need to rescore the RFP's and whittle down to two. Make sure you are honest to the one vendor who did not make it through on why they did not make the cut.

Next, you would invite your top two vendors in for a day to go through a detailed question and answer session. This is where you both ask additional questions, but give the bulk of the time to your vendors to ask specific questions as well. A sample agenda for this day would be: buyer questions, seller questions, data discussion, integration discussion, timing discussion, outstanding issues and vendor ROI analysis for buyer.

Basically the vendor should be asking you everything they need to know to provide you a detailed financial proposal (replaces the first one they submitted with their RFP). Pay special attention to the questions a vendor asks and they way they carry themselves in this meeting because this is the very best it will get through your entire implementation process. If you are not comfortable that you are connecting or they are "getting it," it's a probable indication of what is to come, and that won't be good.

Pay special attention to their ROI analysis presentation, the model they use, the savings areas they say you can expect and the overall savings they believe you will receive. Look for case studies from the vendor to support their claims. Also, ask specific questions on what their process is to help you measure your savings. Remember in the end it is not what you spend but what to will save that is most important.

REFERENCE CHECKS
References are something that you must absolutely check in detail so plan on a site visit with at least two of a vendor's customers. While there, view how the application is being used and by whom. Is it relevant to your situation? Also make sure you speak with at least two people from each company who have first hand knowledge of both the application and the project. All implementations have issues, understanding the causes and the severity of those past issues are what you are interested in finding out.
It is always good practice to ask the vendor for at least four references and have them provide you with two names from each one. All types of games can be played with references. Going to see their reference face to face is the best way to get a true reference because someone who meets you in person is more likely to give you the straight scoop. My recommendation is the vendor not be present.
Also remember you can request they furnish references based on the "client list" they show you during their initial presentation. Always be specific and ask them which of the customers listed are actually using the product and configuration you are interested in. Once they respond with a list of clients, these clients are "open season" for you to request in your reference process.

One more thing, give the vendor the opportunity to set up the reference for you and don't call into the company unannounced. Most vendors respect their client's time and only wish to let them know in advance that you will be calling/visiting. Once you are a client, you would appreciate the same respect. There is really nothing to be gained by this tactic as you usually wind up with someone removed from the process who will be very guarded when you ask them to share information.

MAKING YOUR FINAL DECISIONS
At this point you should have all the information you need to make your final decision. Making your final decision is a combination of many factors. If you have run your process correctly, you probably have a clear winner. Remember, in the end think ROI not initial price and you won't go wrong. As I said earlier, the most important thing you can do now is make a decision. This will allow you to keep your momentum going when everything is fresh in both your people and the vendor's minds. Move quickly to your most important step which is the implementation.

Stick to your ranking system and don't let other outside factors impact your decision. I've seen it over and over, buyers selecting a software vendor putting too much stake on who can implement the product fastest because they have run behind on time. While it is important for the selected vendor to be able to implement in a "reasonable time period" with excellence, the fastest implementation many times means "implement the product with little configuration or process challenge" and not much more.

A "reasonable time period" is different for many companies. The key is to allow your organization the opportunity to address your inefficient processes with this new application. If you take miss this all important step you will simply be setting up your same old inefficient process and trying to address its issues with new technology. Odds are not in your favor that you will not see much of a return in doing so. You must be prepared to change the way you run your business if you want to see a good return.

Listen to new thinking, understand how other companies who've had the same issues as you, revamped and improved their processes. Learn how you can do it better. Doing this may take many different shapes; maybe you need to purchase additional data, maybe start collecting data you never had before, or reconfigure a product you already have to accept new information from your new application.

Whatever it is it needs to be properly investigated, priced out, and new plans set to address them. In most cases it is better to put off your expected "go live" timing and fix your processes
Your contract is the agreement between two parties on what was purchased and how much things will cost. Yet, I continue to be amazed on what items don't make this all important document. The first thing that should be done is to reference the vendor's final vendor responses in your legal document. It actually protects both parties and eliminates any confusion going forward.

Keep in mind that many vendors modules are intertwined, this means that during a demo you might actually see functionality that is not part of the module they are selling you. There should be no gray areas in the contract. List out the functionality you believe you will be receiving and be specific. Too many contracts go out the door saying you bought "our trade funds module." Even if they have a version number make sure the functionality is documented (modules always evolve). Think about it this way, the vendor could have shown you a configuration of their product done for another customer. That configuration may not be part of their core product.

Linking RFP responses to the contract also allows you to name the vendors key people who will be dedicated on the project to ensure that valuable learning are not lost. You may be a big company, but if a bigger one happens to be right around the corner, you may find their most valuable resources are committed contractually to the other company.

In general, just ensure all the key components you feel are necessary for a smooth and effective implementation are listed in the contract. This also is great for the software provider as a contract which is open for interpretation can cause hard feelings and significant extra costs.
IMPLEMENTATION
Implementation is where the rubber meets the road. By far the most often made mistake by software buyers is not allowing enough time for proper implementation of the product you have purchased. The scenario goes something like this: Company "A" spends eight months selecting a software vendor then allows only four months for its implementation because they are behind on time. This is the norm not the exception. It is as recipe for disaster plays out in our industry hundreds of times each year.

Remember, virtually all of your ROI will be determined in your implementation phase. This is where you should be challenging your current processes and trying to streamline and automate most of it. A manufacturer must dedicate the internal resources to do this right. You must not only challenge the way you are currently doing things, you must set measurement criteria to track your progress and returns.

Only 1/3rd of your responsibilities are complete when the contract is signed. The really hard part is yet to come. The problem is that many manufacturers feel that after they buy a product and sign the contract, the onus shifts almost completely over to the software provider, but it takes a great piece of software, a good process and both dedicated vendor and client teams to have any chance at success.

The buying company needs a dedicated team through the entire process. My recommendation is your chosen team leader be alleviated of their current responsibilities and be assigned full time. This will ensure consistency both internally and for the vendor. In addition, you may have four or more "part timers" assigned to your implementation team. They should be told they will need to dedicate approximately 25 percent of their time here.

Forget the way you used to do business and think about the way you want to do it from here on in. Get it right the first time and save yourself time and money. If you don't you'll be doing it again two years from now.

Another scenario that plays itself over and over is that the manufacturer invites the software vendor in and tells them how many things are broken within their walls. The software company shows potential buyer a product which will help them. Purchaser buys product. During the implementation phase purchaser gets cold feet, doesn't want to change that much or at all. Insists that software be implemented mirroring their old broken processes. This scenario is one of the main reasons companies don't get the ROI they were hoping for.

One of the reasons companies use for not changing is "our people will never adapt to do this." My response: Can't or won't? Proper training can address can't, but only the organization themselves can address won't. Your business must evolve and so must your people. Training is an important part of this process you don't want to overlook. If done properly, your people will become more productive increasing your ROI.

From the outset it is very important to define the responsibilities for both the software provider and the purchaser. I have documented a few items which should be on each list.
From the software seller's perspective:
Implementation Support Activities
- Business process expertise and guidance
- Application configuration
- Data loading
- Admin support and
- Core report creation
- Identify delays on both sides and their impact
Ongoing Support Activities
- Ongoing maintenance and problem resolution
- Review and implement new product features
- Configuration changes
- Training
From the Purchaser's perspective:
Implementation Support Activities:
- Provide data requirements and validation
- Provide business/functional requirements and validation
- Provide security access requirements
- Coordinate communication and rollout of system
Ongoing Support Activities:
- Provide access to internal resources needed
- Meeting coordination
- Data management and integration support
- Enforce processes and reasons they are in place
- Administration of application
- Ensure appropriate usage of system

An implementation plan should be provided by the software company and reviewed by all involved. It should be made clear there are numerous responsibilities on each side. Buyer and sellers have an equal responsibility for tasks on the timeline. One of the issues I have seen occur often is the software providers project manager is afraid to tell the client if they are falling behind on their tasks. The result is a negative impact on the implementation timeline. Better to have a strong leader who can keep both sides "in line" and get tasks completed in a timely fashion.

MEASURING PROGRESS AND ROI
Based on my experience with approximately 60 companies the past 10 years, 90 percent of companies who have bought software never even attempt to measure their progress or ROI. This is an absolute must for all software implementations. This step needs to be completed and right away.
You can start by requiring all your potential vendors to present you a proposed ROI. Look to see the areas where they believe they will generate savings. This is definitely an area where you can compare vendor ideas. Ask them to leave you their numbers. Use this as the beginnings of your measurement criteria. You must first know your starting point then pick the areas which you plan to measure. Ask each vendor how they plan to help you measure your progress and ROI. Ask for case studies of successes with past clients. The key is to come up with measurement criteria and KPI's which you will update on a monthly basis.

Ask what process the vendor is using to help them measure their products return on your investment. The fact is every vendor would like to measure your ROI due to the fact they know documented savings with their customers will enable them to sell new customers faster. The problem is that many vendors are so used to having their customers push them for the fastest implementation times possible, that they have forgotten how to assist you in measuring your savings. I recommend this as one of the first topics to address in your first implementation meeting.
If you followed your process closely chances are you have chosen the right software, implemented it close to your timeline. Now you must continue to benchmark and measure your savings. The key now is to continue to adjust. This is an ongoing business relationship so expect at least bi-annual business review meetings with your software vendor. If this is not part of their current process then make it part of yours. It is critical that senior executives be in attendance.
In summary, there are many great software vendors out there both big and small with many great products. Many times the buyer is the key to getting the most return from their software purchase. Remember this is a partnership with two equal parties. Working together as a team and leveraging industry best practices will almost certainly result in good ROI returns.

Here are my best practices "top ten" for enterprise software buyers:
1. Learn how to recognize you have a problem
2. Assign a dedicated internal team
3. Document your infrastructure, processes & requirements
4. Produce a very specific RFP
5. Define a ratings system and stick to it
6. Do your due diligence in all areas
7. Make a decision
8. Put together a very specific contract
9. Challenge all your current processes and accept change
10. Set ROI measurement criteria from the beginning

Al Kenney is the President of BPR and can be reached at [email protected].