urchasing a software development product that different users will utilize in different ways is one of the trickiest tasks IT shops face. When selecting a tool such as a bug-tracking system, for example, one must resolve the requirements of four different groups: developers, testers, project managers, and senior managers. Attempting to satisfy all these groups during a buying decision often results in emotional turf wars and lengthy deliberations.

If you’re part of an IT team that runs up against this time-wasting rancor each time a purchase decision needs to be made, a well-documented, well-executed requirements analysis can help you choose the right software development products in a timely manner. Using the process I outline in this article, you’ll be able to provide the documentation and consensus necessary for your boss to go with your recommendation.

Take Emotion Out of the Process
The two typical approaches for choosing which software development tools a team will use are:

1. The Dictatorial Approach?One person, usually a senior manager, decides what everybody will use. This approach is very straightforward, but since the manager doesn’t do the jobs of all the people who will use the system, it can lead to bad purchases.
2. The Ad-Hoc Committee Approach?A team (composed of individuals with differing interests in the benefits of the tool) collectively decides which one to buy. This approach can be extremely frustrating, because vocal, opinionated individuals can either force a poor decision or spend so much time arguing that no decision is ever made.

   Often, arguments aren’t based on the relative merits of one system over another, but instead on people’s deep-rooted insecurities. In my experience, people often cling like limpets to a product that catches their fancy but offer little tangible reason for their choices.

A properly planned and executed requirements analysis will avoid such emotions and result in a better purchase. Plus, it will assure a decision within a reasonable time frame.

Get Consensus and Authority
Your overall aim is to achieve the two holy grails of any good corporate decision: consensus and authority. In a group decision, you probably aren’t going to get exactly what you want. However, you’re more likely to get something you’ll be happy with if you have more input in the agenda.

Get Enough of a Consensus to Approach Your Boss
The first task is to have enough key people on your team agree that there is a problem with the current situation. You may already have concluded that a specific product is required, but this is not the time to bring that up. Your job at this stage is to help others see the problem and understand that it can be solved.

You should approach this with a reasonably open mind. Get an understanding of other people’s perspectives on the problem and how they see it being solved.

For example, you may be concerned because the chaotic way your team handles change requests and bugs causes schedule delays. Mentioning these types of concerns to your colleagues?without allocating blame?is a good way to get them to pay attention. You can best accomplish this by highlighting facts about the inefficiency’s effect on your company or department. For example: We missed our deadline and we still don’t know how many bugs are outstanding, or We delayed our release by two months because of bugs that had already been discovered but not fixed. The CEO is going to blame us even though the system is at fault.

Then explain how the problem could be solved: A Web-based bug-tracking system at my previous workplace solved this problem. Don’t mention any specific product yet, because you want to remain as vendor-neutral as possible at this stage.

Remember, you likely won’t convince everyone at once that a new solution is required?and you won’t persuade some people at all. Don’t be disheartened, however. If you state a reasonable case and remain patient, you’ll persuade enough people in a week or two.

Authority: Take Your Case to the Top
Once you have two or three key people convinced that something has to be done, you need to get the authority to spend some more organizational time on the problem. There is a Catch-22 here: You aren’t going to convince many of your colleagues to spend time on the problem unless they know that your manager is going to take you seriously, but your manager is unlikely to take you seriously unless you have some colleagues supporting you.

This is where the persistent “merry-go-round” approach is so valuable. Rather than trying to hit a home run, move around the bases one at a time.

Give your boss an understanding of both the problem and the likely nature and cost of the solution. You aren’t trying to get approval for a purchase, just agreement that you should investigate a solution to the problem. As with your colleagues, a good approach is to be as specific as possible about the problem and as general as possible about the solution.

Rather than saying, “We want to buy this particular bug-tracking system because we think it’s cool,” approach your boss with: “We’ve been discussing the reasons for the slip in our schedule and think it is because our issue management isn’t as good as it should be. If it’s OK with you, we’d like to investigate buying a $4-10,000 commercial bug-tracking system.”

Like a politician, you have to cater your message to the audience. Your boss probably wants to bring the process under better control, whereas your colleagues don’t want to be fired for failing to deliver. Both can be satisfied with the same solution if you present it to them differently.

Keep in mind you are trying to get approval for two separate things:

1. Spending organizational time on the issue?You need to persuade your manager to allow you and your colleagues to spend time investigating the issue to come up with a solution. In some organizations, this requires a project code, but normally a boss’s okay is sufficient. Once you have permission, rounding up the people who initially didn’t give you the time of day will be much easier.
2. Acting on the recommendations you’ve made for product evaluation?You are trying to get implicit agreement from your boss that your analysis recommendation will be approved. Nothing is certain, but if you go through the process described in this article, only a capricious boss would turn down your proposal.

After you’ve gone around the merry-go-round once, you are ready for the next stage of the process: creating a strong consensus among your colleagues that a specific product should be bought. This is when a requirements analysis is invaluable.

Focus on Requirements, Not Features
What many people call a requirements analysis is in fact a comparison of feature wish lists. These are not the same thing. Organizations that purchase using feature lists generally choose the product that has the widest feature set, which encourages bloatware. (Would you rather own a digital watch with a built-in calculator and telephone dialer or a Rolex?) Requirements analysis must focus on your current and future needs, not a laundry list of features that may not solve your particular problems.

Given the example of a bug-tracking system, the overall requirements might be:

1. Making it easy to find issues and reproduce them
2. Enhancing and enforcing software development processes
3. Providing a comprehensive overview of the project and team progress
4. A system that is simple to secure and administer
5. Low implementation and management costs

Every company’s requirements are slightly different, but in this case try to focus on the areas expected to make an impact on the effectiveness of the implemented system.

State up front whether every requirement is equally important or whether some things are more important than others. You can use this later when totaling up the scores for the different products under evaluation. (The requirements analysis spreadsheet included with this article uses a simple rating scale where 5 is the most important requirement and 1 the least important.)

If you can agree on requirements before you begin serious evaluation, it will be easier to deal with the inevitable requests for features. You will be in a position to judge features based on their ability to meet the key requirements you’ve defined, not on the fact that they sound cool or suit the fancy of one person. Obviously, you can’t be 100-percent strict here, since some of your requirements might come out of understanding what is possible with a product.

Look for Improvement, Not Perfection
Once you understand your requirements, you can use a requirements analysis spreadsheet to help determine the best product to buy (see the sample spreadsheet for an example). Now comes a slightly counter-intuitive bit: the best product to buy is not the perfect product. You are trying to arrive at a solution in a reasonable timeframe that allows you and the people around you to work together better than you did before.

You don’t need to evaluate every possible product. You need to evaluate products only until at least one satisfies your requirements. If you set out on a quest for the perfect product, you’ll probably never make a decision. Companies that seek product perfection generally end up writing their own solutions, which they usually regret later.

After you’ve identified products for analysis, you should ask those involved in the decision-making process to use the spreadsheet to rate how well each product would meet their requirements. Although you want to avoid ending up in a vendor feature war, sometimes you will be forced to discuss specific features. Here is an example of how you might handle a situation involving two features found in some bug-tracking systems:

1. The ability to save an attachment with an issue?This is likely to be very useful in making the issue reproducible, so it should receive a high score on one of your major requirements in the analysis spreadsheet.
2. The ability to integrate with SourceSafe?This would allow you to log every issue in SourceSafe, reducing the risk of two people doing redundant work. This feature could, however, ultimately burden your team with additional overhead that other process-related aspects of the system should handle. If you wouldn’t use this feature, it shouldn’t influence your rating.

Try to include all interested parties in the rating process and convene a quick meeting to agree on the ratings for each product (or just average the ratings if time is short). At this point, you can also rank the different requirements in order of their importance.

Next, simply multiply the rankings and the ratings in the analysis spreadsheet to calculate overall scores for each requirement. Adding the overall scores gives you a composite score for each product. The highest-scoring product probably is the right solution for your company.

You Won’t Find Everything You Need in One Product
By now you may realize that you aren’t going to find one product that matches your requirements exactly. You might ask yourself: If a reasonable selection of products provide most of what we need, why can’t we get the functionality that perfectly matches our requirements?

The short answer is that software packages are off the rack, not custom-tailored. A good software vendor does market research, conducts usability tests, and spends years trying to develop code that makes life better for those doing certain tasks. But even the best software isn’t going to meet every requirement. You have to sacrifice the dream of ultimate functionality for incremental improvement. As long as you know that the new software will deliver improvements that justify its cost, buying the product is nearly always better than writing a custom application or deciding against the purchase.

Once you are a licensed customer for the software you’ve selected, you should have a direct channel through which you can communicate your requirements to the vendor. In the best-case scenario, features that meet important requirements will be included in future versions of the software.

Remember to present the requirements analysis as soon as you’ve finished it. Strike while the iron is hot!