Do you update your Work Breakdown Structure document once requirements have been defined?

Question

Once your business requirements and funtional requirements have been finalized - do you return to your WBS to update the document? From what I see in practice is that this artifact is used early in the project, if at all, but once the analysis gets started, the only thing that gets updated upon its conclusion is the schedule.

Answer 1

I think there is a frame mismatch here, and I don't think the question can be authoritatively answered unless the frames are clarified. My discussion below is very explicitly not to challenge or argue with OP. The way you manage projects is the way you manage projects and should be judged only on how effectively that permits you to close projects. That said, if I'm write and there are conflicting assumptions, the only way to answer the question is to articulate my assumptions and then pick apart where the methodologies differ.

(Aside: I suspect that the answer is that like many PMI processes, there is an ongoing dialogue among the process groups. The reason that planning is difficult is that creating the WBS may highlight the need for more clarity & precision in the requirements. That clarification may then force a revision to the WBS. But this has to take place in the context of change management).

OP writes:

By writing "WBS" I mean an org structure-like document listing deliverables, work packages (and not the "Task name" column in MS Project). Usually this is used to initialize work prior to defining requirements during the analysis phase.

In the project management methodology, requirements are decomposed into a WBS; this ensures that 100% of the work is planned and estimated. Work isn't initialized until planning is complete and planning is based on requirements.

See the PMI Process groups; creating the WBS occurs very early in the planning phase and prior to the execution phase.

At project Initiating, the project manager must understand the reasons why the project has been initiated, define the objectives that the project will achieve, and the metrics that will be used to measure its success. These are called “Business Requirements,” which describe the needs of the organization as a whole (not of groups or stakeholders within it) and the business value that the project should deliver. The proper identification of these requirements will give the project the right start. PMI library

If the WBS is to represent all the work required to accomplish the project, then the WBS must be based on/derived from the requirements. If you create the WBS prior to creating the requirements, then there is no way to ensure that the WBS includes all the work. I don't know how to identify deliverables if I don't know the requirements; there should be tracebility from every work package and every deliverable back to a requirement. OP clearly follows a different methodology with a different traceability - but it is very unclear to me how that relates to the PMI framework.

Based on this frame mismatch, nothing I have learned about project management would enable me to offer any useful advice on a methodology where the WBS precedes the requirements.

---

I tried to provide a terse answer (I struggle to be terse and frequently fail). I need more time to address the comment captured below; I believe this is an very important observation, but I currently believe it is tangential to the frame mismatch between OP's question and my answer. I believe that OP assumptions about the order of requirements and WBS are different from my understanding of project management methodology.

Isn't the work to capture and develop the requirements, which could include engineering designs, architecture drawings, even proof in concept preliminary products? I would expect that a very detailed WBS can be developed for that work with some WBS--higher level elements--and planning packages for the remaining work. @DavidEspina

To respond to this comment I'm going to have to discuss the project initiation process. That risks being argumentative. My prior answer merely states that OP and I order the two processes differently, and that the differing assumptions make it difficult to respond to the question - it highlights the frame challenge for further analysis. In order to respond to the comment, I need to discuss what I perceive as the "orthodox" project initiation process, which might seem to criticize OP's process.

This is further complicated by the fact that in my opinion project initiation is one of the critical failings of the modern project management model. I would be happy to have someone correct/educate me; I would be very very happy to be wrong.

A large number of the initiating processes are typically done outside the project's scope of control by the organization, program, or portfolio processes and those processes provide input to the project's initiating processes group. pmi.org

The PMI project model is a bit like physics discussion of the universe prior to the Big Bang - the only authoritative thing that can be said is "That's outside the model" - which is a formal statement of then a miracle occurs.

At one of my prior PMO's we defined five different analytical products/processes that had to be completed prior to the project initiation. The project charter had to be supported by a business case which had to be supported by a formal cost model, which had to be supported by an infinite regression of turtles, each of which had to be signed by CxO. I started to suspect why > 50% of PMO's fail within one year. Ours did. Figuring out how to explain that clearly isn't important to answering OP's fundamental question. The answer to that is "Building the WBS prior to requirements is a novel approach, and nothing in the PMI methodology is helpful".

I'll think on this some more and try to come back and be succinct and responsive.

Answer 2

Through a change management process, the WBS and other performance management baseline artifacts can change when change occurs. While many seem to imply that change does not occur if you are not doing Agile, change does occur using other delivery methods. Many sellers of service would develop its WBS prior to work beginning and the work can include additional work on requirements to arrive at a requirements baseline--you can call it final or whatever but the baseline can change. If the requirements change or evolve in a significant way, then it can lead to a change in the WBS and other PMBs accordingly. If your change process makes it seem such a change is too arduous to do, then your change process is broken.

Regarding PBS versus WBS, I would advise you to remove PBS from your PM repertoire. You can establish a product-oriented WBS, have a single project artifact, update only a single artifact, and not worry about ensuring the two products match and map.

Answer 3

To me, a "work breakdown structure" is: "house plans." In other words, "don't dare try to build a house without them." WBS documents that are set out before the requirements have been "finalized" are working-documents at best ... and, guess what, the word "finalized" might always be malleable. So it goes. But, the WBS should be a guiding light.

The "work breakdown structure" attempts to lay out at least a high-level strategy for what needs to be done, in what order, and involving which members/skills both within the team and outside it. In my view, it should be constantly kept up-to-date, and carefully compared against actual progress (or, lack thereof). "Of course you can't get it right the very first time," but the changes can be very instructive. Keep the whole thing up-to-date, even as you observe "what you got right, and what you didn't."

All of this – specifically including all revisions(!) and the full chronology thereof – should become part of the permanent history of the project, and you should carefully review it ex post facto for "lessons learned."

Especially(!) in computer software projects, it's very easy for the workers to "find themselves surrounded by trees," such that they wonder: "what forest am I in, anyway? I forgot." There are just so many details, all of which must be technically attended to, that "the total 'work breakdown'" becomes lost. This document can therefore be "the slender thread" which guides you back home.

"Lone wolf" developers who have become accustomed to "dive in and do it" might need to be shown the merits of: "look before you leap." Such things don't always come naturally to them.

Therefore: revise the WBS immediately after the project is greenlighted, then keep it up to date, and use version-control technology to preserve each and every version of it. ("Ditto" all requirements documents.) Let it always be the most-accurate representation of: "The Big[gest] Picture.™" And, carefully preserve its ongoing history.

Answer 4

If you use a WBS then I expect you should update it as frequently as possible.

You didn't mention what kind of work it is. If the context is software development then a WBS is not usually a good idea. Software development teams typically work better with a PBS or a Product Backlog -based approach rather than WBS. Also, requirements can't be considered "final" until you decide to stop using the software product.