What are we trying to solve with a Shared Documents Model for CSS?

Anne's Framing Questions

In an email from June 27, 2006, Anne reminded us:

Here I would like to interject for a moment to ask the question: what was our original purpose in seeking a central place for us to go for information, reports, plans, etc.?

I would like to add the following questions for consideration in the discussion:

1. What are the desired outcomes of having a central place for all these shared items? I envision having links in the future between documents, say quarterly reports/resource model/financials that would be best done with files in one place.

2. What tasks do we envision relative to each type of document ie changes to annual plans, quarterly report text, inputting of updated financial forecasts, addition of css-mgrs meeting agendas, etc...

3. Can both confidential and non-confidential materials be kept in one central place with confidential materials kept in a hierarchy of password-protected access folders?

Existing Conditions...

Our default approach to collaborative work seems to be:

someone has the lead in shepherding a document to its next stage of completeness.
the owner of the document finds the latest version in an old email from the previous owner, or in a personal folder where they've saved it.
a copy of the document is mailed to everyone involved.
contributors make changes in their version and send the edits back, where the owner somehow reincorporates them into the working original.
that copy is mailed around again, and definitive printouts are made.

Drawbacks to this style of work:

If the original owner leaves, no one is sure who has the next best "official original".
When a group is responsible for editing portions of the document, no one is aware of the changes made by the others until it is all integrated and shared.
When finished, no one knows where to store the finished copy, except that the current owner has it in their inbox somewhere.
If a document is a living document -- ike the operating plan, say -- updates are not possible except by some process of contacting the owner, asking for a change to be made, and then expecting the owner to continute to keep track of the new original.
Because the above is so unwieldy, it just doesn't happen. The result is that the document quickly no longer reflects how things really are, and becomes a management burden to update when, every so often, it becomes important to have that document match reality (as at quarterly report time).

Proposed Outcomes of a new style of work

"The System" keeps the definitive master copy of the document. Not any particular person's inbox.
Changes to a shared document can be made by anyone in the group; changes are tracked and can be revoked;

What documents do we have group responsibility for now?


Operational Plan.	Now a word document of mostly bulleted text with a table or two. For fun, this is a Wikified version of the draft FY07 CSS Operational Plan
Quarterly Reports
Budgets and Forecasts	Generated on a quarterly basis.
Meeting Schedule, Agendas, Outcomes	Intermittently used as a formal work planning modus operandi within CSS.
Process Documentation
Resource Allocation Model	Currently maintained on sparkler1 as the official copy, with the working master on Rob's laptop.

Which technologies are likely to be best for what?

Confidentiality is one forcing factor. Documents with sensitive data need to be closely protected. We need to be able to have documents locked down so that as few as three people only are able to view and update.

Interactivity is a forcing factor. The Budgets and Forecasts area is represented with a complex set of layered spreadsheets, which only work when the formulas in one sheet are actively updating from data in other sheets. Rolling up linkages among these sheets are greatly enhanced by storage in a single file tree.

Compatibility is a forcing factor. If, say, the CSS portion of the quarterly report needs to be able to merge into the same master document as other directorates, then we need to be able to convert, at least, form the group-edit format