The "V-Diagram" method is used extensively by Systems Engineers in large, complex science projects like major astronomy and particle accelerators design-build projects. It's also very applicable to medium and even small projects, too. In simple terms, the V-diagram is really just a means of graphically displaying the engineering-side of the life cycle of a project from the beginning, when you're defining big picture scope and requirements, down through system decomposition into WBS elements, creating subsystem requirements and constraints, through procurement and fabrication of the project deliverables, to assembly, testing, verifying the completed system works, and finally project close-out.
The flow through a V-Diagram corresponds with the five "process groups" that the Project Management Institute (PMI) espouses, but in my opinion it does so in a somewhat more useful fashion for your engineering staff. In other word, the PMI process groups reflect how "managers" think about a project's life cycle, while the V-diagram illustrates how systems engineers think, which means you as a PM need to understand it, too. Here's a picture of a standard Science-based V-Diagram (click the picture to enlarge):
You work your way through a V-diagram by starting at the upper left part of the "V", then dropping down along the left leg to the bottom, and then climbing back up the right leg. You also take the occasional loop back from the right side of the V to the left when verifying requirements compliance. In simple terms, you identify and define all the necessary project requirements as you move down the left leg, build to those requirements at the bottom, and then check the as-built deliverables against their requirements as you progress up the right leg of the diagram.
I once heard a very experienced and highly respected systems engineer describe this process as starting with high level requirements and then systematically "digging deeper" into the design requirements as you move down the V. This "digging" is captured by various subsystem documents that are derived from the high level requirements. This process continues down through the system architecture and WBS, to subsystem requirements, to conceptual, preliminary, and, eventually, to the final subsystem design specs and detailed ready-to-build drawings and specs of individual components.
At the bottom of the V, your team stops "digging" and instead starts building, sourcing, procuring, coding, and fabricating all the components and subsystems of the project. This is the point where all the requirements you uncovered on the way down the left leg of the V get turned into real hardware and software, either directly by your team or by contracted vendors or partners.
The right side of the V-Diagram is also known as the Assembly, Integration, and Verification (AIV) phase. This is when components and subsystems are individually tested, and then everything is put together and tested, and then overall system performance is proven. At the upper right topmost part of the V, the verification of the "customer" requirements (e.g., Science and Operations) is performed and the project comes to a close.
My aforementioned systems engineer friend calls this process of moving up the right side of the V as "climbing out" from the detailed depths of the fabrication and procurement phase. This is done by assembling, testing, and verifying the system with a progressively wider perspective and scope. As you move up the V-Diagram on the right, you test performance of each subsystem and assembly against the requirements you defined when coming down the left side of the V. By the time you get to the top on the right, you are testing very high-level system performance items; in the astronomy world where I work, this is where we verify that the proposed scientific investigations of the new observatory can actually be performed by the telescope that the project constructed.
[Note: If a component or subsystem meets its requirements during the AIV phase, it is by definition compliant and can be progressed further up the diagram into large sub-assemblies and assemblies. If a component or subsystem doesn't meet one or more of it's requirements, you then have to determine just how important those requirements are, and whether you can accept the non-compliance or not. This is a key concept, and I'll cover it in a later post, but for now just note that the power of the V-Diagram is that you can trace-back requirements at a low level up to their original sources higher in the V to help make decisions. Every requirement on the left side of the V has to come from somewhere above it or from somewhere like an engineering standard. This helps immensely when determining just how important a specific non-compliance is in the big picture.]
I'll break this all down further in the next few blog posts to make it clearer how you can use the V-diagram approach in practice to manage the life cycle of your own project.
© Copyright 2014 Mark H.Warner. All rights reserved.
