since i work in a software organization that subscribes to the
capability maturity model

, i’m always interested in exploring how to balance the demands from the various stakeholders involved in software development.

that’s why i was happy to see

initiate a
great thread

on the “politics of design”:

“The politics of technology design are examined in the context of software design where there has been an emphasis on “user participation” as a solution to poor software design. However, in examining the realpolitik of design, our research shows that the process must be situated in an organizational and market context. Thus, traditional concepts of user participation tend to be limited and need to be expanded to incorporate a broader organizational model of how technology and work are structured. .”


links to a
complimentary perspective

that details the
role of project management in design


“In summary, I think one key to success is to enable a very small set of folks to drive the design thinking. I would much rather have one product designer that has medium proficiency in information design, visual design, and interaction design, than three individuals each contributing only those independent perspectives. You want a small number of people to be able to go and iterate quickly, trying out lots of ideas without hoops, bureaucracy or design by committee, but balanced by input or contributions from all of the disciplines you need.”

to round out this incomplete “thought”, it’s instructive to compare the above perspective with that presented in a new book from luminary
ed yourdon

[ who, apparently just started a

] which has the hyperbolic title,
managing high-intensity internet projects

. despite the title, he does articulate a pragmatic approach to developing “internet projects” which attempts to balance many of the conflicting tensions. unfortunately, the book relegates usability issues to a small paragraph in the chapter on testing that ends with the obvious recommendation that it’s in everyone’s best interest to start testing as soon as possible, rather than waiting for when the coding activity has been completed. nice thought, but skimpy the details.

hi. ho.

Leave a Reply