Writing Vendor Requirements to Avoid the Pain

Sunday, February 27, 2011

Brad Bemis


Here’s a pretty common scenario – tell me if it sounds familiar…

You know you have an issue, you talk about the issue, you think up a technical solution, you ask around about various vendor offerings, you read some marketing literature; you may even listen to a vendor give a short product pitch. The solution sounds good, so you buy it, plug it in, then watch it fall short of pretty much every expectation you had…

Okay, so maybe this isn’t an exact scenario you’ve encountered, but I’m sure you can relate. My favorite was a security manager who would go out to lunch with a vendor, and then come back with a signed PO.

No real discussion or planning involved – the product in question sounded like it would meet a need (a need that hadn’t even been considered until the vendors began using their Jedi mind tricks). I won’t even go into the aftermath.

So how do we avoid these failures? Planning is a critical piece of the pie, sure; but it goes deeper than that. One of the most overlooked steps in the planning process is the definition of good ‘requirements’. The way some people avoid formalizing their business needs, you’d think the term ‘requirements’ was a 4-letter swear word…

Either way – it’s definitely time for discussing the critical importance of establishing formal requirements before you start evaluating products and/or breaking out your checkbook.

First things first – what’s the business problem you are trying to solve? A formal problem statement sets the tone for your requirements definition process. If you focus on technologies and features that sound cool, you’re limiting your likelihood of success. Instead, focus on what you’re actually trying to accomplish.

To write a good problem statement, take ownership of the problem (and solution), describe the symptoms and the root cause in measurable terms, identify what’s fact and what’s opinion, establish a vision that expresses the goal state you want to be in and what success looks like, answer the who, what, when, where, why, and how – then, take all of your thoughts and summarize them into a nice simple statement of the problem… Play with it a bit until you get it right.

Before we move on, let's stop for a brief moment to discuss our arch enemy - that evil little gremlin called 'scope creep'.  When it comes to security, everything is interconnected and intertwined.  It's easy to start down a single path that quickly turns into a laundry list of problems. 

However, when it comes to defining requirements, you need to stay focused on solving one problem at a time.  It's essential that you keep the big picture in mind, but if you bite off too much at once, you're bound to run into problems.

Next, identify your stakeholders and get them involved in the requirements definition process. One mistake that’s often made is defining requirements from a single perspective, usually that of an IT person who ‘thinks’ they know what’s needed.

You can avoid this mistake by thinking through who the users of the solution will be, who will maintain it, who will implement it, who will pay for it, etc. Each one of these people (or groups) has a perspective they’d love to share (sooner rather than later).

Together, or individually, sit down and begin brainstorming on questions about the problem and what the right solution might look like. Dig deeply, and keep going until the ideas start to slow down (kind of like microwave popcorn).

Brainstorming is both an art and a science – to get the best results learn how to do proper brainstorming (yeah, I have another article I’m writing, one that actually talks about effective brainstorming techniques).

If you are having difficulty coming up with ideas in your brainstorming session, or you feel that your list of questions is a little weak, there is another option.  You can do a bit of Internet research (something you should probably do anyway), maybe check the Gartner 'magic quadrant' for the technology in question, or read a couple of white papers on the subject. 

You might even check out two or three products and jot down the functions and features that speak to your problem statement.  Just remember that you're not picking a solution at this point, you're generating YOUR requirements.

As you look at the questions you’ve come up with, start turning them into statements that reflect an expectation or preference for the solution that’s needed. Usually these statements should take the form of a single sentence with an object or subject, an action verb, and an outcome or a goal.

The structure really isn’t all that important though, I’m no English professor. What you should really focus on is clear, one sentence statements that reflect what you want the solution to accomplish.  Starting each statement with terms like 'must', 'should', 'may', 'will', etc. can also help a bit.

Refine your statements until they are focused and concise – and you think you’ve got a really good picture of what you need to solve the problem you outlined in your problem statement.

Now spend some time ranking these statements in terms of importance. A scale of 1 to 3, or 4, or 5, works well as long as you include really good definitions of what each rating means. For instance:

1 – Critical, without this functionality or feature the solution will fail!
2 – Required, this feature or function is required, but there may be flexibility
3 – Preferred, this is an important feature or function, but not a key requirement
4 – Desired, this is a feature or function we’d like to see if it’s practical
5 – Optional, an interesting feature or function, but nothing more

Okay, you may want to fluff these up a bit, but these definitions tend to be adequate for most of the requirements documents I write.

We’re just about done at this point. Simply arrange your statements by their rating (and maybe within their rating category; hey, one critical item might actually be more important than another critical item – it happens). Add a brief description of each of your categories and get ready for the beatings to begin.

Your requirements document isn’t complete until you’ve gotten feedback from your stakeholders. Be prepared for some backlash and turf battles though.

If you’ve involved all of your stakeholders in this process since the very beginning, you’re likely to have less problems, but if this is the first time you’re filling them in on your plans, or if it’s been a while since they’ve seen the last iteration – well, you get what you deserve ;-).

So there you have it – a requirements 101 of sorts… Something to help you avoid those nasty ‘assumption based’ product selections that usually end up coming around to bite you in the butt later on down the road. 

As they say in the old G.I. Joe cartoons "knowing is half the battle".  The other half (the more important half) is actually DOING THE WORK to define meaningful requirements.  It's up to you, but I'm a believer...

More to come at a later date…

‘till next time

Cross-posted from http://www.secureitexpert.com

Possibly Related Articles:
Enterprise Security
Enterprise Security Management Vendor Management Functionality Solutions
Post Rating I Like this!
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.