Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Requirements Analysis: Take Emotion Out of Software Purchasing Decisions  : Page 2

If your IT team runs up against rancor and indecision each time a purchase decision needs to be made, a requirements analysis can help you provide your boss with the documentation and consensus necessary to choose the right software development product in a timely manner.


advertisement
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.



Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap