For every VCDX round, I normally run unofficial face to face mock as the last hurdle and prep for all those defending the VCDX that round in the UK and for anyone wanting to come to assist with the mocks and learn from them. I have run these for a number of years and have got really great feedback from them but last year alike to so many things I was unable to run any due to Covid and who knows if I can this year. So I thought I would do an updated series of postings around the advice I normally give in these mocks, advice I give in the VCDXPrepGroup slack channel I founded and run and link to postings where I summarised previous advice. I will break the series into distinct areas along the path to VCDX to try help people wherever they are along the path *NOTE* All advice here is keeping within NDA’s and despite me now training to become a VCDX panellist it is the same as when I hadn’t gone through the training.
I’ve built the design but what are all these other documents needed?
Naturally, most people focus on their design as this is what you are defending but the VCDX requires you to also submit at a minimum:
- An installation guide
- An implementation plan
- A testing plan
- A Standard Operating Procedures document
I will break down what each of these is if you’ve never come across them or if you think some of them are the same thing.
The installation guide is a document that shows for someone that is of VCP level skillset how to install the solution. This can have links to VMware documentation but it has to be personalised to your environment/solution as just a plethora of links will not suffice. I always tell people to do this document like you are providing it to a paying customer as they will want it at a level that their staff can follow it if they have to, for example, build the environment from scratch without you. I get asked sometimes if screenshots are needed and whilst it isn’t likely a hard rule, naturally if the person using the document can see a screenshot that looks exactly like the one they are on it will make it easier for them to follow
This is your project plan where you have to set out all the roles, responsibilities and the timeframes for each portion of the design. Again this has to be specific to your project so even if you have a generic timeline from your vendor or company you need to amend it to your design and trust me the panellists review all the documentation so don’t put your design being accepted to defend at risk by not doing this or any of the supporting documentation properly.
This is where you now prove your design and components by running it through tests to prove it works. I personally like to number all of my tests as even though it isn’t a requirement for your VCDX submission I find using a Requirements Traceability Matrix and showing how you have taken all the requirements from the conceptual design all the way to the testing and validation phase and proven the design you have created meets these helps you ensure you’ve not missed something. Alike to what I mentioned in the implementation plan section you have to provide a testing plan specific to your environment as generic tests of just pulling some cables etc will not suffice.
Standard Operating Procedures
The SOP is all the steps and procedures needed to keep the environment running whilst you are away as well as steps your end customer must follow in the event of certain failures. A good design is one where at the end of the project when you leave the end customer can run it with as little effort as possible. If your design is so complex and requires so much continual manual monitoring and tweaking to keep it running then you have very possibly over-engineered it and the project is at risk of failing. This document should be covering places where the end-user can do checks on all the dashboards, automated reports, configured alarms and how to troubleshoot and build out the environment once you have left.