Some people may yawn at the thought of having to manage and prioritize a set of projects. But if you have a vision and goals for your organization and your team (and you should), then determining priorities – determining who works on what – is a highly charged and motivated activity. Every effective user experience team manager should have a solid system in place to allow for repeatable, predictable project prioritization and resource allocation.
Here’s a set of steps you can take to get control over your list of projects:
1 Hold a regular project queue meeting
Invite your key staff – discipline leads, senior folks. If your team is dealing with new project requests every week, meet weekly. Split the meeting in three: new project requests, in-flight project issues, closing projects. Project prioritization tends to happen in the “new project requests” part, on which the rest of the steps focus.
2 Maintain a project queue
Of course! But the key word here is “maintain”. It’s not easy to keep a queue current. Holding a regular queue meeting helps. As new requests come in, get them into the project queue for “processing” at your next project queue meeting. When you have a queue document, publish it, make sure everyone on the team has access, and did I mention keep it current?
3 What’s the priority? – Use a project priority scoring system
If you’re getting more requests than your team can handle, you need to have a systematic way of determining what you work on and what you can say no to. You have a vision for your team. You have goals. Create a scoring system that uses those goals to evaluate every project request and come up with a priority score.
4 What’s the effort? – Use a simple sizing system
Determining priority is one thing. Determining the effort required is another. That’s right. Effort is separate from priority. Sizing the effort to complete a project is not easy, and comes with experience, but that doesn’t mean you can’t have a system that uses consistent criteria to determine the hours of designer or researcher time required to get the job done.
5 Who can work on it? – Track the capacity of your team
If you’re allocating team members to projects, you need to know how many human-hours you have to work with? In one quarter, a team member may have something like 700 hours available to work on projects. If you’ve been estimating the size of projects, you have an idea of how many hours have been allocated and what’s left.
6 Draw the line
Now you have a project queue, priority scores for each, sizings for each, and number of hours to allocate. Sort your projects by priority, and start allocating team members to projects based on hours available. When time runs out, you draw the line.
Download: Project queue tool
About
Being somewhat of a hybrid between a user experience designer and a developer, I thought I’d chime in with how similar these guidelines are to an implementation of Scrum. Scrum is a framework for agile development (although I’d say it can be used for more than software development – the japanese industry uses it for optimizing car manufactoring processes) that also advocates maintaining a product “backlog”, which is exactly what you’re describing.
Our company is small which makes it easy to implement this kind of methodology, so in the last few projects, we’ve been perfecting the processes maintaining the backlog and estimating time. This is because I believe that nailing down time estimates and keeping the list / backlog updated are the two critical pieces for the framework itself to do well.
Here’s some of the things we keep for each entry in the queue / backlog:
- ID – A unique identifier for each of the entries, for quick reference. It’s good to have something to look for apart from the description.
- Description – A description of the unique feature on the list. In the case of software development this might be something like “Add a form to allow people to comment video entries” on a video website.
- Priority order – The order in which this should be built if we were to organize it by business value * team availability. This is also how we sort the list.
- Estimate – An estimate of how long in terms of man-days (one man working one day) something would take. Example: 4 man days means that 1 person would take 4 optimal days implementing this feature.
- Test spec – How to test that the feature was correctly implemented. When you wrap up a feature and mark it as “done”, the steps outlined in this test spec should be used to validate the solution.
- Discussion – A discussion/note area where details about the particular feature go. This is obviously optional, but we find that it is a great place for clarifications.
There’s a lot more I could mention about how we do prioritization or how to select a combination of “features” or backlog items to work on a sprint, but it is probably material for more in-depth posts about queues.
PS: Love the idea of this blog, I hope I can contribute more and more often with comments. Hope this one helped.