Dr. Paul Giammalvo and I have a lot of heated and fun discussions about project management best practices. Sometimes we agree, sometimes we disagree vehemently. From Paul:
“As you know, I am NOT a fan of “ad hoc” or creating customized WBS’ unless absolutely necessary. (And how many projects are TRULY unique) I spend an inordinate amount of time arguing against exactly what you are advocating…….There are a lot of good reasons for developing standardized WBS/CBS structures….While Omniclass was designed for the built environment, the fundamental reasons underlying the creation of this approach are valid for other sectors as well“
Domain Dispute?
I wrote a book on the WBS, which may be why Paul likes jabbing me so much on this topic. 🙂While it’s true there are many similarities in projects, from my experience with software projects there are many nuances and differences too, especially in the lowest WBS elements.
I see standardized WBS in my industry especially with physical products that are fairly routine like our spacecraft and launch vehicle. But when it comes to sensor development and the ground systems there is a good deal of variability. Because we are working on Landsat 8, we have two missions that are still operational and history with the previous missions to draw on. And while there are similarities, there are many differences too.
We have a completely different Con Ops for L8 due to the manner in which data is collected on the spacecraft and how it’s transmitted to the ground stations. Plus the implications of a push broom versus a whisk broom scanning sensor used with previous missions necessitates entire new subsystems and other components we’ve never had before.
Innovation and Fresh Eyes
What’s more, some major changes in processing scenarios were missed (in my opinion), even though major changes from the last mission are present. This was partially if not mostly due to a reliance on project artifacts like the WBS and requirements from the past, instead of looking at the system and customer needs with fresh eyes.
So perhaps it’s a domain thing, but in software my experience had led me to believe that starting with something similar and adapting creates mistakes in planning and stifles innovation. I would not dispute the utility of standardized WBS and planning in industries like construction or refineries, because I have no experience in those domains and can see how standardization would easily apply.
So with software systems, my contention is that you end up with your grandpa’s architecture and design when you start working from his blueprints.
What Do You Think?
Where do you come down on this topic? I’d love to hear your thoughts and experiences, especially if you work with software systems to a great extent. Maybe I’ll learn some new things and need to go write a second edition of my book.
Hi folks,
Not sure that I would characterize our disagreement as being “vehement” but it certainly is passionate!!
For background information, I am coming from a background in construction, not IT, but as a life-long (as opposed to accidental) project manager, I have seen the advantages of standardized WBS since the mid 1960’s.
The first was the Construction Specifications Institute’s “Masterformat”, http://csinet.org/numbersandtitles which was a coding structure designed originally to ensure that elements in the construction documents appeared once, and only once, and always in the same place. For contractors bidding on the work (which was my primary role) the CSI coding structure became a logical and rational way to organize my costs, as for each element in the WBS, there had to be a cost. Masterformat was organized roughly around the various trades and followed a more or less progressive approach- Division 01 is General Conditions, 02, Existing Conditions; Division 03 is Concrete etc. At some point, practioners realized that sorting only by trade provided a limited perspective- that a second way of organizing the project was needed, so CSI came up with Uniformat. http://www.csinet.org/uniformat Uniformat enables stakeholders to sort the work of the project not by trades, but by COMPONENT.
This model has been tested and proven, not only in the courts, but in actual practice.
Fast forward to 1992, and the offshore oil and gas sector liked CSI’s Master and Unformat concept, but found the coding structures limited and not addressing some of the unique aspects of offshore oil and gas. The Norwegian government created Norsok Z-014, which was a three dimensional model- by Resource, by Component and by Time. http://www.standard.no/PageFiles/951/Z-014.pdf Again, having been around for close to 20 years, this WBS/CBS also has stood the test of time.
Fast forward again to 2005 and driven by the growing use of Building Information Modeling, (BIM) CSI, ISO and the Electronic Product Information Cooperation (EPIC) after extensive research into what various stakeholders expected, Omniclass was created. http://www.omniclass.org/index.asp Omniclass offers 15 different tables or ways to sort the work deliverables required from any construction project.
So where is the disagreement between Josh and myself? The key issue is Josh claims that software is “different” enough that a standardized WBS cannot be created. I disagree. My position is that probably 80% to 90% of software creation could be standardized, leaving only 10% – 20% which is unique enough to require a customized WBS.
So the question is, given the construction sector (which is a much more mature user of project management as as delivery system) long ago recognized the need for standardized work and cost breakdown structures which enable multiple sorts is the reluctance of the software sector merely suffering from the “not invented here” syndrome or is Josh’s argument that “software is different” valid?
For those interested in this debate, you may enjoy the work being done by Jean Yves Moine, on the importance of multi-dimensional sorting capabilities. http://3d-wbs.blogspot.com/
Enjoy and looking forward to an enjoyable debate on the subject of WBS.
BR,
Dr. PDG, Jakarta, Indonesia
http://www.build-project-management-competency.com
I know, but “vehement” makes for a good title! 🙂
Just to clarify, I’m not saying that a standard WBS can not be used for software…just that it shouldn’t.
I think it is a direct correlation to how much is truly unique and how much has been done before. If you are doing more of an IT project implementing your company’s software solution that is going to likely be almost operational in nature with important differences for each client.
If you are developing software for something that hasn’t been done before, standardization can be more of a hindrance than a help in my experience.
Hi Josh,
Well, I guess we will have to “agree to disagree” that no matter how “unique” some software creation may be, that there isn’t or can’t be value in some standardization.
Again, having been a “practitioner” for over 40 years, many of those where my own money was on the line as a general contractor, the standardized WBS serving as a check list (risk mitigation) saved my butt (not to mention my bank account!!) on more than one occasion.
Bottom line- when the IT sector can consistently deliver projects on time, within budget, in substantial conformance to the technical specifications while substantially achieving the purpose for which they were undertaken, THEN I am willing to entertain arguments that “you do things differently” or that “your way is the better way”, but given the rather abysmal track record of IT projects being “successful”, I would be hesitant to tout what you are doing as being a “best practice”.
🙂 🙂 🙂
BR,
Dr. PDG, Jakarta, Indonesia
http://www.build-project-management-competency.com
Thanks Dr. Paul. I think you would have to establish what the common practice today in the IT sector first, and be able to control for the other variables involved. From my anecdotal experience, I can tell you the majority of projects I’ve interacted with but wasn’t managing myself in the IT sector are NOT doing what I’m doing with the WBS tool, let alone the BOE, value stream mapping and other lean techniques, etc.
The # 1 problem I’ve seen isn’t really a matter of standardization or not…it’s project managers opening up MS Project and starting to plug in a schedule on the fly, and they call that their ‘project plan’ — they don’t have a WBS…
I’m going to have to side with Dr. Paul on this. The intent of a WBS is to define scope and deliverables into manageable packages that are agreed to by the customer. If extreme details aren’t known then you would break it down to a planning package. The fact that, “If you are developing software for something that hasn’t been done before, standardization can be more of a hindrance than a help in my experience.” I would say you are working in an R&D environment where risks are more acceptable and your WBS should be very flat, just enough to track costs.
The value in using a standard is so costs on similar projects can be compared and evaluated. It also keeps redundant new terms from creeping in to confuse stakeholders just because the engineers want to be creative. Using a standard also allows for a place to start when you are defining a project and something to estimate to. Throughout the project there are opportunities to decompose planning packages as well as utilize the change management process to adjust the WBS if the design is refined so much it constitutes that action.
The WBS should constrain design when necessary to meet customer expectations regardless of the product being software or a manufactured good.