The Value of a checklist.

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.

Everyday hundreds of transactions are processed through your TMW systems, whether TruckMate or TMWSuite. You’ve configured what KPI’s and events matter, and the DAWG constantly reviews your databases for appropriate transactions. When it finds and appropriate rule, the system will send an automated email alert to the designated people so that action can be taken. These email alerts signal that someone needs to provide guidance. That something requires people to intervene. Dutifully these requests are emailed out, to get taken care of. Have you considered; Who is assigned to deal with the issue? Who is accountable? Are you sure that they are paying attention and will treat the item with the priority required? Will all the people deal with the issue in the same consistent way? Do you have to send the email to a whole group to make sure that at least someone dealt with the issue? Does everyone then have to chase everyone else around to make sure it is done? Is it ever actually fully completed? Would you know? What are they doing? Is there a way to check if it is a longer running series of activities? Did they follow the procedures? Does everyone know the procedures? Can we track these tasks? Did we drop the ball? What is the cost to rework? What are the consequences failure?. A lost customer, a contractual breach, exposure to liability? Clearly using email to manage these activities is not an ideal solution for the reasons above and more. Email is not workflow. With WorkOptima, that same email is used to start the process, so no changes to any existing systems is needed. But rather than ending up buried in an already full email box somewhere, WorkOptima receives the email message, assigns it to the correct process and initiates the appropriate workflow that you have assigned. This way; The issue becomes instantly visible to everyone, nothing is potentially overlooked. We can track it to conclusion. Appropriate and vetted workflow steps are applied to ensure accurate and consistent outcomes, The assigned people are notified and the service levels ensure that it gets dealt with according to schedule, The workflow enforces accountability. It allows reporting and ensures that the process is consistently applied. Avoid liability and post-event drama, At the end of the process, the steps and decisions taken are known and archived as an audit trail for both follow up and future process improvement. And WorkOptima is easy and simple to use, and it requires no changes to your existing systems! Handling emails, DAWGs and exceptions; Better, faster, at lower cost, more reliably with visibility and oversight. What's not to like?

Software, Buy Versus Build A question often asked or at very least considered, is shouldn’t we just build this ourselves? The thinking typically goes something along these lines; This is really not that complex, From a certain distance even the most rugged and horrible mountain does not look that hostile. From far enough away the specific contours, rocks, icy cliffs, cold rock faces and myriad other obstacles are never visible. Absolutely, many people could ultimately climb the mountain, but how much training, learning, experience and preparation will it really take? With every software system once the project gets underway, there will be hundreds of issues that the development team will encounter. Each issue has a cost, whether in time, effort or additional money and will need to be accommodated and dealt with. Each issue adds to the delay in delivering a good solution. Ultimately if one accurately and fully scoped the solution and functionally decomposed that solution into all the many building blocks required to deliver the solution, you might find that many good solutions don’t appear too complex on the surface, but like the mountain, the true complexity and scope is hidden, until the details are really understood. Our needs are simple, we don’t need all those features, Taking the same mountain analogy, sometimes when we are too close to the details, we don’t see all the other options that we might need to consider once that specific obstacle is scaled. The climber when scaling the rock wall, is only able to think about that rock wall, more specifically just the next few hand holds. All attention is about scaling that cliff. Though admittedly not a trivial issue, it is certainly not the time right now to discuss tomorrows hike across the windy ice plain. Very few companies ever start out by saying that their needs are complex. Typically because the users are fixated on their personal interactions with the system or process. Few people are fully aware of the overall big picture and those with a big picture overview are seldom aware of all the nitty gritty details and use cases. In virtually every software package the many features and functions are attributable to the various use cases that customers have required the product to achieve. The collective use cases demanded by the marketplace improves the breed, and makes sure that the product is able to deal with many scenarios, specific issues and not just a singular option. More often than not many of the features in a good off the shelf package will ultimately prove to be useful. As you better understand your needs and the product and its capability to improve outcomes within your organization, it becomes useful to enable those features and expand the value of the solution rather than not having the option to do so. We already have developers on staff, The thinking here implies that we are already paying these people and to achieve the incremental product it is essentially free. Not so fast! Consideration needs to be paid to the following; Not all developers are equally good at all types of technology and coding. How long will it take certain developers to achieve the functional knowledge and be able to produce the solution? Are you paying for software development or incremental learning? Many software companies building commercial software, have considerable teams of developers with specific skills able to perform the necessary development. Will you have to add people to your development team as the project evolves to achieve the desired results? Commercial software companies have people assigned to customer support and training. As the solution evolves are your existing developers able to perform both forward looking development and support? Will they become consumed by support and ongoing development such that they are unable to do any of the other daily IT tasks that they were hired to achieve?. Will you be forced to grow your team to keep up with the new demands? There is a huge distinction to be made between building something for today’s needs versus the ongoing resources that will be needed to accommodate other use cases of the software within the company. This relates back to the prior point about our needs are simple, they seldom really are, and your development team will need to keep enhancing and improving the product to ensure that it keeps pace with the evolutionary needs within your company. Will this project take on a life of its own?, or will your IT people be able to return to their prior responsibilities? It never ends. There are very few development efforts where you are able to say it is 100% done, we are at the end and we never need to come back. Since software is being used in a dynamic environment, namely your business, it needs to continue to advance and scale to accommodate new perspectives. Will you always maintain the development team and those skills to ensure that you are able to continue developing that in-house developed product? At what point does this “product” become a potential liability to the company, when staff leave?, when the business changes?, when the team can’t get to other development needs? Our process are unique anyway, Before accepting that your processes are really unique consider, is this aspect of your business something that makes your company totally unique in the market place? Is this the feature or process that defines your “secret sauce” as a company? Facebook had to build the product, you and I, not so much!. Before assuming that the product is indeed unique and it is indeed the secret sauce, be very objective. Sometimes processes are complex and some companies have developed complex processes but they are not in of themselves adding to the companies strategic value or secret sauce. They are just complex because there are many moving parts. Before you make the build decision, review these processes carefully. See if a commercial product can’t address them? Learn how other companies implement similar processes. In this regard an outside perspective can be very useful. Alternatively the process might just benefit from some clean up. Over time many processes become more complex as they get added to, rather than restarting from a clean sheet. Sometimes processes evolve owing to limitations in the existing environment and systems and perhaps a new system would simplify this. In all these cases this is not likely justification for a build decision, but rather that some work needs to be done to improve the operation of what are complex but likely generic processes. When to build? If you determine that a process or aspect of your business is indeed and truly your secret sauce then it may well be expedient to build a solution to accommodate that process, report, module, interface, web site or whatever to encapsulate that specific process. It is seldom true that just because one process is strategic that this is justification to build a complete system. Rather find ways to achieve a blend of a commercial offering for all the reasons above, but that can accommodate your proprietary and strategic extensions. This way your development efforts accommodate strategic advancement and are of high value and are not generic coding to recreate what is already commercially available. WorkOptima, is a purpose build solution to deliver business process specific workflows. WorkOptima allows you to focus your efforts on delivering the end user solution to your business users and not re-inventing the wheel. Time to market and cost of ownership are paramount to success.

