pmStudent

Like this? Share it!

Thanks so much for the email Vinay, and I'm glad you enjoyed the Work Breakdown Structure book.

To answer your question, I've seen many IT projects structured that way and done it that way in the past myself, that's the norm.

However, I think there is a better way.

First, I try to avoid using SDLC/project phases as a way to structure deliverables at a high-level. There are obviously deliverables associated with phases, but in general I think doing this takes the focus away from the product and towards the process. For a scope definition document, I want it to be very much product-focused without regard for the methodology that may be used (and may change during execution).

Second, I use the levels as examples in the book and you'll probably remember my point regarding the levels at which deliverables "live" - trying to assign these levels ahead of time (a level for subsystems, another for components, etc.) is problematic. It tends to introduce artificial groupings of deliverables and levels that don't make sense. The same goes for trying to assign cost control points at an arbitrary level across the entire WBS - sometimes it makes sense to control costs higher or lower depending on the stakeholders, visibility of the element, etc.

That's probably why I went light on full-fledged end-to-end examples - no two projects are alike, and with templates people start making decisions that end up creating artificial complexity and overhead. I've been involved in several large-scale projects where this happened and we ended up with these 'phantom' levels in the WBS and requirements that just create extra work for no value. Lower-level requirements get traced through an intermediate level when they could just get traced directly to the higher level, etc. I'm talking about millions annually down the tubes just due to the structure of a WBS.

Like this? Share it!