Re: A failure to communicate...

I'd like to address Anu's comments (snipped below) and try to make more
clear how I'm trying to make effective communications a UCD selling point.

> I'm liking this thread very much, although I'm not sure that
> it's really a UCD thing - effective presentation and
> communication of specifications / artefacts is vital whatever
> methodology you're using, so I'm not entirely sure how this
> becomes a UCD selling point.

As others have also noted, effective communication between all parties on a
project is important (vital!) no matter what method.  I agree. I also think
experience and studies bear out that effective communication between all
parties on a project is hard to achieve.  Particularly for IT/software
projects (although I don't think it's unique) because you often have
highly-trained techies talking to non-technical users/clients/business folk
and the difference in their abilities to understand each other are often
great.

So, into the breach might step the UCD professional who is good at talking
both languages.  They are trained/experienced at working with users and
understanding how their needs might be translated into a software program.
They should also be trained/experienced at working with software developers
and understanding how the "optimal" design for the users might need to be
modified in light of engineering constraints.

Well, why the UCD folks as the "gap-bridgers" and not the PM or BA or
whomever else?  My simple chain of logic goes thusly (and trust me, any
logic I possess is going to be simple/simplistic):

1. Lack of user involvement and difficulty achieving clear communication
about requirements are the two primary symptoms often noted for project
failure.
2. Software projects usually involve users and developers.
3. UCD professionals are experts at involving users.
4. UCD professionals can communicate with developers.
5. UCD professionals can therefore help you involve users and achieve
clarity about requirements.
6. UCD practices and artifacts are the tools UCD professionals use, so if
you're bringing in UCD professionals you're bringing in these practices and
artifacts.

My simple (I hope) analogy, which is not origial, is that of hiring an
architect to help you design/build a house.

You could just go to your local day laborer center and get a bunch of guys
who have built houses before, take them to your homesite, and tell them
"build me a house with 4 bedrooms and 3 baths, etc. You guys have done this
before, I want to see construction start soon."

Nobody does this, and for obvious reasons. You hire an architect to take
your ideas about what you need, work with you to refine them and turn them
into sketches, elevations and eventually blueprints.  Along the way the
architect uses their experience and consults with engineers when needed to
make sure the design is buildable within time/budget/etc constraints.

Once all the engineering plans are done, the general contractor is hired to
find all the construction folks to follow the plans and build the house.
The architect is there along the way to ensure the design is actually being
followed and may again work with the client and contractor to help
mediate/negotiate any changes that may need to be made if unforeseen
problems arise while trying to "implement" the design at the chosen site.

The architect plays a valuable role in acting as intermediary between the
"non-technical" client and the engineering/construction trade. I think UCD
professionals have a similar role to play in software/IT projects by virtue
of training/experience/interest.

RL

    --------------------------------------------------------------
     POSTINGS (in plain text): [email protected]
           SUBSCRIPTION CHANGES:  http://lists.syntagm.co.uk
            (or send email to mailto:[email protected])
    --------------------------------------------------------------