In 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 isnt an exact scenario youve encountered, but Im 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 hadnt even been considered until the vendors began using their Jedi mind tricks). I wont 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, youd think the term requirements was a 4-letter swear word
Either way its 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 whats 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, youre limiting your likelihood of success. Instead, focus on what youre 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 whats fact and whats 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 thats often made is defining requirements from a single perspective, usually that of an IT person who thinks they know whats 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 theyd 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 Im 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 youve come up with, start turning them into statements that reflect an expectation or preference for the solution thats 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 isnt all that important though, Im 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 youve 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 wed like to see if its 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.
Were 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 isnt complete until youve gotten feedback from your stakeholders. Be prepared for some backlash and turf battles though.
If youve involved all of your stakeholders in this process since the very beginning, youre likely to have less problems, but if this is the first time youre filling them in on your plans, or if its been a while since theyve 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
Source: infosecisland.com
Add new comment