In a perfect world, software can be created or purchased that meets all of your requirements. In the world I live in, this is frequently not the case. Often we do not have sufficient time or money to build out against all of the requirements. Likewise, we usually cannot find a software package that meets all of our requirements.
In these cases, we need to decide which requirements are the most important, and which we are willing to do without. Having a formal process for prioritization of requirements can reduce the drama of decision making after it is determined that all requirements cannot be met. Prioritizing requirements is easier when you aren’t already in the position of knowing that you have to compromise. Having a formal process and prioritizing requirements before you know whether they will be able to be satisfied is easier, because it allows the exercise to be “hypothetical”, and therefore objective. It can take some of the “politics” and turf battles out of the decision making domain, because there is less personally at stake in the hypothetical.
So if we agree that we need to prioritize our requirements, and we want to do this before we have a shortfall, how would we do it?
There are any number of possible ways but in reality, it comes down to value. How much, what kind, and who gets it. So let’s talk about a valuation process. Requirements are there because they add some kind of business value. You can’t know how much value until you know how that value is realized, or what kind of value it is.
So lets define the kinds of value you have:
1) Continuation ( I need this to stay in business, to “keep the lights on”, to survive.) These requirements are essential, but they do not have positive value, that is realized when the project is complete. They are liabilities, because not meeting them is a negative result of the project. They can be represented by a portion of the business that is lost because the requirement is not met.
2) Growth – (I need this to grow my business) These requirements are represented by the present value of future growth. While i can’t predict how much I will grow, I can project this, and I can reflect the value of the requirement as a limit on this growth – without satisfying this requirement, I can only acheive 20% of this growth (so the requirement is valued at 80% of the projected growth). Recognize that this can’t really work, because I can have 5 requirements with the same value adding up to 400% of the value of the growth, so you can normalize to the total value of the growth.
3) Cost Savings – (I need this to reduce my operational cost) These requirements are represented by the present value of future cost savings. Each requirements is tied to a valued bucket of savings, and is valued as a fraction of that savings. Without satisfying this requirements I can only save X, Normalize the same as growth requirements.
4) Risk Reduction – risk reduction requirements are realized when you don’t spend or lose money because of some problem that happened. Valuing these is difficult, because they are like an insurance policy. How do you decide how much insurance you need? How do you decide how much you should pay to cover the potential loss? If my annual losses cost millions, this is easy to value, if your losses are small, but the potential is high from a single event, then the value is more difficult to predict. But in the end, they cannot be valued at more than the business is worth. Each requirement then can be valued as a portion of the total loss that you are insuring.
Now lets talk about how to represent this value in a score:
We have a number that is the score for each requirement, we have the value types, so at the minimum, we can total each type, and represent each requirement in proportion to its value type. We must prioritize the value types. How to do this is less scientific. We can look at the total value for each type, but that may not reflect the relative priority or management’s desire. So we can adjust these. Maybe for this project, growth is the top priority. Maybe cost savings. This really is a decision, the requirements and their valuations do not tell us the answer. Decide. You must arrive at a relative weight of these value types.