SIGIA-L Mail Archives: SV: Real life examples - Was: SIGIA-L: w
SV: Real life examples - Was: SIGIA-L: www.ia<whatever>.org
From: Gunnar Langemark (gunnar.langemark_at_valtech.dk)
Date: Thu May 03 2001 - 05:31:42 EDT
Thank you for your reply Anne.
I can see that we do not agree on the useful-ness of sharing examples.
> 1 - My employer will not allow this, for the very good reason that...
> 2 - these deliverables are trade secrets.
That was my first concern. However some examples may not be problematic in
> 3 - shouldn't we be talking about process, not necessarily
IMO one doesn't preclude the other. The examples of deliverables would work
as a point of departure for discussions about the work process. It would be
at a more informed level - since I sense that we are not always talking
about the same thing. In this group there is a lot of effort being put into
explaining in words what could be shown in visuals.
> It seems to me that the IA process is a stable entity, not
> changing across
> projects or organizations.
That may be so in your organisation. If You are content with status quo in
your organization You don't need to take part in this.
> Deliverables and timelines are necessarily
> flexible, since every project is different.
I believe that also the process kan change according to the nature of the
customer, the project, the technology and so on.
For example: If you work on a larger content management based system there
will be more emphasis on defining the elements of possible content. If you
work on a 're-launch' of existing content the emphasis will be on
reorganising rather than on innovation.
> Seems to me that the point of sharing deliverables has been to
> reverse-engineer a process from them. Is there a way to just
> address the
> process itself? And shouldn't any centralized site for IA
> work towards this,
> instead of acting as a deliverables bank?
Your point is good - but I interpret this differently. I believe that
talking process without any concrete deliverables is too academic - and will
generate a lot of noise in the form of discussions of definitions of terms
In my experience a 'map' can be a 'hierachical content map', a 'navigational
structure', a set of 'functions' or 'use cases' and probably much more. A
lot of misunderstanding happens when the maps go out in the organisation -
and there is nobody around to explain them. I would like to know more about
how others convey the needed information in ways that are easier to
understand for those of the users who are not information architects.
List archives are available at:
To subscribe or unsubscribe, send mail to majordomo_at_asis.org with the
appropriate command from the list below in the body of the message:
This archive was generated by hypermail 2.1.2
: Sun Nov 23 2003 - 22:54:38 EST