In almost every project of any complexity, a debate arises as to how to set up the work breakdown structure.
Traditionally, it is about the work. If you're building an airplane, you need engine, wings, body, and so on. They often get produced by different vendors so it makes the contract management and earned value reporting much simpler to keep these products together. It allows one to see the progress towards having a completed component or product. Besides, it's called a work break down structure - shouldn't it be about the work? But more often that not, the project WBS looks like a life-cycle: plan, gather requirements, design, build, test, deploy (or something pretty much like that).
As soon as you start decomposing a product-based schedule, assuming an organization with some level of process maturity, you notice that you're just cutting and pasting task names. Each element of the solution requires each of the life-cycle phases. Now each phase has deliverables in it, so those deliverables are repeated numerous times through out the schedule. And each of them has a set of generally-identical steps: draft document X, review document X, update document X, obtain approval for document X, publish and distribute document X. Very tedious.
It doesn't take long before somebody says "why don't we organize this thing the other way around?" Put all the planning and approval actions together, all the requirements gathering together, and so on. This is especially prevalent where the organization has defined a fairly comprehensive list of artifacts, while the actual products the project is to deliver are somewhat nebulous. All the more reason to expose those products at the highest level of the project!
The math on this is actually quite simple: under every circumstance but one, it doesn't matter. The number of tasks is the number of components times the number of process steps.
However, the one exception may actually be the norm. If many of the product components move through the process at exactly the same pace, then they can be handled together on a single artifact set (requirements document/s for wings, fuselage, wheels as one document, requirements for the engine as a separate document, rather than tracking 4 sets of artifacts through their creation. If the entire work is subjected to a series of phase gates, where work is essentially being steered towards at least notional stopping points, this is not an unreasonable point of view. It does encourage a realization that the work does have to pass through these phase gates, and it does serve to acknowledge the governance's authority's right to stop the work where it doesn't seem to make sense any more.
The main disadvantage of focusing on the life-cycle rather than the work product is that it does seem to lead to a tendency to forget that the project is about getting actual working products or services into being rather than about getting a bunch of documents completed. As noted above, if the project's real deliverable (not the artifacts) are unclear in the beginning, hiding that structure inside a canned SDLC structure is not going to provoke the necessary thought; such a project is almost sure to end up missing some very important capabilities, the absence of which may not be detected under the sheer volume of artifacts.
Now, what is NOT acceptable is to use a life-cycle approach for things that are turned out at different times. That completely masks visibility into the progress of the products. For instance, if a solution will be rolled out in three distinct increments, it is very important that all the work leading to each incremental roll-out be part of an integrated package. Much of the work for subsequent increments does build from similar work in earlier increments, but that's no reason to package (for instance) all the design work for all increments under an overall "design" heading.
Perhaps one of the reasons that this issue keeps coming back up is the ability to pile a lot of detail into tools like Microsoft Project. Just because one can do so quite easily does not mean that it needs to be done. Putting it in there is one thing; managing it is another (and no doubt there are professional schedulers who relish the job-security a grossly over-complicated schedule seems to provide them, at least until the project collapses under the weight of its overhead). A grossly-abused "best practice" in project management is to have no task lasting longer than two weeks. If we go to the references, we see that the actual recommendation is that tasks in a schedule should be no longer than twice the reporting cycle - and that reporting cycle should be based on what makes sense for the level to which reports are being rendered. No doubt a work team leader wants reporting weekly, but in that case, what is the proper degree of granularity for a business-unit executive?
Let's not forget the other guidance in this area: projects should be baselined (and then reported on) at the contract WBS level , which is defined as one level (at most two levels) of indenture below the contract itself and therefore at most only only the third level in the project. If you've got tasks like "review draft report" in your schedule, you'd better be leading the team that is actually writing or reviewing that report. If this sort of task is making its way up the reporting chain, you're adding a lot of fairly meaningless reporting overhead and costs to your projects, and the sheer volume of all that may be distracting you from much more important observations.
No comments:
Post a Comment