WorkOptima does exceptions processing and email is not workflow - huh? Everyday hundreds of transactions are processed through systems like Oracle, TMW, TruckMate, Manhattan, Peoplesoft, JDE, Microsoft GP and many many others. Everything works well.......almost!! Frequently within a transaction, there are situations that need intervention. Perhaps the system doesn’t know what to do, someone needs to provide guidance, something requires people to intervene. This is perfectly normal. Like thousands of other businesses, what happens? You configure your system to send out emails or create alerts, asking people to deal with these situations. Dutifully these requests are sent to some email address, to which we have assigned a whole bunch of people, to get taken care of. Therein lies the issue; Who is assigned to deal with the issue? Who is accountable? Are you sure that they are paying attention? Will all the people deal with the issue in the same way? Do you have to send the email to a whole group to make sure that at least someone dealt with the issue? Does everyone then have to chase everyone else around to make sure it is done? Is it ever actually done? Would you know? What are they doing? Is there a way to check? Was it dealt with in a consistent way? Did they follow the procedures? Does everyone know the procedures? Was it dealt with in a timely manner? Was it dealt with at all? Can we track these tasks? Did we drop the ball? What is the cost to rework? What are the consequences, a lost customer, a contractual breach, exposure to liability? Clearly using email to manage these activities is not an ideal solution for the reasons above and more. Email is not workflow. With WorkOptima, that same email goes out, so no changes to any existing systems is needed. But rather than ending up hidden in an email box somewhere, WorkOptima receives the message, assigns it to the correct process and initiates the appropriate workflow that you have assigned to the exception type. This way; The issue becomes instantly visible to everyone, nothing is hidden. We can track it to conclusion. Appropriate and vetted workflow steps are applied to ensure accurate outcomes, The assigned people are notified and the service levels ensure that it gets dealt with, The workflow enforces accountability, allows reporting and ensures that the process is consistently applied. Avoid liability and post-event drama, At the end of the process, the steps and decisions taken are known and archived as an audit trail for both follow up and future process improvement. And WorkOptima is easy and simple to use, and it requires no changes to your existing systems! Handling exceptions, better, faster, at lower cost, more reliably with visibility and oversight. What's not to like?

The busier we are, the more likely we are to make mistakes and therefore the more important it is to have strong processes