One of the things that I feel will be consistently true throughout my life is that there are more things that I'd like to do than I will have time for. Across my personal and professional life, many of these look a lot like large projects. Whether I'm working on the next major software project for work, a website or mobile app I'm building for fun or profit, a ridiculous art project for BurningMan, some kind of home improvement activity or any thing else, the reality of limited resources (particularly my own time and the time of my collaborators) will be one of the greatest limiting factors.
I've found that in order to be effective and to actually finish projects (and finish them in a meaningful way) there are two things that I need to do:
1) Set a deadline
2) Define
exactly what will get done.
Most projects have some kind of deadline built in. For a moment, let's assume that you have a deadline intrinsic in the project, and for simplicity's sake, let's assume that there's only one (the "all-up done" deadline. (Though we all know that for complex projects that's a vast simplification)
This still leaves the question of how we define what will get done. I recently learned a framework for thinking about this problem which I have found to be incredibly clear and useful. Since learning it, I've explained it to folks on each project that I've worked on, and I've found that it has taken root, and been incredibly effective at driving clear, meaningful conversations in areas which were previously dangerously ambiguous.
This taxonomy is as follows:
P0 – These are items we will NOT ship the product without. If it comes to a decision between a P0 item and our date, our date moves. That’s the definition and bar for what a P0 item is. Clearly we cannot have more P0 cost than we have time in our schedule (simple physics). Likewise, it would be somewhat irresponsible to have the P0 cost be very close to our total time… We should have some buffer there, or we can expect our ship date to move (also physics). Ordering our P0’s relative to each other is not a super useful exercise, because we’ve already stated they’re non-negotiable. We still need to work through dependencies, and determine when things need to go in, but we’re not in the business of trading off P0’s against each other.
P1 – These are items that we would LIKE to ship with, and that we PLAN to ship, but if it comes to a decision between a P1 item and our date, the item will slip to the next release, and we will not move our date. Which items we do in this bucket will likely be the most contentious question. After pulling the P0 costing out of our schedule, there will be a relatively small block, and so there probably won’t be a lot of space in the P1 bucket. Ordering these is also important, because we will have to trade these off against each other throughout the project. As we recognize more complexity or cost in the items we’ve allocated to P0 that will naturally result in P1 items dropping off the list, and it’s important that those decisions be made in a consistent framework.
P2 – These are items that we will NOT ship this release with, but that we would LIKE to ship in the next release or two. These items should be considered from an architecture perspective during design that supports P0 and P1 items, to ensure we do not architect ourselves into a corner which makes it very HARD or EXPENSIVE to do these features later.
P3 – These are items which we do NOT plan to ship for the foreseeable future. They are captured for consistencies sake, and so that there is a clear list of non-goals. Any time one of these comes up, we can point people at the P3 item… Yup, we’ve thought about it, and we’re not doing it.
This taxonomy was proposed to me by Alex Frank, one of the architects in my group at work, and since adopting it, I've been pleasantly surprised by the amount of use I've gotten out of it. I've explained it to many people, and it's been common for them to follow up asking for the written description, and then to have them adopt it for their own projects. Given all that, it seems like a powerful set of ideas, and I figured I'd drop it here so that more folks could see it. :)
