My former colleague Kate McGoey is fond of saying, “I can do anything, but I can’t do everything”. It’s true – with enough time and resources, we can develop software that does almost anything. Seriously – we’ve sent men to the moon and robots to Mars. The problem is that we don’t have unlimited time or money so we have to figure out how to allocate those resources. That’s where prioritization comes into play.
Assigning priorities is often a challenging task. Our business partners may even be confused by the need to prioritize at all. After all – they’re requirements, right? And a requirement is…well…required, right? So if I require these things, then they should be in the solution, so what’s the point in prioritizing them? It’s actually an understandable perspective. But I circle back to Kate’s comment – we usually can’t do everything, and that brings us back to the need to prioritize.
As with most projects, our CRM conversion project started with a long laundry list of requests and complaints. Our existing package hadn’t been working well for some time so the team looked at this as their chance to get everything fixed all at once. Establishing our scope helped us establish a clear focus but there was still more on our list than we had time or money to take on. We used the key “question words” to help us prioritize: WHO, WHAT, WHERE, WHEN, WHY, and HOW.
WHO Prioritizes?
Prioritization should be a team sport. No single person on a project team has all the knowledge and perspective required to establish priorities on their own. During scoping, you should have identified all your stakeholders. You will want to engage all of them in setting priorities. It’s highly unlikely that any two stakeholder communities will have the exact same priorities.
Keep in mind that you want to identify priorities for a stakeholder group or role, not a named individual. For example, on our project, I represented both instructor management and marketing. Identifying priorities for “Kathy” is not nearly as meaningful as identifying priorities for “instructor management” and “marketing”. Beyond that, turnover happens, so “Kathy” may not always be the person representing those groups. (Don’t worry – I’m not going anywhere!)
You can get a head start on understanding your stakeholders’ priorities by doing some stakeholder analysis. Our Stakeholder Analysis Template is a good tool to help you think through some key stakeholder characteristics.
Prioritize the “WHATs”
It’s so easy to start solutioning in the early stages of a project. Don’t start debating the merits of various potential solutions while prioritizing. Your session will get bogged down in details that are not needed – or helpful – at this stage. Make sure that the stories or other items you’re prioritizing describe “what” is needed, not “how” the need will be met.
WHERE Do We Prioritize?
Ideally, I like to pull people together for a group session when it’s time to set priorities. It’s true that we want to understand what’s important to each stakeholder. There is also lots of benefit to hearing others’ perspectives. We often make assumptions about what others want or need, and we can be wrong. Sometimes learning why something is important to someone else will help us be more open to raising its overall priority.
I was reminded of this when we were prioritizing things for our new CRM. I assumed that Mary, our business manager, would value having the software send out some of our post-class communication to students, like the Reflective Learning questions we send. As it turned out, that was a fairly low priority for her, particularly compared to having it create customized Class Information Sheets for our instructors. Why? Well, there’s a higher volume of the Reflective Learning questions, but the Class Information Sheets are much more complex and it’s easier to make a mistake on them. She valued reducing errors on the Class Information Sheets far more than she valued reducing the time involved in sending Reflective Learning questions.
WHEN Do We Set Priorities?
My short answer? Early and often.
I’ve always felt that traditional waterfall methodologies contributed to our prioritization challenges. Stakeholders learned that if they wanted something, they needed to define it at the beginning of the project and make it a high priority. If they didn’t, they weren’t likely to get it. Changing a requirement or its priority was frowned upon, and formal change processes made it difficult to adapt as the project progressed.
Agile approaches have definitely helped on that front. As an example, Scrum suggests that a prioritized backlog be produced at the onset of a project. It then encourages regular backlog reviews. During those reviews items can be moved higher or lower on the backlog as priorities change. This more fluid view of priorities has helped many stakeholders be more receptive to setting realistic priorities – something other than “High” or “Critical” for everything they want.
WHY Prioritize?
You’ve probably heard this one before: If everything is high priority, then nothing is. I think we all inherently believe that prioritization is needed, but here’s a great story that brought this home for me.
One of my colleagues was working with a team. Their deadline had been moved forward and they were going to have to reduce the functionality delivered in the first release of their product. They had identified 20 high priority user stories but were going to have to cut that down to 10 – 12 stories. After an extended discussion where nobody was willing to remove anything from scope, my colleague decided to end the meeting. The dialog went something like this:
Analyst: So am I hearing that you can’t choose any stories to remove from this release?
Team: Yep – we need it all – you just have to figure out how to do it.
Analyst: OK – we’re done here.
Team: (surprised silence) Ooooookay…so that’s it? You’ll get it all in the release?
Analyst: Nope. Since you all can’t choose, I’m going to go back to my desk, randomly pick 10 stories, and that’s what you’re going to get in the next release.
According to him, it was amazing how quickly they decided that they’d rather make the choices themselves.
It’s possible that everything on a given project is really important. But unless we can get some idea of the relative importance of each item, there is no way to make intelligent choices when we don’t have the resources to do absolutely everything.
HOW To Prioritize?
I think my colleague in the story from above made a classic mistake. Trying to prioritize through discussion alone almost never works. I have been in meetings that drug on for hours without reaching a resolution. Or worse – people finally give in and come to an agreement, but at the next session, they reopen the conversation because they haven’t truly bought in to the agreement.
My colleague Ali gave some great options in her recent blog 6 Prioritization Techniques for Yielding Value. These approaches introduce objectivity into prioritization, leading to faster results and higher buy-in from your stakeholders.
Ask ALL these questions!!
Remember to use all the question words to help you prioritize – who, what, where, when, why, and how. Prioritization is hard but necessary. You’ll be a hero if you can help your team do it quickly and effectively!
Kathy Claycomb
Managing Partner, Lead Expert
Kathy Claycomb brings over 35 years of experience to the classroom. She has participated in all phases of solution development using everything from agile to waterfall methodologies (and quite a few in between). Before joining B2T, her career spanned roles from application developer to Senior Director of Services at various organizations. Kathy has broad industry background including transportation, manufacturing, insurance, energy, healthcare, and banking.
Kathy’s first love is teaching, and throughout her career she has always managed to spend a portion of her time instructing. She has an engaging, highly interactive teaching style that ensures students leave the course with a thorough grasp of the material. Her students consistently praise her teaching abilities and her talent for drawing on her personal experience to enhance their learning.
Kathy served as the Technical Editor for Business Analysis for Dummies, 2nd Edition.
