pmStudent

Tweet

Tweet

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!

I answer a question from a member of my project management training program about project scope considerations, and highlight a dichotomy between project scope and product scope, their different sources and how they should be thought of as separate but related entities.

Share this with your network

I recently received this question from a student and would like to share it with you.  (note they are referring to Figure O in the eBook, not in the full work breakdown structure training course.)

"I realize that it is important to capture testing and integration but your example (figure o) seemed somewhat arbitrary. Since integration exists to ensure that subsystems work together, shouldn't we have integration identified under deliverable 1 and deliverable 3 as well? Also, is it acceptable to have a deliverable called "final deliverable integration" at level 2? Just so you know,  I am a scheduler by background so I tend to think in terms of activities. What you stated about deliverables makes a lot of sense."

Thank you for the question Russ!  I'm happy to share my thoughts:

Integration as an example of a support element happens at multiple levels (components, subsystems, systems, segments, etc.)  On the project I'm currently working with now (NASA, USGS), for our software and hardware systems we have Integration & Test at the subsystem, system, segment, ground system, spacecraft, and mission levels.  We also do unit testing within components of the subsystems but that activity is called out as a schedule item along with code reviews, etc. and the WBS doesn't go down to that level.

I had a conversation today that reminded me about a mistake I see project managers make from time to time.

When creating a Work Breakdown Structure and the subsequent Basis of Estimates, some will use documentation as the key deliverables.

The logic goes something like this:  We don't have anything tangible to deliver except these documents, so hey, let's take all this other work, find which document it most closely relates to, and use that to hang our hat on.

This creates a lot of problems.  

First, it's not accurate.  You didn't take 600 hours to create that document.  Rolling up your work this way gives the illusion that by axing that one document from the scope, it will save that much time and effort.  Wrong!  Most documents, especially in a project with a heavy IT focus, are created only as the 'documentation' of a lot of other time and effort.  In my area, designing and creating build scripts, ERDs, data models, etc. might result in being ABLE to produce a good DBDD (Database Design Document) but all those pieces of scope are separate deliverables in and of themselves.

Second, it confuses your scope and the ability to create and track meaningful tasks for your team.  Creating the document is not the primary goal; the primary goal is delivering all the work (code, designs, etc.) that eventually gets documented in a formal fashion.

Thanks for reading my rant.  A penny for your thoughts?