WBS (work breakdown structure) vs SRS (software requirements specification document)

Question

I am new to project management and need a clarification. I want to create the work break down structure for a software project. The definition is that WBS must contain 100% of the work. How can I determine 100% of the work unless I have done the detailed requirements gathering. But I read somewhere that WBS should include gathering requirements as a work package. To me it looks like an input to WBS. Can someone with real experience please clarify.

Answer 1

"WBS must contain 100% of the work"...that means we must consider all pieces works to be done under the scope of a particular project. WBS elements are defined in terms of "outcomes or results"...not every action/detail required to produce that result (minute detail would part of SRS and Low level Design etc document). How to determine the level of breakdown is described at http://en.wikipedia.org/wiki/Work_breakdown_structure

The purpose of WBS is to define and organise the scope of the total project in order to assigning responsibilities, resource allocation, monitoring the project, and controlling the project. So it just have project objectives/deliverables. But in case of SRS the purpose is encompassing all the functional and non-functional requirements of every objectives/deliverables.

For a small/medium level project we generally have one WBS document and several SRS documents. For big projects we do the same after dividing the projects in Modules.

Hope this will help. You are welcome with further specific questions. Thanks.

Answer 2

Notwithstanding Praveen's answer, which is a good one, I want to address the WBS, progressive elaboration, and EVM. While the WBS of any given project in any given industry must contain 100% of the product / service to be delivered, and at the lower levels, the actions required to produce product / service, there is no requirement that 100% of the WBS be developed and / or known before the project begins. In many cases and circumstances, it is simply unknown what will come next until some work is accomplished, which can include developing the lower level requirement or spec documents.

Further identifying and iterating the WBS as you become "smarter" are perfectly acceptable.

Conducting EVM in this scenario is also perfectly doable. As the work is further elaborated, it informs the planning values to be used in the baseline and, under control, you simply process a change to the baseline and keep working. Under this scenario, you can expect the BAC (baseline at completion) to be in flux while elaboration occurs. While this is normal and can be expected, it does become a stakeholder communication issue.

EDIT to answer Comments: With EVM, you ALWAYS have that option because, despite the ton of uncertainty with which we deliver projects, change is 100% certain. Your EVM capability needs to be able to handle change. Indeed, you could create a "baseline" of budget based on the rough order of magnitude cost estimates for the work of which you are not certain. When you learn more, you re-estimate / refine the later stages of work and, under your approved change process, adjust your budget accordingly.

When you strike a new baseline for downstream work, you should not be overwriting work that has already begun, so you would not be altering a baseline for work underway or already completed. You are rebaselining future work, where actual and variances have not accrued.

In cases where you want to, after a formal approval, rebaseline an existing work package, there are methods to do so without overwriting actuals and variances accrued. This can be complex but, simply put, you would close down the existing work package thus saving the actuals and variances and open a new work package with budget. There is way more to it than this but it is hard to get very detailed here.

Mark directed you to MIL-STD-881 above. Start there. There are other sources, as well, you can find out there for very detailed instructions.