Activity Codes or WBS: Which is Better?

I have a confession to make.

In my latest book, CPM Mechanics (2012), I was especially critical of the Work Breakdown Structure concept. In fact, I was equally harsh in my first book, Faster Construction Projects with CPM Scheduling (2007). I even wrote a separate ICS-White Paper in January 2012, entitled, “How WBS Can Break a Schedule.”

The truth is that the Work Breakdown Structure does have merit, just as it also has real world usefulness. And I can assure you that in the next edition of CPM Mechanics, I will most certainly wordsmith the section dealing with WBS. I will unequivocally declare that one can use the WBS mechanism as a systematic means of insuring that a Project Schedule contains all of the project scope intended for it.  I will point out that a well-conceived and implemented WBS offer be a potent and robust way to locate and access the most miniscule information in a Project Schedule.

In My Defense

So what set me off in the first place? I have been performing as a Project Scheduler for over three decades, across more than 185 projects worldwide. And yet I can count on one hand the number of times I have used a Work Breakdown Structure. And in almost every case my experience was fraught with aggravation and frustration. I have always preferred the utility of skillfully-employed Activity Codes.

In hindsight, I can see that my ridicule of  WBS was misdirected, for it is not the Work Breakdown Structure concept itself that is inherently flawed. Rather, the criticism rightfully goes to those who poorly executed it on those projects where I had the great misfortune of serving as Scheduler.

In each separate case, the WBS was had been created by a Cost Engineer. Not only did the Cost Engineer not consult with the Scheduler in development of the WBS in the first place, the entire WBS definition was established before the schedule was even conceptualized (which precedes its being written).

In other words, by the time I came into the picture as the Project Scheduler, the WBS had already been formalized. As a consequence, my subsequent scheduling effort was forced to “adopt” the existing WBS, despite the fact that the WBS may have been flawed – through errors of both commission and omission (e.g., missing or redundant scope). And no amount of discussion (whether polite or forceful) proved effective in bringing about the slightest alterations of the WBS, once formalized. Hence, the frustration.

Improvements in Software

Also in my defense, I note that in the years since my published rant about WBS, scheduling software has evolved, such that one of my complaints no longer has absolute merit. If you read the above-referenced ICS-White Paper you will see that I complain about the inflexibility of a WBS hierarchical structure that forces “only one WBS code per activity.” Well, nowadays, a few scheduling software programs provide the ability to create multiple, independent WBS structures. This means that a single activity might be assigned more than one WBS code. (That said, I still prefer Activity Codes over WBS!)

The Broader Issue: Choosing Scheduling Tools and Techniques

The question of whether or not to use WBS raises a broader, more fundamental issue — one worth discussing, and the real subject of this blog: how to decide which scheduling tools and techniques to apply when faced with more than one choice.

To be sure, having a range of selection is, for the most part, a good thing. After all, you wouldn’t want to eat a meal comprised of just one food type, would you? Imagine beef for appetizer, beef for the entrée, beef for the side dish, and beef for dessert. Yuck! You wouldn’t frequent a restaurant that only offered one meal choice on the menu, would you?

Let’s face it: When it comes to Project Time Management, there are as many “perfect solutions” as there are consultants to serve them up. Surely each one of these offerings (products, services, new concepts, etc.) has merit, and applications for which it might be perfectly suited. At the same time, however, we can be equally sure that no one of them is Utopian.

Each has its strengths and weaknesses; therefore, each has at most limited value. The challenge for each of us is (a) to find a way to understand what each offering is best at, (b) to learn how to choose from among them choices, and (c) to then skillfully implement a particular solution option that is best for a particular project’s unique circumstances.

Choosing Against the Backdrop of Differing Context

Mixed up in the challenge of the previous sentence is accommodation of differences among project players. Such differences exist along three distinct axes.

  • Topical: Along one axis is a broad range of managerial topics about which differences may exist.
  • Ideological: Along another axis would be an equally wide spectrum of possible values and beliefs with respect to any given topic.
  • Practical: The third differentiation exists along lines of process and performance.

What boggles the mind is how, with just these three factors at play (topical, ideological, and practical), the number of exponential choices can mushroom to create a management nightmare that defies measurement.

  • Topical Considerations: Within this group of concerns are tradeoffs and considerations like cost, time, contract, resources, harmony, quality, and so forth. Just among these few topics, which one(s) would you consider most important? And would member of the Project Team give the same answer?
  • Ideological Considerations: These differences concern what one values most, as well as what one believes to be the best way to secure and safeguard those values. Here is where the diversity of opinion is at its greatest.  For example, consider the standoff between popular management philosophies: Command-and-Controls versus Team Empowerment; Project Autonomy versus Home Office centralized Control, etc.
  • Practical Considerations: Differences concerning the practical application of management ideology typically entail Methodology and Technology.  Examples might include Earned Value, Gantt Charts, Critical Path Method, Graphical Path Method, BIM 5D scheduling, Momentum Scheduling, Critical Chain Project Management, Linear Scheduling, Location-based scheduling, Lean Scheduling, Earned Schedule, etc.

ICS-Research has studied the relationship between these three categories of managerial variability and reached certain recommendations. One such recommendation is that Practical choices should be made last — only as a reflection and consequence of Ideological and Topical preferences. By contrast, Dominant Project Management begins with Technology and/or Methodology and then either (a) backs into a “canned” Ideology that is forced to fit, (b) makes an assumption about which Ideology we must adopt, or (c) is silent on Ideology altogether.

To be sure, Cognitive Project Management approaches Project Management with tremendous respect for the multiplicity of options and choices that confound it, and it holds to the contention that effective Project Management boils down to real-time improvisation as the Project Team’s best risk mitigation policy. That is, the Project Team should have a variety of response arrows in its quiver, a selection of sharpened and ready tools hanging from its belt. We believe that the Project Team should have sufficient knowledge, training, and experience with using each option, in order to skillfully select and employ the best one for any given situation.

We are Blessed With Many Choices

The good news is that there is not just one right Solution for any particular Project Management circumstance. And, beyond debate, no single Solution can be best for all situations. We know this because:

  1. No two projects are the same.
  2. Projects, at their compositional core, are fractals. That is, each member of the Project Team perceives a slightly different project, even if all projects share the same name and address.
  3. Across its natural life cycle, the essential composition of a Project will gradually and subtly change in terms of priorities, conditions, informational needs, resources, tempo, complexity, etc.
  4. Members of Project Leadership are human beings; thus, unique individuals. Each one can be expected to hold to a slightly different Project Execution Strategy.
  5. Just as projects are fractals, so is Project Management. Each “knowledge area” within Project Management has its own innate organizational structure, success criteria, required skill sets, and functional processes.

As a tangible example of that last point, consider that under Project Time Management specifically, the Project Team must deliberate and agree upon a host of issues for which individual opinions may vary, perhaps widely, including: project strategic planning, project tactical scheduling, period and necessary rerouting of work flow, close-quarters coordination, long-range strategizing and remapping, detailed schedule analysis, broad-brush theorizing about GRASP factors, risk planning and dilemma forecasting, resource-leveling, schedule buffering, and on and on and on.

Activity Codes versus Work Breakdown Structure

So, the next time you are surfing LinkedIn and come across some out-of-control debate among “seasoned” schedulers over which is the better data manipulation technique, Activity Codes or Work Breakdown Structure,  just remember that there is always more than one way to skin a cat. No method is ever always right, or always wrong.

As a discipline, perhaps each of us would be well advised to descend from our high horse.

Leave a Reply

Your email address will not be published. Required fields are marked *