Dealing with limited resources

PM Clinic: Week 22 discussion summary

Compiled: 3/31/2005

The Question:

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 met.

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
  supervise/consult.
• 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.

Contributors

Marc Colburn, Neil Enns, Matt Hummel, Steven Levy, Scott Berkun (editor)

About PM-Clinic

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 rules.