Dealing with limited resources
PM Clinic: Week 22 discussion summary
We're in the specification phase for our next release, and the ratio of Product designers
(UI designers) to PMs has dropped significantly from our last release. If we use the
same process we've used in the past (i.e. Design is in on all the feature teams, PMs
work with Designers directly for ui design, etc.) we'll overwhelm the design team and
we won't get the right work done.
So, we need some kind of plan/process through which to prioritize features, assign
resources according to priority, and manage the list when things come up that require
shifting previous priorities. Or something like that. Whatever process we use, we want
Design & PM to be bought in to the plan and both parties feel like their needs are being
I'd love to hear suggestions for models that have worked for you in the past when Design
(or any partner team for that matter) was short on resources and a more formal process
was necessary to keep the release moving and people properly focused and un-frustrated.
- A designer, a designer, my kingdom for a designer
How to prioritize anything:
- One way to look at this situation is about priorities. If there aren't enough designers
to cover the work, prioritize the work and assign designers to the most important
work items / features.
- For areas that can't be covered, find team leads or programmers that have some design
skill and assign them as appropriate.
- For areas that still can't be covered consider: hiring contractors, cutting the
work, or postponing those features until resources can be found.
Levels of service:
- One model is to look at any resource (programmers, testers, designers) as a service
to the team. If you're a service, you can provide different service levels.
- Level 1: Platinum - we will drive the design of the entire area.
- Level 2: Gold, we will drive the concepts and core ideas of the design, but will
then hand off many decisions to the engineering team, and
- Level 3:Silver, we will supervise and consult, but can't drive anything.
- Level 4: Dirt. We will ignore you and make silly faces at you when you're not looking.
- Get all of the influential people thinking in this way and tie each service level
to an amount of designer. "Oh, you want level 1 service? We need another designer
to provide that to you."
It's really about quality:
- If you are told to do work without the proper resources you're really being told
to drop quality. If you need 5 designers but only have 2, the real result will be
that quality of the work will drop.
- If you want to make arguments to management about resources talk about quality.
Don't just ask for more people, ask what level of quality they want the work to be
done at. Arguments about quality are more likely to result in more resources than
arguments about resources.
Guidelines and templates:
- With some kinds of design work a good designer can make templates and guidelines
that others can re-use. This will at least achieve some consistency across all the
work and provide answers to some of the basic questions programmers will have.
- In some ways this helps the team in the future: it puts some basic design skills
in the hands of the individuals doing the work. If you expect to face similar problems
in the future it's in your interest to start teaching people the basics now.
Schedules and quality:
- Another approach is to redesign the scheduling process to focus on quality and delivery.
Instead of dropping quality when resources are low, each schedule milestone should
be framed around the available resources. If there are only resources for 3 weeks
of quality work, then that should be what the team schedules for and delivers to.
If it's done right these short milestones will trade low quality for high, and give
more frequent deliveries to customers. The downside is that it may take longer for
all features to be built, but the making the delivery incremental with high quality
might be worth the tradeoff.
Marc Colburn, Neil Enns, Matt Hummel, Steven Levy, Scott Berkun (editor)
The pm-clinic is a friendly, wise, open forum for discussing how
to lead and manage teams of people. Each week a new situation is sent to the list and
we share advice, ideas and stories. Anyone can join as long as they follow the simple