Re: Information Architects; was: Re: job title nomenclature on biz cards

Subject: Re: Information Architects; was: Re: job title nomenclature on biz cards
From: eric -dot- dunn -at- ca -dot- transport -dot- bombardier -dot- com
To: "TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com>
Date: Tue, 24 Aug 2004 10:18:34 -0400


I generally agree with Gene's observations on the possible paths to
failure in implementing any type of CMS/KMS

"Gene Kim-Eng" <techwr -at- genek -dot- com> wrote on 08/21/2004 02:03:35 PM:
> To truly capture and manage your organization's total
> knowledge, you need to pull in content that often doesn't
> get into technical documents, such as design specs, marketing
> collateral, manufacturing and test instructions, service and
> support records, etc.

Certainly. But you do have to start somewhere. Big, never ending,
cross-department, politically hobbled efforts to produce a 'complete'
system from the get-go are virtually doomed to failure from the start.
It's unlikely you'll progress to the stage of trying to get the unwashed
hordes in the company using it.

Start small. Classify, store, and ease the retrieval of one department's
or even one small group's deliverables. Then, expand the system to store
and classify the required support documentation. But, in these stages, do
not require others to populate the system. Allow the company and other
departments to continue 'business as usual'. However, create a document
retrieval interface that is easy to use and direct all people making
document inquiries to the system.

The big hurdle to overcome is the unavoidable declaration of management
that organising engineering docs is engineering's problem. The sales pitch
is to show that techpubs has to do the job anyway and that you need the
system internally. If you have to get documents from various
departments/groups and already need to track revisions and integration, it
should be easy to show the savings in time and effort and how the system
will standardise the process and lead to increased quality/accuracy or the
documents.

There are probably a million different ways to start such a system. But,
one approach that I'm toying with is MyDMS (
http://dms.markuswestphal.de/about.html) linked to a comments/bugtracking
database. With such a system, revisions, communication between the
departments, questions and comments, as well a approval of documents could
be tracked.

> The moment you tell your engineers, manufacturing, marketing,
> field service, etc. people) that they're going to be
> expected to "adjust" to the CMS/KMS by learning to use
> new tools and formats, you have doomed it to ultimate failure.

Exactly. I couldn't agree more. That's why you begin by making a system
that meets your departments needs first and which your department is
totally responsible for. Then you start to get sneaky...

As documentation requests are directed to the CMS/KMS system, people will
start going there naturally. Eventually, some may even start using it as
there primary source of information (as it will be easier for an engineer
to find a design doc than leaf through binders, search servers, or hunt
for the person who has them squirrelled away).

At this stage, others may begin alerting you to changes instead of you
having to continuously hunt and monitor for revisions.

To then up the ante, you need to look at how other departments work. How
do they store and classify their documents? What reports do they need to
generate? What lists do they need to maintain? Figure that out and you'll
probably find that you're already 80-90% of the way there already. Add the
10-20% more information required to the system and send 'your' reports to
the people responsible and ask for them to compare theirs with yours to
identify where your information is lacking.

After a couple of rounds of updates, you get REALLY sneaky. You give them
access to enter their information and generate their reports from your
system. Once you've got them that far, and even though your department is
now saving substantial budget from the streamlined and standardised
process (and so are all the other departments now using the system), you
approach the bean counters for budget from the various departments for
upkeep of the system. ;)

> The CMS/KMS systems that will ultimately make content and
> knowledge management concepts work will be the ones that
> adjust to the way people work *now.*.

Can't emphasise that enough. That's the reason ISO, quality efforts,
XML/SGML projects, and all other manner of corporate/business efforts
ultimately fail. You can't force chaos to fit into little ordered boxes.

You need to first understand the chaos as it exists and box the whole
monster. Then, you can break the chaos down and compartmentalise it. The
duplicate and extraneous activities are removed from the box as the
organisation evolves.

> This *might* be possible with XML, *if* tools like word
> processors, spreadsheets, databases, etc., etc., migrate
> to configurations in which XML works under the hood of
> familiar tools,

That's the big red flag I went chasing after. :) XML has nothing to do
with this. XML may eventually be the common denominator, but it may be a
long way off in the future. In the mean time, standardise on the easiest
common denominators first; Storage, metadata, and retrieval. Then, expand
the metadata and work your way to standardising databases and spreadsheets
and lists.

> but unless the CMS/KMS can also handle
> the native file formats already out there, it can never
> really achieve its promise.

That's the key to where to start. Don't change the process or the file
formats to begin with. Design for the process and formats that exist now.
Once the trap is set, THEN standardise everyone else out of a job. ;)

Eric L. Dunn
Senior Technical Writer

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

ROBOHELP X5: Featuring Word 2003 support, Content Management, Multi-Author
support, PDF and XML support and much more!
TRY IT TODAY at http://www.macromedia.com/go/techwrl

WEBWORKS FINALDRAFT: New! Document review system for Word and FrameMaker
authors. Automatic browser-based drafts with unlimited reviewers. Full
online discussions -- no Web server needed! http://www.webworks.com/techwr-l

---
You are currently subscribed to techwr-l as:
archiver -at- techwr-l -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot- Visit
http://www.raycomm.com/techwhirl/ for more resources and info.



Follow-Ups:

References:
Re: Information Architects; was: Re: job title nomenclature on biz cards: From: Gene Kim-Eng

Previous by Author: Re: Experience with Resume Sender Services
Next by Author: Re: Information Architects; was: Re: job title nomenclature on biz cards
Previous by Thread: Re: Information Architects; was: Re: job title nomenclature on biz cards
Next by Thread: Re: Information Architects; was: Re: job title nomenclature on biz cards


What this post helpful? Share it with friends and colleagues:


Sponsored Ads