Stefan Kapusniak is a Senior Programmer with the Kildrummy Corporation
The Work Breakdown Structure, the Tree, the Hierarchy: it’s a powerful tool for bringing the complexity of a project under our control.
By breaking up everything that we have to manage into smaller pieces and making us define how those smaller pieces are grouped together it can, to coin a phrase, make the hard things easy, and the impossible ones possible. It’s great, it’s amazing, it’s powerful, it’s shiny. When we arrange the tracking of all the physical details of our project to fit into a structure, we can both focus right down to the smallest detail, and pull right out and see the overall summary, with numerous levels of detail in between.
Exactly what we need. In theory.
Of course practice isn’t theory. It’s still great, it’s still powerful, but when you start having to actually construct the things and apply them to your real-life projects, the aches, pains and niggles start to appear.
Not least among them, whether to break things down by Area or by Phase. Small wars have been fought over which should be used. This time we look at our project and decide Area is the most appropriate, as it’s spread across multiple sites on different continents, and move on to working out how we’re going to get buy-in from all the levels of the project to get the data that we need from them.
Then the accountant walks into room, and asks: ‘So this magical structure of yours, it can give me a view of your project by cost code of accounts, right?’
And we have to say, no, no, the structure we so artfully designed can’t give us an accountant’s eye view of the project. Of course it can’t, we didn’t build it to do that! Doh!
Can we design a structure that does both jobs? Both the tracking of our project in terms of the boots on the ground, the concrete poured, the floors of the high-rise going up, and the tracking of it in terms of all the money flowing in out that we have from the accounting side?
Well kinda, sorta… well, not really. We could hang all the account codes off the leaves of the tree, but we’d have to duplicate them across all our individual jobs. Or we could do it the other way around, have the cost codes of accounts sit at the root, and then split our jobs across the cost codes, slicing the jobs up to let us do that.
Either way, unless your accounting system and work program are miraculously in sync, it all gets pretty ugly. Notice, we’ve suddenly lost the ability to zoom up and down the level of detail. Once we go below a certain level everything turns into a noisy mush of either cost code or job duplication, and depending on which strategy we chose, we’re locked out of seeing work view or the cost view at the most zoomed out level. What to do?
You’re way of ahead of me of course.
Since the structure is just a model, why should we have to use just one model, if we’re trying to model two very different aspects of the same thing?
Aha! Now we’re thinking like real Cost Engineers. We need both views, the Work Breakdown and the Cost Breakdown, but those views don’t have to be related except at the level of those real things happening in the real world. In fact they really shouldn’t be, with the independence comes power.
With the structures being independent we can now roll values up the ‘wrong’ structure. Money values gathered from the accounting side can shown in the Work Breakdown view. Progress and completion information gathered at the work sites, can be shown in the Cost view.
Two structures then, one for the money side, and the other for the physical side. Program management Nirvana attained! Well apart from the piffling insignificant trifle that we’ve still got to execute the project. 🙂
Only, one day you start to get to wondering. You get to wondering whether that decision we made to build our Work Breakdown Structure around Area rather than Phase was a compromise we needed to make. If two structures, why not three? A Phase Breakdown, Area Breakdown and a Cost Breakdown.
Then you start seeing. You start seeing them everywhere. Multiple independent structures, the Organisation Structure, a Structure for the flow of physical documents (from budget to tender to contract to expenditure to payment), a Structure for the funding sources.
And on your next project instead of jumping straight into designing that single one true Work Breakdown Structure, instead you start by deciding which of the many possible independent Structures are going to be the important ones on your project.
Now, now you’re thinking with Structures.