After you have collected all of your individual scope elements, you should begin organizing these into logical groupings and categories. On my current project, we used butcher paper and note cards to shuffle and move things around on a big table and whiteboard. (Another method is to use so-called “mind-mapping” software to capture content. I’ve personally used products like coggle.it and MindNode for this purpose on small and large projects alike with very good success.)
During the initial layout, management should give the engineering team almost complete carte blanche to sort and organize, but they should be given some over-arching guidance; namely, when grouping items together, ask your team to think in terms of contracting strategies. How you’re going to subdivide the procurements on a project should align as closely with your WBS as possible; you should strive to avoid components in a single procurement package spanning multiple major branches in a WBS tree.
Way back at the start of my current project, we were a small team, and the plan was to stay “lean” for a while and try to leverage involvement from industry and partner institutions. This meant larger than typical contracted sub-packages for combined design and fabrication for many of the subsystems. Even if we assumed we were going to self-perform a task in-house, we acted as if we were going to subcontract out that package when organizing the WBS; this kept us focused on ensuring discrete, standalone and self-contained “contract” packages for which we could readily write SOWs, specs, acceptance criteria, and interface control documents, as well as estimating cost and schedule.
Did you find this post useful? Sign up here for our free email list to help ensure more like it are created. Thanks!
You can also email me directly at Mark@TheProjectManagementBlueprint.com