VCDX – Supporting Documentation

Once you have finished your design documents, you then have to prepare the supporting documentation.  The length of this task is very often underestimated by aspiring candidates, who either rush the job to make the submission and possibly have their application rejected due to incompleteness or miss their submission date.

List of articles in my VCDX Deep-Dive series (more than 70 posts)

I was planning on writing this post in the coming weeks, but a Twitter discussion with Michael Webster and Will Huber preempted it.

This post provides some examples with the minimum information required for the supporting documentation to be considered “complete” and details the strategy to ensure that those documents completely cover the design.

The term “Supporting Documentation” refers to the following documents/sections from the VCDX Blueprint:

• Implementation Plan
• Configuration Guide
• Test Plan
• Standard Operating Procedures

Assuming you have validated that your design meets your Customer’s Requirements, you now have to ensure that your supporting documentation will allow the design to be implemented, configured, tested and operated successfully.  This is where we separate the men from the boys, so much effort has gone into the design process, you then need to marshal your resources and push through the creation of the supporting documentation.

The strategy is very simple, create a linked list that maps from each physical design decision to the Implementation Plan, Configuration Guide, Test Plan and the SOPs.  This is summarised in the diagram below:

It is very important to maintain a unique numbering system throughout all of your documentation; this will allow you to quickly verify that all components and scenarios are covered and then collate them into a matrix to ensure that nothing is missed.  For example: supporting_documentation_template and supporting_documentation_matrix.