The software procurement process is broken I recently came across a blog describing how companies buy software. This is something I am certain many of us are familiar with. Traditional advice goes something along the lines of; Have each department involved and create a formal understanding of the business requirements. Thereafter collate all these needs and generate a formal procurement document. These documents are then sent to various vendors who get to answer these questions as best as possible and unsurprisingly almost nobody ever marks the not possible box. Thereafter the shortlisted vendors are selected and they get to typically present an on-site demonstration of the product. Unsurprisingly this demo is often again feature / function oriented. This process in my opinion is fraught with problems and delivers sub-optimal results for everybody concerned. Here is why?; The question and answer format does not provide any basis for evaluating HOW something actually occurs within the software being reviewed. For example “Can your product do XYZ?”, the answer will always be yes. But the real issue is how do es the product perform this and what steps are required and what are the limitations etc?. The people buying the software typically frame and base their questions from an existing point of reference. For instance in the system they are currently using they have to do XYZ and are therefore asking questions of the vendor around something that might not be required or might not really matter in a future state, but is highly relevant from the current reference point. For the future software does things differently, therefore they never need to “press the any key”, so why ask about it? The implementation cycle and effort to get started with the new software being reviewed is never really understood. Typically this is a result of the vendor under-estimating the complexity or over-estimating and being fearful that they will be disqualified. Likewise the client who has a more fully formed understanding of what is actually required always tends to view the project as simpler than it often is. This of course leads to the dreaded time and materials model which almost always results in costs escalating way beyond the original expectation. So the question is, can this procurement model be improved upon and how might we do so? In my experience very definitely yes and the best procurement scenarios, as a vendor, that I have been part of worked like this; Rather than ask thousands of feature function questions, have your departments and analysts write up several end to end processes that you would like to see modelled. Focus For example; a. Onboard a new driver starting with X and ending with Y. b. Place a freight order assign the truck and dispatch the load. c. Resolve a complaint from a driver when wages were incorrectly applied. The Idea here is to describe the typical things that you would like and need the system to deal with, on a day to day basis. Focus on the process description rather than the how. Take your time and try and consider all elements of this process. The more descriptive the better. Once these use cases have been developed, share these scenarios with interested vendors and explain how the procurement process will be conducted and what you expect; We would expect a demonstration of these scenarios be performed not features and functions, you of course get to use the features and functions to show the process in action. Ask for rough ball park pricing, but note that this is not firm and they will have time to firm pricing post demo. You are doing this step just to weed out a few vendors that might be way over budget no matter how good they might be. Affordability will matter at some point. Conduct the demo days; Watch as the scenarios are walked through by the vendor. Watch carefully for the number of clicks, “hand stands” and “shuffles” required by the system to complete the prescribed scenarios. Throw a few curve balls into the mix once you have seen the complete scenario implemented end to end the first time. Do not mix curve ball changes in until you have at least seen the first clean pass. Again understand carefully the “hand stands”, “shuffles”, and clicks required to accommodate the curve balls. If there is merit or the procurement rules allow, have the vendor back if necessary. Perhaps on the second attempt they might have a closer working model. At this point it should be very clear to you as the customer what the differences and capabilities are between the various offerings as well as a much better understanding by the vendors as to what you are expecting. Allow the vendors to firm up pricing including implementation for the described processes outlined prior (this should be the basis of the contract terms) More processes might require more service hours but likely in order to implement the key critical process flows that were the subject of the demo and RFP items a lot of other ground work will have had to be completed so there should be less contract variability. Now contract and implement those aspects and processes as the initial deliverables, so that You are able to achieve some specific objectives for a measurable budget and effort. There should be a much reduced gap in vendor client expectations and therefore a smoother project implementation. What I have attempted to share, is hopefully a usable outline for what I would consider to be a more practical guide to better software procurement. A way to address features/functions and demo failures and to get a much more practical understanding of how the software will actually work and at the same time reducing some variability on service hour and overall project costs.

Email and spreadhseets, while pervasive as sub-optimal. They result in endless follow-ups, poor tracking and limited visibility.