My 5-yr old has a singularly powerful motivator: candy. So much so that my husband bought her a shirt on a recent business trip that reads “I (heart) candy.” I used to dread simple trips to the grocery store for fear of making a scene at the checkout aisle. However, I found that the key to avoiding those tantrums (mostly) was to establish and communicate reasonable boundaries, apply consistent enforcement of those and even provide an occasional reward for good behavior.
So, how are end users and stakeholders like 5-yr olds in a candy store? Their desires are almost always bigger than their budget and schedule will accommodate. A co-worker of mine was fond of saying requirements are like air because they always seem to fill the space allowed them. The reasons for this are diverse and, in some cases, legitimate. It is the responsibility of the Business Analyst (BA) to help customers understand the impact of unmanaged requirements on the project and to help them effectively prioritize them for implementation. To continue the food analogy, they need to learn the difference between appetite and hunger.
For the purposes of this post, I will focus on the “establish and communicate reasonable boundaries” portion of my approach and do so by discussing requirements prioritization within the context of a Requirements Management Plan.
Ideally, a project should have a formal Requirements Management Plan, which in-part outlines the process that will be used to prioritize requirements. However, not all projects or organizations require or will support this level of rigor. In lieu of this document, the analyst should at least discuss the process of requirements prioritization with the business in order to reach a verbal agreement.
The plan should start with an understanding of the participants. For this the BA should partner with the project manager and sponsor(s) to identify key personnel to involve in prioritization efforts. Once the team has been identified and gathered, start by agreeing on the ‘basis of prioritization’, such as: business value, technical risk, regulatory compliance or urgency. For example, business value may be proven by evaluating a given requirement against an established business case or cost benefit analysis for the project. A company implementing an online warranty renewal should have the ability to quantify the expected improvement in revenue based on providing a self-service solution for their clients. It is common for multiple criteria to be defined for a project and the list above only accounts for a few common ones.
The plan should also address the specific prioritization techniques that will be applied such as: MoSCoW, voting, budget analysis, risk analysis and more. Prioritization techniques can be either qualitative or quantitative. The revenue example above is a quantitative technique, but not all requirements may be evaluated in this way. The company implementing self-service warranty renewal may or may not be able to quantify the financial value of complying with FISMA standards, but if they sell to or contract with the federal government they understand that it is becoming an important factor to winning business. This is where qualitative techniques are applied. MoSCoW is my preferred qualitative measure, although I have also used other values such as High, Medium and Low. NOTE: Regardless of qualitative or quantitative approach, make sure all participants understand the scale and context of the ranking/rating options. When selecting a technique, take into account business considerations such as organizational maturity and readiness, availability of data for analysis, size of the project and like factors.
Finally, don’t forget to address how the project team will address conflicts within prioritization activities. Every project seems to involve at least one player with unrealistic demands and a low tolerance for negotiation so defining the rules for handling these demands is critical. One approach might be to have a pre-defined escalation path to position one person or a governing body as a tie-breaker when involved parties cannot reach consensus. Another effective approach is the “you want it, you buy it” clause. When stakeholders realize the tangible cost of implementing their wish list, they may suddenly become very rational about paring it down to reasonable scope. If all else fails, take a cue from Robert Fisher and William Ury and apply your B.A.T.N.A. or best alternative to a negotiated agreement.
After establishing the plan, the analyst is accountable to ensuring the process is clearly communicated to participants. The BA will then work with identified participants to perform the prioritization and documentation activities.
A complete and thorough requirement prioritization exercise can be worth its weight in gold down the road and, at a minimum, will hopefully help you avoid any unnecessary tantrums since the business was involved from the beginning in both the process and execution. After all, no one wants to see a team member out- perform my 5-yr old in the candy store…
 A Guide to the Business Analysis Body of Knowledgeâ (BABOKâ Guide), 2.0 ed., International Institute of Business Analysis, Toronto, Ontario, Canada, 2009, pg. 3
 “MoSCoW Method.” (2011, February 8). Retrieved February 22, 2011, from Wikipedia: The Free Encyclopedia: http://en.wikipedia.org/wiki/MoSCoW