Hi: There are two different attributes: Project Priority and Priority. We have four different priorities. We couldn’t come to an agreement of what the difference between an “Urgent” and a “High” priority was. We couldn’t really agree what a “Low” priority was. Given all of the “High” priority projects, giving a project a “Low” priority was the death knell for that project. Some companies have the philosophy that you should ONLY work on the highest priority projects. There is another view that says you should spend 75% of your time on high priority projects, 15% on medium priority, and 10% of your time on low priorities. If you don’t balance the work, everyone will claim their work is high priority, because no one will ever work on medium or low priority. Then, your prioritization scheme means nothing when everything is a high priority. In the end, we ignore the priority because we have no consensus on what each priority really means. Instead, we use the Project Priority. We’ve only gained a consensus on what a Project 1 project is. It is left to the Portfolio managers to determine what a 2, 3, 4, etc. means. We do have some support / BAU plans that model ongoing work. I make those priority 99. In other companies I’ve worked in, we had a consensus on what each priority means. Yes, we changed the priority of some projects weekly or monthly as a result of sitting in portfolio management meetings where the business changed what was important to them. A project didn’t change priority just because the go live was near. It changed priority based on the urgency of getting the functionality or work product we were going to deliver. For example, if a customer would close more business if we have certain functionality, the project to deliver that functionality would definitely creep up in the priority. Potential to generate incremental revenue was a factor in prioritization in those companies. I think it is reasonable to have a conversation about a portfolio of projects, decide what work products are most urgent, and prioritize accordingly. Beware of people who will exhibit flexibility on the definitions of each priority. There are people who will try to game the process to get their pet project bubbled up to the top of the priority list. They will insist there is a nebulous quality to the prioritization scheme, or reject the scheme outright, and then proceed to argue why their projects are most important. Pinning down exactly what each priority means - and quantify it so that you can essentially calculate the priority - reduces the ability to game the system. Above all, do not base the project priority on emotions, like, well, the CMO really wants this deliverable, we should bump up the priority. Priority has nothing to do with personal choices and the rank of the person with those preferences. Priority has to do with delivering the most important value to your customer first, your company second, individuals and personal agendas fifth or sixth. The worst prioritization scheme is based on who is the biggest bully in the prioritization meeting, who claims asteroids will come out of the sky and destroy life as we know it if his personal-favorite-project isn’t called “The Most Significant and Critical Project in the History of the Company”. Such people will say that their project is Priority Zero - to be queued ahead of all of those insignificant Priority One projects. The Bully Method is bad. So is the Passive Aggressive Method - someone sits quietly in the prioritization meeting and mumbles about yeah, sure, let’s do it that way, okay, fine, and then after the meeting really puts the pressure on the portfolio manager in a 1:1 meeting to change the prioritization. They know their bullying wouldn’t work in the meeting, so they wait for a chance to corner the Portfolio Manager after the meeting and influence the prioritization. Hey, come up with a quantified prioritization scheme and you’ll minimize the turmoil. More than you asked for ☺ Thanks! Eric
