on - edited on by
VIVEK - vkulanda
Previous Article
This article describes the life-cycle of a typical document following the Cisco Advanced Services quality policies. A document has to go through different stages before being made available to the customer.
DCP capabilities allow the Cisco Advanced Services delivery team and you, the Cisco partner or customer to drive the document through its life-cycle. The different steps of a document life-cycle are explained in this article.
A Deliverable document will typically go through 4 stages before being made available to you, the customer for download : Authoring, Review, Approval, Publishing.
The below illustration depicts the document life-cycle from a Cisco Advanced Services delivery agent's perspective (such as a Cisco network consulting engineer or a Cisco system architect)
Other document types however (contractual documents, supporting material and reference material) do not have to go through these stages and will remain in the authoring stage throughout its life-cycle. Here's a definition of the different document categories used in DCP:
- Deliverable: a document created per the scope defined in the contractual agreement (e.g. low-level design, security report, design recommendation, …)
- Contractual Document: a document created for use during contract negotiation, validation or signature and with contractual value (e.g. Quote, SOW, MCC, …)
- Support material: a document created in support of an engagement, but not necessarily defined in the contractual agreement (e.g. closeout checklist, network diagrams, meeting minutes …)
- Reference material: documents that are not related to any engagement and can be reused in support of a particular engagement (e.g., white papers, calculators, …)
Authoring
This stage is where the author is still creating the document. It can go trough different versions before it is ready to be reviewed in the next stage.
The author will upload the initial version into DCP. The meta-data essentials will default to :
- version: 0.1
- status: pre-draft
- category: deliverable
‘Pre-Draft’ is the default status when a document is initially uploaded and defines the 'Authoring' stage. This status should be used if the document is not yet ready for review and/or approval.
If the document is not a deliverable, the category can be changed to any of the other categories: contractual documents, supporting material or reference material. As these documents don't have to go through the review and approval stages, the status will be set to 'Approval not Applicable'.
Note: Properties are editable by the Author and the document Owners. As such, document Owners can act as a proxy on behalf of the Author. Both the Author and Owners can progress a document through its life-cycle.
Version numbering is completed by DCP itself to ensure consistency in numbering and compliance to our policies.
Subsequent versions through the authoring can be uploaded using the check-out/lock and check-in capabilities. The subsequent versions will increment their version number as 0.1, 0.2, 0.3 ... The lower digit indicates how many versions have been uploaded.
When the document has reached a stage where it can be reviewed by peers and being approved, the status should be changed to Draft. By changing the status to Draft, other actions become available such as 'Submit for Approval'.
Reviewing a document
At this stage, it is recommended to change the status of the document to 'Draft' to indicate that the authoring stage is over and that the document can start the review and approval stage.
To review a document, DCP provides Discussion capabilities. Every document can be discussed separately and the full discussion is captured and saved with the document meta-data.
A discussion can be started at any time throughout the content life-cycle but it is definitely during the review stage that a discussion is recommended to collect feedback from peers.
When inviting peers to participate in a document discussion, they become a reviewer of the document and they will have the possibility to download the document for review and leave their feedback comments in the discussion.
Discussions and the notes within are time- and date-stamped and are tagged with the name of the person providing the comment.
Furthermore the version number of the document in which the document is when starting a discussion or leaving a comment is tagged with it as well. This will be useful for audit purposes to show which versions got reviewed through a discussion.
At the end of the review stage, the author will consolidate all feedback and incorporate it in a final version and check it in. Now the document is ready for approval
Note: A reviewer also becomes a contributor by default. A contributor of a document can check-out/lock and check-in a document. The full capabilities to progress the document through it's life-cycle (such as submitting for approval ...) are limited to the author or owners of the document.
Approving a document
The approval of a document consists of the internal approval, followed by the customer acceptance. The approval capability provided by DCP can handle both at once. First it will seek approval from the invited Cisco employees after which it will seek document acceptance from the invited Customer contacts. Again here, only the Author or an Owner of the document can submit the document for an approval.
During the approval process, the document version will change to 1.0 and the status will go through following states :
- Internal approval pending
- Internal approved (or internal rejected)
- Customer acceptance pending
- Customer accepted (or customer rejected)
From the approval stage on, from the moment that you submit a document for approval, the status will change automatically and doesn't need to be managed by the author or owner. It is DCP that drives the status through the full approval stage.
Once the document gets fully accepted by the customer, it can be further published to additional customer contacts.
If in step 2 or 4 the document gets rejected, the document has to go back to the review stage. The author will have to understand why the document was rejected, incorporate the necessary changes and go again through a review and full approval.
To do so, the author (or owner) will upload one or more new version(s) with changes incorporated. The status will automatically revert to 'draft' and the version number will show 1.1, 1.2 ... The major digit showing '1' indicates that the document already went through 1 approval cycle, even if it was rejected. This is important for audit purposes.
Tip
At any time, the version number reveals a good portion of the history of the document. E.g. version 2.3 indicates that the document already went through 2 approval cycles and since the last approval cycle, 3 additional versions were uploaded. DCP provides capability to review the full history of a document. This is explained in a separate article.
More details on the approval cycle is provided in its respective article.
Publishing a document
Once that the document is customer accepted it is possible to further publish the document to additional customer contacts. The customer contacts that where invited for the document acceptance have the document already published to them. But at this stage you can add additional customer contacts. Only the customer contacts that are listed in the publishing setting will be able to see the document listed and will be able to download the document.
Publishing is limited to Cisco employees and if you as a customer want to ensure the document is available to other contacts, you will have to work with a Cisco employee that is listed as owner or author of the document. This is further explained in a separate article.
Archiving and Purging a document
Like with every content management system, documents have an active life-time after which these get archived and eventually will get hard deleted (purged) from the servers.
The archiving of a document is defaulted to 2 years after the last modification of a document. This can both be a new version uploaded or changing any of its properties. The archive period of 2 years can be changed in the properties of a document. Archived documents are hidden from listings but can still be retrieved and restored if necessary.
Purging a document is system driven and is defined per the Cisco Enterprise Records Information Management (ERIM) policies. The Cisco Records Retention Schedule for DCP documents is as follows:
| Category | Retention period if linked to Project | Retention period if not linked to Project |
|---|---|---|
| Deliverable | 10 years after project finished | NA |
| Contractual Document | 10 years after project finished | 10 years after last modified date |
| Support Material | 5 years after project finished | 5 years after last modified date |
| Reference Material | 1 year after project finished | 1 year after last modified date |
A monthly job will calculate which documents are due purging.
Both for archiving as for the purging a notification is sent upfront to the author and owner(s) of the document .
Related articles :
Table of Content
Previous Article