I Have Mastered the Art of Talking to Myself Without Moving My Lips

Hey, don’t laugh, it’s a key skill. The only creepy thing about it is I can look at someone right in the eye and be muttering to myself at the same time. And even though I have at least another 40 years before I’m at that station in life where muttering is just something you do,  I’m getting an early start because I’ve discovered that it has high value.  I’m not the first to discover this, as it turns out. Experiments have been done to prove that regularly talking to yourself is a positive thing: http://newsfeed.time.com/2012/04/25/talking-to-yourself-may-actually-be-a-good-idea/.

All the scientific research aside, the value I get from my outward-inner-dialogue is the art of practicing my next line.  That’s because I so often find myself in boardroom meetings with very passionate people.  Which is probably not that uncommon.  What’s also not uncommon, is that the people in the room don’t all share the same views. They can be passionately expressing opposing views with each other while earnestly trying their best to do what’s best for their company.  I, on the other hand, am an outsider invited in – and I’m equally passionate about trying to mediate them towards achieving the ideal solution to some often delicate challenges.

The muttering comes in handy because I can try-out ideas out loud, so to speak, before I actually say them. It’s funny how things can sound so different in your head, compared to how they sound when they’re actually spoken. Or mumbled.

About a week ago I was a participant in a very heated debate on a company’s policy towards the layout of their standard work breakdown structure for their projects going forward. They were growing and winning bigger, more complex projects, and needed to improve how they planned, estimated, tracked and reported on those projects. The good people in the room were looking to gain some agreement on the level of detail needed in their WBS.  Designing a good work breakdown structure is arguably one of the most important exercises a project manager can do – so I was very much on board with the effort they were undertaking. Of course, good WBS design is a topic that can be debated on to the ends of the earth – and in many respects boils down to the needs of the company and project. Below are some of the points they were debating.

High Granularity

The upside of creating a very detailed WBS is that it provides for:

1. Better information at a more granular level
2. It improves the quality of project estimates
3. It provides better clarity for measuring progress and improved earned value management metrics
4. There is a much better chance that the cost codes at all levels (workpackage, phase, etc.) will provide meaningful reporting

Low Granularity

The downside of creating a detailed WBS is it’s much more cumbersome to manage:

1. When it comes to tracking: having too many tasks to track against can introduce errors and omissions.
2. When it comes to cost code definition: having too many cost codes can lead to an overload of information. While this can be nice to have, most organizations don’t have the discipline or resources to make good use of that information

Although the people in the room were aware of the value that a detailed WBS provides, they were also worried that they don’t have the strict internal processes to make good use of it – and it would become a mess.  These are all fair points.

My internal-talking-out-loud-dialog system was working that day as I listened to them and prepared my interjections. I’m not about to sit on the fence, so I have to take a side that I think is the right thing for them to do – which means a delicate maneuver of trying to make everyone feel okay about it.  I’m ultimately on the side of building a WBS that captures the most meaningful information down to the workpackage level. Each workpackage (task) should be able to be sized and therefore measured and progressed. WBS items that are too generic and designed as buckets are not as useful.  I don’t want to get into it too much in this small article, but that’s the general gist of where we took it.

I explained to them that with our software, they can design a good, detailed WBS, but assign their labor resources to specific tasks/workpackages for tracking. That way, when people are entering timesheets, they only see the small fragment of the WBS that is relevant to them. This eliminates the potential for logging cost to the wrong place. They can additionally create alternative WBS Views that compress what’s shown on the WBS to a more controlled and high-level perspective. I also showed them how the tracking of materials, subcontractor payments and equipment, is managed by the pre-defined cost code, and the people preparing and tracking the purchase orders don’t need to even see the WBS. That part is predefined by the project manager, engineering and/or project controls teams. With these manipulations, the WBS is then effectively sectioned-out, so that only a privileged few actually see the full breadth of it.  Then, when it comes time to measuring progress and calculating earned value management numbers, the rules are more clear because the workpackages have been pre-designed to be measured.  We also got into how this influences the estimating, budgeting and the need for good cost-code strategies, but those are topics for another day.

I’m always interested in hearing people’s experiences around these topics. Do you have a good WBS design approach you’d like to share. Do you talk to yourself? How do you feel about that?