How (not) to Buy Big Ticket Services

Just imagine this: either you or somebody way above you decide that you need a formal inventory system for the equipment that goes in and out of your shop. You go online, search for “inventory management” and spend the next hour or so browsing a plethora of very cool sounding solutions. Like so many people, you may even get sucked into the first one that looks really impressive and spend the time there. You then enthusiastically tell your team about your great discovery and set up an online demo with the vendor after a short call with their sales department who, hearing a brief description of what you need, tells you that they have the best product for the job.

The demo is impressive as well. You learn about some unique features that companies “B” and “C” don’t offer, you see how you can securely access the system from your smart phone or tablet, and how everything will be stored safely in the cloud.

You go through the same exercise with companies “B” and “C,” perhaps check the Gartner Quadrants on the companies and start the P.O. process for the winner.

The likely result is a very expensive purchase that either nobody uses or, if they’re forced to, it gets hopelessly tangled up with bad data and becomes essentially useless.

Let’s do something that we couldn’t in real life and start over…

Try a Different Approach

The first thing to do is gather your team (or representatives thereof) to drop the bombshell about the inventory system. The group should include some frontline people who will be using the system as well as those to be tasked with its implementation, maintenance, administration, and supervision. Your task at this meeting is to clearly state the need—the problem(s) that the inventory system is meant to address. If it was originally your idea, you’ll need to make a convincing pitch on why this important enough to take time away from what the group should normally be doing and possibly why the money should be sucked out of your department budget. If the request came from the upper ranks, let them know what triggered it (new company policies, old company policies newly enforced, etc.). Being a good leader, you try not to criticize your managers (too much).

This may a good time to also present the basics of what the new system should be expected to do. In this case it obviously needs to include records of all the equipment; the detail of what’s included in the records will still need to be hashed out. Will it need to record checking equipment in and out? By whom and how frequently? If it’s not obvious, give your team members an idea of who you expect be responsible for which parts of the system. The idea here is to discuss and define the new system’s goals. At this point, it’s a good time to wrap up the first meeting to give people time to think things through. There will always be someone who has a ton of great ideas right off the bat. That’s great but given an enforced chance to cogitate on the matter they will realize they may have come up with a couple of gems, but the rest would have been a waste of time and needless debate.

Dreaming of Your Happy Place

The goal for the next meeting would be to imagine what a good system would be like for them to work with, given the needs you listed. This would include not only how a system would work, but how it could break. This is a matter of thinking through the nitty-gritty. How will things be added to the inventory? if they are to be checked in and out, who will do it and how will the process work? What type of reporting will the users and managers need? What kind will you and your superiors require? If this involves software or online services, does your IT department have any security hoops you or the vendor need to jump through?

These brainstorming meetings may be best done by the subgroups comprised of the folks who would be most closely involved with certain elements of the system. For example, even though they may think differently about the matter, your tech gurus should probably stay away from the front-line people who will be responsible for the system’s everyday use. You’re asking them to come up with their ideal world. It’s not time for techies to bust any of their balloons. That will come later—maybe.

This brainstorming sessions can get a bit wild, so you’ll need good agendas and a clear goal. If you’re still working with the full group, it can sometimes be helpful to start with the expected end products and work backward. For example, talking about what kinds of reporting will be needed and how items will be checked in and out. Finally, how will they be entered into the system, how will their status be determined (if it’s broke, you don’t want to have someone check it out). This is the time when the best negative thinkers on your team to shine.

Another important thing, as your groups are coming up with features, they should also rate them by importance: essential, important, nice to have. This project will likely involve compromise. It helps to know where your requirements can bend a bit.

The Walkthrough

The next meeting would gather the entire team together and do an imaginary walkthrough of the process. This is usually where you discover things that have been forgotten. That “status” thing mentioned earlier is commonly something that would have possibly slipped through the cracks.

Unless your new system is starting something totally from scratch, you will probably run into the one thing that vendors’ marketing and salespeople never want you to think about: the level of effort required to implement the system. For example, in an inventory system, all your stuff won’t just suddenly appear in the equipment database; somebody will have to put it there. Who will do it and how long will it take? Do you have a source of the data, like purchase records, that can be loaded into it? The same would go for check-up inventories down the road. If the inventory requires original purchase information like date, vendor, and cost, that could involve a lot of research.

One of the most important things you, as manager, need to contribute to the process is to ask good questions and listen to the answers. You don’t need the all the knowledge and expertise of your front-line folks, but you do need a basic understanding of what they do and what they need to do it well. Your 10,000-foot view may help you see things that are invisible closer up. Those kinds of skills are essential for all this to work.

Sometimes, the Answer is “No”

One of the worst scenarios a manager can face is the case where the original requirement has been handed down from above, but their requirements would be too burdensome in terms of time and cost for them to be implemented in any practical way. However, if you’ve followed our path this far, you will have a lot of documentation to support your case, possibly negotiating for extra time or assistance in the implementation or whatever other obstacle needs to be overcome.

Assuming things have gotten this far, the next step is to take the results of a successfully completed walkthrough and list out the features your ideal system needs to have, should have, and would ideally have. Now it’s finally time to start your research and contact vendors. Rather than getting overwhelmed by all their products’ bells and whistles, you can focus in on how it will meet your group’s specific needs. You may even be at a point where you have a specific list with features and priorities and can score a vendor on how well it meets each. If none meet one of your essentials, you can either look to more vendors or reevaluate how critical that need is.

Buy-in: What Money Can’t Buy

Where all this hopefully leaves you is with an available product that mostly fits your actual needs and the beginnings of a plan on how to implement and use it. But there’s one added benefit we haven’t mentioned. All these long and sometimes painful meetings have virtually guaranteed buy-in from your team, the stakeholders. They will know beforehand what they’re getting—what they can have and can’t have. And they’ve agreed to live with it the best they can. That’s one feature that no product can offer on its own.