1

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.

  • Read about progressive elaboration. – David Espina Nov 29 '14 at 22:16
  • how does it work with EVM methodologies? what if it can't be iterative. – Alex J Nov 29 '14 at 23:23
  • There is a good document on WBS called MIL-STD-881 that you may find helpful, particularly if you are looking at EVM. Also Google WBS and EVM for many good articles. – Mark Phillips Nov 30 '14 at 10:23
2

"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.

  • This makes total sense. Thanks for the explanation. But to generate the WBS, we have to involve the BA and some level of requirement gathering is done, correct? SRS will expand on it later I assume. – Alex J Nov 30 '14 at 11:52
  • also, will WBS contain a package to create the SRS document as a deliverable, in your experience? – Alex J Nov 30 '14 at 11:55
  • I also have a follow up question here. If you can provide insight, it will be great. pm.stackexchange.com/questions/12716/… – Alex J Nov 30 '14 at 12:54
  • Yes Alex, SRS can be one of the deliverable along with other documentation like design specification or test plan document. Thanks. – Praveen Prajapati Nov 30 '14 at 13:58
1

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.

  • Thank you for your comment. I assume this is more like a phased approach. Sometimes under EVM, you don't have that luxury. All work must be estimated upfront. Granted it can change as the project goes on, but delaying detailed req gathering on all WBS items may not be an option. – Alex J Nov 30 '14 at 15:15
  • I had another question about changing baseline. How do you do that. Do you just baseline the new scope/tasks, or overwrite the existing baseline. I would think the latter is undesirable because you will lose actual values of work completed till then. – Alex J Nov 30 '14 at 15:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.