In a recent article about requirements gathering, I pointed out that you shouldn’t get too hung up on the priority of the requirements or tasks you have in front of you. In this article, I want to expand on that concept and offer a different priority paradigm that takes the stress and senseless nitpicking out of the project planning process. It also helps you avoid the "analysis paralysis" that is so common in business projects.
My contention is that assigning tasks a numerical priority is basically a waste of time.
I’m sure you’ve seen this situation before: You are asked to attend a meeting with management to discuss future plans for Project X. At that meeting, you have several business stakeholders around the table, and each person has his or her own agenda. Your job is to keep track of all the requirements for Project X and prioritize them according to how important the stakeholders think they are. By the end of the meeting, you have a laundry list of items that are prioritized from 1 to 5 and you are expected to come up with an estimate for what it will take to accomplish each item.
At the next meeting, everyone gets together again to consider your estimates and review the priorities. In the meantime, several things have happened:
- New stakeholders have shown up at the meeting, and they have different ideas on how the items should be prioritized.
- Several stakeholders have conceived new requirements, some of which are seen as higher priority than anything previously on your list.
- You point out that some of the smaller, lower-priority items would be much more efficiently accomplished in combination with one or more of the higher-priority items. The stakeholders agree to "bundle in" those items, even though they aren’t a high priority.
- Your estimate for certain items raises eyebrows around the table, so the stakeholders decide to "save those items for later" even though they are still a high priority.
This approach to priority often produces a lot of dissention over what is essentially a meaningless distinction between the items on your requirements list. None of the political and mental anguish has solved the primary problem, which is to clearly identify everything that needs to go into the next (or first) release of the project.
When I experienced these meetings myself in the corporate environment, I walked away from the meeting confused and frustrated. I eventually figured out a better way to deal with prioritization. I call it the "This Release" theory of prioritization.
This Release in Practice
The technique for implementing This Release is very simple. When you sit down with stakeholders to discuss the project requirements list, all you ask them to do is identify each item that should be included in the current release of the project under development. That’s it.
Your requirements list now consists of two basic priorities:
- This Release
- Not Scheduled
Any further breakdown is useless for several reasons:
- Prioritizing assumes that nothing changes over time, which is obviously not true. Over time, the business environment changes, so the requirements change. Old requirements fall off the list entirely, and new, critical priorities are added.
- As each release goes out, you learn things you didn’t know before. Some of these things have a big impact on the importance of certain items on your Not Scheduled requirements list.
- As I mentioned before, it is often worthwhile to bundle several small requirements with one large requirement if they affect the same area of the project.
Convincing Stakeholders
Unfortunately, numerical prioritization is hard-wired into the brains of most stakeholders. It usually takes a bit of convincing to get them to adopt the This Release philosophy. Expect a few blank stares when you ask them to commit to a decision on what items should go into this release. It takes them a while to figure out how they can still flex their political muscle and agonize over business benefit in such a limited "just make a decision right now" environment.
In my experience, it helps to assign every project release a number. Don’t confuse stakeholders with a complex, multi-part version number as is common to IT software applications. Keep it simple. Start at Release 1 and increment by one for every release. For project planning purposes, it is irrelevant if the release is just a bug fix release or if it is a full feature release. Let the developers worry about how to number the application files if they need a finer distinction.
Also, don’t let the stakeholders talk about what goes into the next release or the one after. That is just their attempt at reintroducing a numbered priority. Those discussions are just as useless as assigning a priority number, and for all the same reasons.
Achieving Mental Clarity
A side-effect of This Release prioritizing is that everyone involved walks away clearly understanding when a requirement will be addressed. Every item is either in the current release, or it isn’t scheduled for release yet.
Stakeholders no longer walk away under the illusion that a high priority number means they will probably get what they want eventually. They must either fight to get what they want right now, or face the reality that there’s no telling when they will get it.
Meanwhile, you walk away with a smile on your face because you actually know what you need to get done for a change.
The This Release philosophy works in your personal life as well as in your professional life. When you have a pile of tasks in front of you, you can agonize all you want over how to prioritize them, or you can simply pick the one that matters the most to you and just do it. Around here, we call it the Pick One approach to getting things done, and it works very well.
