PM Clinic: Week 16 Summary
Topic: The battle over design authority
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
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.
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.
Faisal N. Jawdat, Chris Beiter, Neil Enns, Dave Heller, Trena Roush, Andrew Stellman,
Scott Berkun (editor dude)