Smart technology procurement starts with identifying what you need

First in a series. Many IT professionals know how difficult major technology purchases can be. Projects like picking a new CMS system, selecting a data center or replacing helpdesk software are relatively infrequent. This means employees are not well-practiced with determining and organizing requirements or the product selection process.

They are often biased towards those products they already know, and may not be familiar with some others competing in that market segment. Throw aggressive sales people and tight deadlines into the mix and you have the recipe for a technology purchase that is decidedly not optimized for the business.

Lack of structure in decision-making is a large part of the difficulty. Putting a structure around the decision-making process makes it easier to manage and consistently faster. However, the real payoff is when you make a purchase decision optimized for your specific needs. In other words, you buy something that really works for your organization!

Previously I identified the hidden costs of poor technology purchasing. This followup is the first of a two-part article describing a structured method for making technology purchase decisions. The first part covers creating and managing purchase requirements. The second explores evaluating products against these requirements. This structured approach works best for technology purchases where there are many product features to compare or requirements to consider. Note that in this article the word product is defined very broadly, and includes software, hardware and intangible services that an enterprise might purchase.

Organizing Requirements

Properly defining purchasing requirements is the key to making the best possible purchase. People often begin with a blank page in Microsoft Word when gathering requirements. Initially this works well, but it does not scale up as the number of requirements grows. As the information increases, it gets harder to manage the requirements because there is so little structure. What structure there is, must be manually managed.

The first step to bringing structure to the decision making process is to organize requirements with a spreadsheet. Because there are always far more requirements than products to be evaluated, it is better to organize the spreadsheet with requirements columns down the left and products across the top. Spreadsheets work very well, but they eventually suffer from a scaling problem as the number of requirements increases.

This could be improved by building some sort of database. That usually is too much work for one purchase, but leads to the idea of a general-purpose tool. Since that is the realm of commercial products, this article concentrates on using spreadsheets to make the purchasing decision.

Requirement Details

The second step is to realize that a requirement is more than just a name. Each requirement has several parts, as listed below. Typically, these are arranged as columns on the left of the spreadsheet. Note that requirements can also be expressed as features; it depends how you word them.

Name: A short descriptive tag that uniquely identifies a requirement.

Description: Provides context and amplifies the meaning of the name to ensure everybody knows exactly what is meant by that requirement.

Person: Optional, and only used in larger evaluations involving many people. Describes to whom the requirement is important.

Importance: This describes in words how much the requirement matters to the business (or person).  Usually implemented as a drop down box. There should also be a numerical measure associated with the importance (more on this in the second article), and a description of the importance. See table below for an example. Note that the “Importance Description” is vital so that everybody involved has the same understanding of each term in the table.

Reason: Explains why the requirement is important, and provides context for evaluating products against this requirement.

Finding Requirements

After using the product in production for a few months, you do not want to find features are missing. That is when you can get buyer’s remorse! Thus, this next step of finding requirements is very important. There are three primary methods, listed below.

Your Knowledge

As an IT professional, you usually have some knowledge of requirements, especially on the technical side. This is a good place to start. Product reviews can be helpful, particularly when the reviewer makes negative comments. Pay particular attention to any reader comments added to on-line reviews because they can highlight real issues, and can alert you to the presence of unknown competitive products.

Reverse Engineering Product Features

When considering a major technology purchase there are usually a few potential products already in mind. Use the features of these products to generate your list of requirements. This is really reverse engineering your requirements from the product features, and is an incredibly powerful technique for rapidly getting a comprehensive requirements list together.

After reverse engineering the first product, you have a great set of requirements and a product that matches up very well. You are tempted to stop right there! But when you repeat the process with a second product, your perspective quickly changes, and you are likely to add quite a few more requirements. It’s a bit like needing to hear both sides of an argument. Ideally, you want to reverse engineer the features of at least three products to ensure you get a broad enough mix of requirements.

User Input

After reverse-engineering requirements, you need other people to tell you how important the requirements are to them, and why they are important. This helps you better understand the problem the proposed purchase is attempting to solve.

When considering software purchases it is useful to examine the flow of work around the system because that can also alert you to new requirements. Pay special attention to the manual workflows of existing processes.

Managing Requirements

As the number of purchase requirements grows, you need to manage them. Do this by collecting related requirements in groups. You can also weight requirement groups, explained in the follow-up article. Broadly speaking, requirements are either technical or business. Under business, you should include things like legal, compliance, etc. and softer things like vendor financial health, product price and contract flexibility. For example:

• For any vendor, what is their financial health? What is their cash flow like compared to competitors? You do not want to sign up with a vendor and find they go out of business after a year.
• You could look at datacenters. What is the average age of the equipment? Too new and it may suggest an immature vendor. Too old and it may suggest cashflow problems.
• You are considering a SaaS product. Does the vendor require a minimum commitment of a year, or will they allow you a monthly contract while you pilot the product?

Even though these softer requirements may be somewhat subjective, it is vital to consider them because they can make a real difference to the vendor relationship and the ultimate success of the purchase.

Requirements Conclusion

Properly defining your purchasing requirements is the key to making the best possible purchase. In this article, we described a structured method for creating and managing purchase requirements using a spreadsheet. In part two we describe how to rate products against the requirements so you can select the product that best meets your specific needs.

Photo Credit: Adchariyaphoto/Shutterstock

Chris Doig has personally seen the problems caused by poor technology purchasing in multiple companies. He co-founded Wayferry, a startup that created a free decision support tool for technology purchasing. Wayferry’s mission is to help IT people everywhere make better technology purchasing decisions.