More in Common Than You Realize?
If you fished as a kid, you probably baited a hook and dropped it in the water. When you got older though, you learned how to catch specific fish. You realized it involves an entire system of location, timing, and tools. When the complete system was deployed in search of fish, your chances of success were greater.
Choosing enterprise software involves a system as well, the proper deployment of which can ensure that you catch the software fish you want also.
What is Enterprise Grade Software (EGS)? Examples are familiar names: SalesForce, NetSuite, SAP, Oracle, PeopleSoft. Wikipedia defines it as “computer software used to satisfy the needs of an organization rather than individuals.”
Scope is the difference. EGS tools are utilized by more areas and are more visible (higher or broader) in the org chart than other tools. Scope is what requires a “system” to properly acquire this grade or class of software. Since the tools’ scope can be so large, the decision is most likely a group one. More to the point, several groups are likely to be involved in the decision to purchase any EGS tool. Groups may have their own internal politics as well as external between the groups.
So how can you get the needed results from a multi-group decision-making process? A “moderately democratic” approach can ensure a proper decision from available options. The first step is the development of requirements. With potential competing groups, this can be more difficult than you might expect from off the shelf software.
Each group should develop its own list of requirements. It should involve input from both management and staff of each group. Competing requests should be resolved by group discussion and when the competition is between groups, an arbiter for those decisions must be found. In addition, an overall Project/Solution Consultant should be identified. Their primary task will be to understand the overall requirements and identify competing requests between the groups.
The task of identifying and defining requirements should have a time limit, but all stakeholders should be involved. Determining that time frame is difficult as it varies by the complexity of both the decision and the solution being purchased. It's easy to get “analysis paralysis” thinking that every single “I” must be dotted and “T” crossed. Know there will be tradeoffs between effort and output. If it's determined that the time frame set will not be adequate for information gathering, the process should take a time out and reset so expectations can be more realistic.
When defining requirements there are several sources that can be used as a starting point. Many trade or industry vertical organizations are available to help members in this area. One of the first resources they will recommend will be “Industry Experts.” These are the Forresters and Gartners of the world. Their information and comparisons can be invaluable. Just keep in mind that they are businesses whose primary purpose is to make money.
Specific references who match your industry and requirements are just as valuable. Having a reference whom you can visit onsite is well worth a drive and meal or two. Insights gained from this resource can be even more valuable than those from industry experts. These can become post-sale resources as well.
Your organization’s process may involve an “RFx” process. These are a Request for Information (RFI), Request for Proposal (RFP). Request for Quote (RFQ), and Request for Bid (RFB) and are exactly as their names describe. Each is a formally defined process and document of which there are several sources available for more information. Some organizations will not require an RFx but that doesn’t mean that you cannot utilize these processes as your own. While an RFx process helps, the bottom line is to document the requirements in a form that can be easily transmitted to appropriate parties.
The final decision criteria should come down to a Proof of Value (POV) and Proof of Concept (POC). The POV allows you to establish success criteria and define how a POC should look. Stakeholders should vote or score the POCs based on their groups’ requirements. The scores, together with a written POV, allow a case to be made internal to the organization that the decision is the correct one.
Each organization will have its own purchasing process(es). You must know what part you play in that process or players in the process with which you interact. Vendors have their own selling process and the best will align their selling process to your buying process. Vendors will want to know everything they can about your decision and buying processes and you should share.
An organized system of choosing enterprise-class software eliminates risks and helps ensure the best choice is made. There are no guarantees but following this outline should help clear the murky water (eliminate the unknown and stay with our allusion) and ensure you catch the software fish you want.
About the Author
Bobby McCullough is a Sales Engineer at Flycast Partners. Bobby has over 20 years’ experience with multiple enterprise ITSM and ITFM solutions. ITIL v3 and Scrum certified, he has worked with a range of organizations from large multinational financial institutions to some of the largest Federal and State Government organizations. He todayBobby lives just south of Nashville, TN.