This is a good discussion. The main question seems to be "is it better to
insert 'office of record' into the retention schedule or not?" Those who
say yes insert it say that without it non-owners think they have to follow
the retention schedule. Those who say no - like me - say ownership is not
stable enough and the structure of the retention schedule doesn't map well
to owners, creating risk of inaccurate and incomplete ownership information
which is not worth it given that the purpose of a retention schedule is not
to identify ownership but to identify length of time records of certain
activities must be retained.

I should clarify that policy at my job says record owner can be creator or
receiver of record, not just creator. I negotiate disputes from a default
position that owner is creator but that's not in the policy. Also, at my
job, RM policy and retention schedule are the same document.

The BOD example is not a representative example because it's the most
stable activity in a company and most BOD records are not created by the
BOD office which is not the norm. Yes, inserting BOD office as owner of BOD
records into retention schedule would help people who contribute BOD
records to understand that they are not the owners. BOD ownership is not
going to change so no constant schedule updating needed. But most business
activities change ownership more often than BOD and most record owners are
the creators. Constant changes of ownership -  or maybe I should say names
of business unit owning the activity - which happen as a result of
'restacks' make me unwilling to insert office of record into the retention
schedule knowing it will be out of date most of the time for most record
examples in the various record classes within a year. The project records
example doesn't convince me that it's any help to say, in a retention
schedule, that project team owns the various project records their team
creates or receives. (An owner is not 1 person, 'office of record' means
anyone in that group. Nobody is proposing that individual people be
identified in a retention schedule are they?) Project teams question to me
is 'is this document a record or junk?' not 'is the project team
responsible for this document or is some other business unit the owner? '.
Individual guidance when it comes to project records is more useful than a
vague statement about ownership in a company-wide document.

Is it OK  to insert office of record into retention schedule for some
record examples in some record classes but not others?

At my job the retention schedule is actually part of the RM policy, it's an
appendix. For those of you who keep a retention schedule separate from
policy, do you repeat statements from the policy in the retention schedule
- statements about record definitions, purpose and use of the retention
schedule, consequences of not complying etc.? Those statements have to be
in a policy, no question. Repeating things from one official rules document
to another will inevitably result in discrepancies that confuse people and
cause controversy. But not offering explanations or definitions in a
retention schedule is not helpful. Schedule and policy should be one and
the same - intellectually and physically arranged to be the same and
linked. It's OK to publish additional communications around it that offer
more detail and more examples, even naming units or individual owners or
those tasked with recordkeeping responsibilities, as long as no
contradictions with the policy. But that additional stuff belongs outside
the policy/retention schedule. It's not OK to name owners (groups or
individuals) of records or record classes in the retention schedule but not
provide policy statements about the principle used to select owners, the
purpose and goal of naming owners, the obligations of owners.


-- 
Maureen Cusack
San Francisco, CA
[log in to unmask]

List archives at http://lists.ufl.edu/archives/recmgmt-l.html
Contact [log in to unmask] for assistance
To unsubscribe from this list, click the below link. If not already present, place UNSUBSCRIBE RECMGMT-L or UNSUB RECMGMT-L in the body of the message.
mailto:[log in to unmask]