So, you have your SWOT and your fishbone, now you need to prioritise your requirements.

There are lots of ways of doing this, but I think you’ll have gathered from my previous posts that I’m always keen to do things the simplest way possible and refine things from there.

1. Take all your requirements from the end points on your fishbone, and write them all down on post-it notes.
2. Hold a couple of rapid, 15-minute sessions with business stakeholders and ask them to stick the requirements to a flipchart sheet, with the most important at the top and the least important at the bottom, so you end up with a kind of requirements priority ladder.
3. Hold a follow-up session with the technical stakeholders who will need to deliver the project: designers, developers, project manager. Don’t tell them that the requirements are prioritised by importance (although they’ll probably guess). Just ask them to review the requirements and move them further to the right of your sheet depending on how time-consuming or difficult they are to achieve.
4. Draw a 2 x 2 grid around the post-it notes. The 2 x 2 grid is a business analyst’s cliché, but also a friend. The vertical axis is benefit and the horizontal axis is difficulty. You’ll end up with a PICK chart, shown below.

You should just implement the requirements in the top left of the grid. They’ll bring value and are relatively easy to do, so they should be in your project scope right away. Conversely, those in the bottom right should be scrapped as their value is questionable and they’re hard to do, so the business case will never be proven.

Requirements in the bottom left grid should be challenged. Just because we can do them, doesn’t mean that we should. What real benefit will there be for the organisation if we implement them? Won’t they just divert our focus from our main project objectives?

We may well implement requirements in the top right of the grid, however. We know from the outset that their implementation will be difficult and costly, but if we can prove their benefit then we shouldn’t rule them out. These requirements may involve some prototyping and benchmarking, but shouldn’t be excluded just because they’re hard to do.
If there are lots of requirements in the Possible group, you can always repeat the exercise just for those requirements and include only those in the top left. You should also retain a record of those requirements that were in the Kill group, as in future there may be more value in doing them and they may be easier to implement with changes to work practices or evolving technologies.

The advantage of the approach articulated in this and the previous two posts is that it’s relatively quick and simple, while retaining a focus on real problems and how likely you are to be able to solve them. Obviously, there are more refined approaches than this, but if you just need to get things done, this approach is worth trying.