My experience was there wasn't anything gained from explaining to our
end users the technology behind records  management.

I just had to say "We need content types  to route records." When it
became too much again to explain what a content type was, I just guided
them through describing MetaData.

I had the same experience with publishing and approval. People don't
seem to want to know why it works because they're having a hard enough
time wrapping their heads around how to do their part in the process.

My recommendation is to start small and grow in to it. This is contrary
to my original feelings to share more technical  information to encourage
a more comprehensive base of understanding.

I don't know yet which was the better path, but you may take some time
to consider this about your user base.

> I don't know yet which was the better path, but you may take some time
> to consider this about your user base.

That's definitely good advice.

I think it really does depend on your users. Many of our MOSS users have
absolutely no interest in how it works, while other 'power users' really
dive into it and quickly learn as much as I have.

In regards to this particular group, they're not developers per se, but
do work within IT. So they can definitely appreciate any technical
training from an analysts POV.

I also think that understanding what MOSS could provide might help  push
things forward a bit for us.

Still, not necessarily looking for technical  instructions as much as
comprehensive feature lists that would apply to the records  folks. I'm
looking for the fabled document that falls somewhere between the sales
literature and the developers training.

office.microsoft.com/.../CH101786671033.as
px

office.microsoft.com/.../HA101280011033.as
px



office.microsoft.com/.../FX101494691033.as
px

Sorry that second link was IRM not Records.

I wonder if any of those pages have the fabled documents you need.

The first step in any records  retention policy  is actually a very
non-technical one. The staff  who will be in charge should start putting
together a matrix that reflects your document policies. The matrix
should cross-reference the various categories of documents with what
additional metadata you want, how long you want/need to keep the
documents online, what you will do with them when they don't need to be
online anymore, whether you need to track changes or not, etc.

This matrix will be what you use to setup custom Content types  and
associated Information Management policies. You'll need to have the
content types in place before documents are created or you will not be
able to effectively store them in a Records Center. The first step to
building the content types is know which ones and how many you will
need.

> This matrix will be what you use to setup custom Content types  and
> associated Information Management policies. You'll need to have the
> content types in place before documents are created or you will not be
> able to effectively store them in a Records Center. The first step to
> building the content types is know which ones and how many you will
> need.

What kind of pain are we talking about if we need to retrofit this 6
months down the road after we have people already using MOSS?

It is a matter of migrating all existing content into new document
templates at that time?

I don't think that'd be a huge deal, as the onus would be back on the
individual document owners and something we'd have to do now or later
anyways, as I don't think many of our documents are in too much of a
consistent structure to begin with.

It would be a matter of modifying each document record to use the right
content type before sending them to the records  repository. Since
document templates are applied when the document is created you wouldn't
have to transfer the content to a new document template, simply change
the content type and fill in any metadata required by the new content
type.