Posts tagged ‘Requirements’
When you are thinking of buying a shiny new car, you probably have a few basic requirements in mind. 4 wheels are good to have. 2 door or 4 door. Satellite Radio or built in GPS. And in my family’s case, how many ways to keep the kids entertained while we are driving long distances?
These requirements are fundamental. Not many people also come to the dealership with a list that says the car must have 3 AC outlets, 15 cup holders, and seat-back pockets to hold tissues & maps. And if they did, can’t you just imagine the grin on the dealer’s face as he thinks about how much extra he is going to charge you for the extra cup holder adaptor and upgraded seats. And hopefully you’ll overlook the fact that there is NO WAY to add an additional AC adaptor to the car that already has 2.
The concept of having a high level set of requirements and the less-valuable detailed list of requirements is what I have found applicable to purchasing a software package from a vendor. My experience has shown that there are ways to avoid analysis-paralysis, sticker shock, or project risk in these situations.
First, it all starts with setting a priority. Even before you talk to a vendor. Your project sponsor must decide what comes first – Scope, Schedule or Cost. Based on this upfront discussion, you can make decisions throughout the life of the project easier. Based on the priority, have a discussion with your project sponsor about the ramifications of customizing any software package purchased. Customizing a software package is fine if your priority is Scope but if your sponsor is more aligned with Cost or Schedule, then you should try to avoid customization like the plague. Customizing software – no matter how experienced the vendor – adds Risk & Cost (short-term at implementation and long-term in ongoing maintenance). Having your sponsor on the same page with you from the start – before they start to hear about all the great things the vendors can do for them – makes conversations about eliminating customizations easier.
Second, evaluate whether your software is supporting an existing business process or a new process – perhaps a new product or service you are planning to offer. If the process is existing, make sure it is documented. If the process is new to your organization, skip to Step #3. For existing processes, work with the impacted stakeholders to identify processes that MUST be supported by the new software. And don’t let them waffle on you – there is a difference between MUST and Nice to Have.
Third, issue your RFP. I find it helpful to give my vendors insight into my priorities (Scope, Schedule, Cost) and to base my RFP on the Must Have requirements plus many other requirements about the ongoing relationship, architecture, and other things.
Once you have selected a supplier, do not start building a list of requirements. Start with reviewing their available documentation. Any vendor worth anything can provide you with system documentation that outlines how their system supports various business functions. A user’s guide at a minimum would suffice. Walk through this documentation twice. Once to gain an understanding, and the second time to see how it applies to your organization. This is where the process documentation comes in handy – if you have it. You can align the system documentation to the process documentation and document the gaps. These gaps are then reviewed for Must Have versus Nice to Have. Again – keeping in mind the Scope, Schedule, Cost priority discussion in Step #1. If you are building a new business process, you can start to build your process documentation based off of your stakeholders input and the functionality supported by the software.
By basing your requirements off of the gaps and not trying to build a full set of requirements from scratch, you can avoid spending hours eliciting requirements that are not satisfied by the selected package. Additionally, you can avoid higher costs when the stakeholders insist that they need the additional functionality (customization) within the software package.
There are days that I cringe in meetings. I find that using my “poker-face” requires a lot of my energy so I use it sparingly. When we are talking about the scope of a project, and I hear “well, sometimes it needs to do x and y”.
Wow – where to start!
Let’s break this down word by word.
1. Sometimes – This is an indecisive way of saying that the functionality needs to vary in some aspect. As a Business Analyst, you need to dig into the intent behind this word ASAP.
- Is there a particular business rule that would drive a change in behavior of the solution?
- Should the functionality only be available at a certain time of the day? Day of the week? Particular days of the year?
Similar words/phrases: Occasionally, In some cases, Periodically
2. It – this is the name of the pet on the Adam’s Family, NOT a word to be used in requirements. This word brings no value and all kinds of risk to your documentation. As the Business Analyst, ask some exploratory questions to resolve “it” into something substantial.
3. And – Warning bells should be sounding at this point! The words “and” and “or” are signs that you could be talking about 2 different requirements. A way to validate this is whether or not the two pieces “x and y” are separate test cases.
Hopefully that example gives you a few ideas. Here are a few of the other “ugly” words in requirements. Help build this list so together we can banish these words from requirements conversations around the world. Post your suggestions as comments and when our list grows, I’ll publish an updated, printer-friendly list.
- Including but not limited to
I could use some input. Many requirement management frameworks state that you should include out of scope and/or deferred requirements in your specifications. While I understand the nature of this direction, I find myself wondering if it sets a false expectation.
On the positive side, capturing these requirements and referencing them in your documentation provides comfort to the stakeholder who provided them that their input was not ignored. However, documenting these requirements does nothing actionable, which is why I struggle with the value of including them in the specification. It does not guarantee that the requirements will be worked in a future project. Unless someone facilitates turning those requirements into a corresponding project, we may find those same requirements still sitting in a document years later.
As an alternative, as a Business Analyst, I have typically taken any deferred requirements and worked with the stakeholder to determine if they truly warrant a project of them own. If a business case can be made, I help them get the request submitted. If the Business Analyst is not in the position to help with this step in the process, then it could end up being passed onto someone else, who fails to take action. Either way, having requirements documented offers little assurance that the work will be done, in my opinion.
If you have experiences, positive or negative, in the handling of deferred or out-of-scope requirements, let me know your thoughts.
An artistic analogy to help you understand the difference in Business, Stakeholder and Functional Requirements.
Considering what “could” go wrong when documenting requirements for a system enhancement can make life easier down the road for your systems and users.