PM Clinic: Week 16 Summary

Topic: The battle over design authority

Compiled: 2/21/2005

The Situation:

I'm a sole project manager on a team on 5 programmers, 3 testers and a handful of other specialists (documentation, localization, etc.). We have decent processes in place for most of the basics, and generally get along and work together well. However the machete sized thorn in all of our sides is design. When it comes to figuring out what the features are, and how the work, it's a no holds barred full on WWF slamfest. We argue, we fight, we get frustrated, and struggle over various kinds of design decisions. Sometimes the arguments are over UI design, sometimes about high level programming choices (object models/APIs, not implementation), and sometimes it's even over the requirements themselves. In our org, it's not uncommon for execs and manager types to jump in on some of these debates as well (aka battle royale).

So my question is: What should the role of a project manager be in leading design choices? Should PMs lean towards tracking/supporting projects, or should they be leading them? And if they are to lead, how much involvement should they have in the design of the software/website itself?

- Tired of the fighting over design, Boston, MA

Advice

There was some disagreement as to how far a project manager should go in fulfilling any specific activity. Some felt it's ok for PMs to drive design (in the broadest sense), since there's a natural focal point for all of the decisions and managing that follow. Others felt the real obligation of a good project manager is to make sure the decision making process is clear, and that it serves the best interests of the project. Even if Fred, the PM, is a good object modeler, odds are good the best use of his time will be spent doing something other than object modeling.

I thought Tim nailed this issue with this point: "the responsibility of a PM is to classify & re-enforce which **role** takes the lead in resolving which issue. Others can advise, but this person disposes." In part this implies that for any given decision there might be a different person best suited to make the final call. If the PM manages this right, the power struggles fade, as power shifts around the team organically, based on the situation at hand.

Faisal pointed out that these struggles are heavily personality dependent - to deal with them (the struggles) requires someone observant enough to understand how to talk or respond to the key people, and tactful enough to take action without making things worse. A rule or a process will only go so far - someone has to be savvy and experienced in working successfully with people of different personality types.

There was a side discussion about the role of designers, particularly UI designers, in the process. The key points from it were (note, this is probably not entirely objective as I was one of the main debaters in the discussion): design culture is often different than engineering culture, and mismatches can often occur. Design (as a job/role) should be a first order player in design related decision making, and for projects where ease of use or other design attributes are goals, someone trained in that kind of design should be involved.

References

IBM dealt with these issues awhile ago, and documented their conclusions. The focus here is on user interface design, but it's not hard to imagine extending this to include roles for development, test, marketing, etc.

www.NextD.org - A group advocating cross functional design.

Contributors

Faisal N. Jawdat, Chris Beiter, Neil Enns, Dave Heller, Trena Roush, Andrew Stellman, Scott Berkun (editor dude)