The Value-Complexity Matrix
I like to think of projects as a journey from the abstract to the concrete. Here's a simple path:
Do business strategy / user research
|
Make a list of features
|
Create features
|
Code features
Somewhere in that "list of features' step is a big transition from mushy research to getting down to work. Once I know what the features are, the list is prioritized.
The feature prioritization is based on the user research and the business strategy, along with the initial technology estimates. I like doing this prioritization exercise in person with all the stakeholders so all viewpoints can be factored in. It's a seminal meeting and the results guide the rest of the project.
I like to take each feature and assign it values according to risks and rewards, or complexity and value...the terms may change in each project (MBAs and project managers probably know the proper name for this chart). If you put the terms on a matrix, with x and y axes, you get a visual picture, like so:
This is how I interpret each quadrant:
- High Complexity / High Value: It's important to include these features, and because they're hard let's address them first so we have enough time and find any unknown snags.
- High Complexity / Low Value: They're hard and no one thinks they're important, so try to leave them out.
- Low Complexity / High Value: Definitely include these, but give them lower priority.
- Low Complexity / Low Value: These features can be put on a reach list, to do if resources permit. Or left until a future phase. Or you can re-examine them to see if your original values are accurate.
Throughout the project, especially if things are going off course, I can refer back to this and make sure the reality of how we're devoting our resources fits the plan.
Of course, risk/reward analysis goes on throughout a project in big and small ways. It happens in questions like 'Which markets do we target?', 'Which audiences do we leave out?', 'What is the page weight limit?', and 'Should we use DHTML?'