The Down Side of Good Tools
Often, out of the sea of different opinions of how things should be done, there rises a few techniques that make it to the level of becoming a standard way of doing things. They can be codified in a Body of Knowledge, if such a thing exists for that discipline, or become generally accepted as a ‘best practice’, though we all know that these things are quite rare. Even when they are raised to that level, there is danger that they can become overused: while every technique has it’s niche, no technique should be used too broadly. Such is the case with Work Breakdown Structures and Gantt charts.
These tools are considered de rigueur for project management, at least for those project managers that have been formally trained and for those projects that can’t be run off the back of an envelope. The Work Breakdown Structure is a great tool for categorizing all the different areas of work that would likely take place on a typical project, and works best when it is tuned to the particular type of project we are dealing with. We could have a WBS for building out a PMO, for example, or a WBS for building a house (which would be distinct from a WBS for building an apartment building, and quite different than our PMO WBS [enough TLA’s yet?]). It excels as a tool for capturing and extending our understanding of what needs to be done from project to project of the same type, so we don’t get caught with our pants down and forget an entire class of effort in a particular domain.
The WBS is best used as a memory jogger as we build out our initial network of activities for the project, but we need to be careful to avoid overextending it’s utility. A good WBS is hierarchical in nature, and extends down from the major categories to more detailed descriptions of work to be done, but implies no relationship between these nodes, and carries no information about the effort or duration for any of them. These are project or implementation-specific issues, while the WBS carries common information across projects of a particular domain. As it is hierarchical in structure, and PM tools capture hierarchies well in their Gantt view, this is where we often start getting into trouble.
Many teams will capture a WBS within their PM tool (such as MS Project) for convenience. From that point, it can easily be seen as a simple step of connecting all of the lowest nodes of the WBS together with finish-to-start dependencies in a Gantt view, attaching resources and duration or effort to them and voila! We have our project schedule, it took us all of about 10 minutes, and we’re off to the races.
Except for that little issue that the network we build has no relationship with how people will actually interact to get the job done, making our network a useless tool for tracking and managing the project, which is why we’re building the thing in the first place.
When we actually build a network for a project based on how people will work together, we usually see that those bins of stuff to do that were managed in categories in the WBS are actually quite mixed up and spread throughout the project. As we build our network, we need to let go of those categories in the WBS and focus on relationships and dependencies. The utility of the WBS has been served, and we can move on from there.
Which brings us to the Gantt view. It is the initial view when we open up MS Project or most other project management tools, which at some level implies that it’s the first view to use, but there are challenges with this. There are several different views we can consider for our project, and the one that lends itself better to the initial realization of the project is not the Gantt, but the network view. As we are (hopefully) collaborating to understand how we will work together to decide who needs to produce what for whom, at what time, the network view makes it easier to consider the overall picture of the project. Just as a Mind Map takes us away from the linear constraints of capturing bullet points one after another from the top to the bottom of the page, the network diagram releases us from the same constraints inherent in the Gantt view.
If we use networking techniques and release ourselves from the constraints of the WBS categories, we are much more likely to build a common understanding of how the project will likely play out. This gives us a trackable schedule, and a manageable project. I think it is best to remove yourself from tools altogether in the initial stages of planning: people in a room with post-it notes and a whiteboard produce the best project networks I have seen (and used to successful completion).
Once you have a good network that everyone buys into, then you can use the Gantt view, if that’s where your comfort zone is. Recognize, though, that as you can represent the project in these many views, it only makes sense that each will have its strengths and weaknesses. Whether it is Gantt, or network, or PERT (if you are at that level of sophistication), or even a tabular view, it is best to be well versed in all of them.
One last concern that I see with many projects is that when the WBS has been slavishly used to build the initial schedule, it also becomes the basis for reporting progress on a project. Variances will be reported against WBS categories, which tends to hide what I see as more important and relevant information. For me, the variance on the individual tasks are more important, and provide me insight that helps me keep the project on track and learn from my mistakes from project to project. Rolling this information up into categories diminishes my opportunities tremendously.
Don’t get me wrong, I think that WBS’s and Gantt charts provide tremendous value, when used appropriately. Just as with other techniques such as Use Cases, though, their overuse can actually be detrimental to a project. – JB