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

[eric -dot- dunn -at- ca -dot- transport -dot- bombardier -dot- com]

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.