VCDX – Implementation Plan

Every VCDX submission requires an Implementation Plan.  This post covers the standard activities that should be included and how to align your Project Schedule with the VCDX programme.

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

A standard, Project Schedule “101” looks like this:

• Project Kickoff
• Requirements Workshops – What does the customer want?  What does the customer need?
• Design Phase – Develop the Architecture Design and Supporting documentation
• Design Verification – Peer Reviews, Lab build, Budget Justification, RFPs, etc.
• Ordering of BoM – Delivery of Hardware (if required) should take around 4-8 weeks (depending upon location) and Software is within a week (licence keys and support activation, since most software can be downloaded at any time).
• Pre-Requisite Infrastructure – non-vSphere touch-points to your design (VCDX-DCV)
• Training of Staff – (if necessary)
• Configuration – Build the solution as per the Configuration Guide
• Testing – Functional, Integration, Reliability and Performance testing as per the Test Plan
• Soft-Launch – Validate the Standard Operating Procedures and allow a pilot group of users onto the solution
• Vendor Resident Engineers – To support the first few months of Go-Live (if necessary)
• Go-Live – Everything is verified and meets the customer requirements
• Migration – P2V conversions, V2V migrations (if necessary)
• Project Completion

Irrespective of whether your VCDX project is wholly fictitious, partially fictitious or completely real, was never implemented, was implemented recently or will be implemented in the future, it makes sense to align your Project Schedule with the actual VCDX Submission and Defence dates (60 day window).  Why, I hear you ask?

After you submit your design, you will find flaws and weaknesses (your “attack surface”), since no design is perfect.  Part of your “story” when presenting to the panel, will be the detection and remediation of these flaws and weaknesses during the Configuration, Testing and Soft-launch phases.  The reason we Test and Soft-launch is to verify that the design meets the customer requirements and “feedback” any problems back into the design to improve it.

During your presentation, you are detailing the highlights of your design and how you detected and fixed any defects.  So, the more recent and interactive the timeline, the more real and convincing your dialogue and explanations will be.

The only caveat to this strategy, is using EOL hardware/software from an ancient project (3 plus years ago).  This makes it difficult to justify the risk of using EOL infrastructure.  My advice, update the solution accordingly before submission.