Scope, Requirements, and Work Breakdown Structure

The scope of the work and the requirements provide us with information from which we can build the Work Breakdown Structure or WBS.  In fact, even before we are able to start doing the work to build the expected results of the project, our work breakdown structure should capture the items associated with evoking, understanding and documenting the requirements.  We may (should) have one of the top levels of the work breakdown structure hierarchy that specifically address those items and things we should do when it comes to the requirements.  The decomposition of this portion of the project will ensure we consider all of the activities required to allocate both project time and talent to ensure the requirements gathering and documenting are given the diligence that this key part of the development of the product is due.  For example:

Example of Work Breakdown Structure for Requirements

That is not the end of the work breakdown structure.  The contents of the requirements documentation will also drive subsequent actions to deliver the product or project results.  In this way, the requirements will identify specific actions that must show up in the work breakdown structure.  For example, if our requirements point to software, then we know there will be elements of software development in the work breakdown structure.  The definition of the expected quality of the project delivery will identify quality assurance activities that must take place to ensure this objective is met, for examples think reliability and allowed failure rate in terms of parts per million.

The work breakdown structure is used to outline the way we intend to build the requirements, and then the requirements will identify specific actions that will be included in the work breakdown structure.  These two things are symbiotic; the work breakdown structure contributes to the gathering and understanding of the requirements by providing an outline of the things we must do to gather and document the requirements.  It also identifies dependencies (not a function of the work breakdown structure but the act of decomposition we learn these things) and securing the time and talent for generating these requirements.  Then the requirements help us to structure and define the things that must be done to fulfill those requirements.

If you want to build the requirements in an adequate way for the project, consider breaking down the work for building the requirements. This includes things like activities for finding and removing of the defects in the requirements and specifications before we start building the product in the project.