Sal, you say this: users should “respect the development team’s expertise, and believe their requests aren’t going completely unheeded,” right?

Try this. (This is just the very first example that occurs to me, BTW.) Go to this site: http://www.sonyadtv.com/index_e.html

If you were a user of this site, why in the world would you respect the development team, when that team obviously showed little respect for the user? As for “unheeded,” well, we might say that not only were the users unheeded, they were ignored. (Usability testing was performed on this site, and the results discarded as being politically inconvenient.)

Users are human beings, as I never tire of reminding people, and are therefore subject to all kinds of human foibles – including the occasional inability to put their requests in language that developers will readily understand. But this in no way justifies lecturing them that Father Knows Best.

He doesn’t, all too often.

Have I misunderstood you?

The main ingredents of my article were communication and collaboration. Im calling for everyone to work together to make sure these types of applications arent built in the first place.

Im sure there are plenty of examples of this process gone wrong; bad web sites, unused intranet modules, et cetera. Im calling for a solid development process where each component (not just the users) know their place and what’s called for in that place. Development shouldnt run amok thinking they know whats best for the user, and the users shouldnt clam up thinking ‘the developers will do what they please so why should we even say anything?’

The expertise I meant users should respect is in respect to technological development of the application; it was not meant as a pat on the user’s head by the developers saying: We know what to do, trust us. I can understand how it might have been construed that way, but it was not my intention.

Most importantly, this was not meant as a lecture to any side of the cycle. It was a call to work together as efficiently as possible.

Again, thanks for the comments and I hope Cecilia (and others) are getting a better understanding of where this article is going.

.sal

I still don’t understand how you get users into your communications. They are not at the work place. How do they even know development is occuring? How can they get their feedback to the developers, if you are not using the observation techniques I have seen in the usability expert books? Or does the project manager inform them and collect their input? How do you deal with “self-reporting” issues?

If users are completely unavailable, a higher level of interpretation is needed; if its an internal project and project management/development is on-site, it should be easier to get feedback.

.sal

The requirements-gathering responsibilities in your article which the PM and users are to shoulder look to me just like what good analysts or designers are supposed to do. Would you consider the role of analyst/designer to possibly be a missing role in your list of PM/developer/user? It’s been my experience that a good PM and a good requirements analyst are not the same person.

You can always argue for more interaction and/or tiers in the design process. My intention was not to discount added levels or specific expertise in the ladder; rather to focus on the minimum requirements.

I imagine most medium-sized organizations dont have budgets for requirements analysts, so I didnt get into too much specialized detail.

You raise an excellent point, though. Thank you for the comments.

As an information architect/project manager for a major retailer’s e-commerce team, I am constantly striking a balance between business requirements and technical requirements. The challenge is to identify, and then to *reiterate* in a meaningful way, the business requirements, and then connect them to the technical requirements (IA is part of technical reqs in my case).

The key to this is to communicate back to the user/business partner what you have heard them asking for and *not* asking for. A couple of conversations like this will usually result in a bunch of requirements that were never articulated in the first pass. Then, of course, there is the negotiation phase – i.e., do you want all of these features, or do you want it by the original date?

In the end, the more conversations you have with users early on, the less likely you are to find out late in the process that something critical has been overlooked.

Lisa,
This is exactly my point. As the article title says: ‘Effective Project Communication’ is what’s needed, and often overlooked.

Thanks for posting.

.sal

However, I think Mr. Palmisano confuses how to work and communicate with users (and customers) versus how to do so with clients. Assigning responsibilities to clients is appropriate, assigning them to users or customers is irresponsible.

Of course, in software and web development, irresponsibility is all too common. I doubt if there is anyone who wouldn’t benefit from following Mr. Palmisano’s advice.

I completely understand working with clients is often very different from working with user/customers. However, the main ‘responsibility’ of the article was communication in a variety of forms. I do not advocate assigning users tasks which will detract from their everyday workload, rather, those users expected to communicate their needs should know how to do so properly and effectively.

Indeed assigning tasks to customers, in almost any form, is a risk at best and should be left to a comments or feedback format.

Again, thank you for your comments.

.sal