Requirements and establishing priorities

We're starting a small project for a new client, and of course, we're gathering the requirements for their solution before we dive into designing and developing it.

Of course, clients start off with a grand vision of what their new software will be able to do for them, and then they say they want all that for a limited budget, and can we have it done next week?  The overlying principle in any project is that there are really three main constraints: time, money, and quality. The scope of the project must fit into the triangle formed by those three constraints.

So, Joel got us started a couple of years ago on a great way to help clients identify the priorities for the requirements they have given us. When we arrive at a list of requirements, we then assess them in four areas:

• Benefit - the relative benefit of having this feature or requirement in the final solution
• Penalty - the relative penalty of not having this feature in the final solution
• Cost (or complexity)  - the relative cost of implementing this feature
• Risk - how much you don't know about implementing the feature

We use a spreadsheet, and assign values 1 to 9 for each of these columns, next to the requirement itself. A benefit of 9 means that it is high benefit to include this feature, a penalty of 9 means that it would be really bad if we didn't include this feature, a cost of 9 meant it would be really complex or time-consuming to implement this feature, and a risk of 9 meant we didn't know how well the feature could be implemented.

To come up with a ranking of each feature, we use a Priority column which simply totals up each of the four B, P, C, and R factors, and then we sort descending on the priority column (this works great in Sharepoint too). Sometimes we will weight the factors by multiplying each of the factors by a percentage (35% B, 35% P, 15% C, 15% R) but it usually works out about the same.

Now we have a list of features/requirements that have the most important ones at the top, the least important at the bottom (note that you may have to account for dependencies between requirements as well as the priority). We can apply "scope" to the list and cut off the bottom stuff according to the amount of time or budget we have (assuming you don't want to cut quality).

It works pretty nicely.

I recently used it at a company where we were involved in a SEPI project (Software Engineering Process Improvement) and they found it a really useful exercise. I was able to develop an iteration plan for the construction phase based on implementing the features in the priority order. The early iterations were the hardest, most time-consuming ones, and, frankly, some parts of some of the early features spilled into the next iteration. But our last two iterations had the trivial stuff scheduled in it, so we were able to make up the slack easily. We also had early releases of the most critical pieces, and were able to adapt to some of the changes that were identified by the early adopters. If we had scheduled it otherwise, we would not have made the deadline. We did end up dropping some of the lowest priority features, but no one cared - success criteria were based on the highest priority features, not the lowest "nice to haves".