The shape of the table

---

The shape of the table matters. Ask anyone who has negotiated.

Want to even the playing field? Make the table round.
Want to be agile? Make the table round.

From tables to agile? How did that happen?

One way to get agile -- or increase agility, or velocity -- is to purge hierarchy. Flat is better. Square is ok; round-and-flat is better yet. There is no head of the table. At least by seating, there's no chief among chiefs, though in every group or team some dominance will emerge.

We can extend round-and-flat to portfolios -- all projects equal; and to projects -- all work streams equal; and to the WBS: all major activities equal.

And the advantages of round-and-flat are: less hierarchy; less dominance; improved safety; shorter and quicker lines of command and communications; more lateral interaction; and close-at-hand working to foster innovation. From all this we get a better ROI: more production at less cost.

What's not to like? Really, nothing, unless you are a control person. In that case, you may be pretty uncomfortable.

You ask: what about a virtual round table? Does that work for remote workers the way it works in a co-located venue?

Not exactly.

Remote working has a slower velocity, and a poorer track record of innovation. We are social, and do our best work in a social environment. It may be only you and me; but generally it holds that even if only pairs, the paired environment works better than the sole contributor. (If you really are working alone, add some background, audio or visual: music, chat, even TV with the sound off.)

Take away message: go round!

---

Bookmark this on Delicious

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

WBS benefits

A posting by Brad Egeland entitled "Benefits of the Work Breakdown Structure" caught my eye because, above all else, the activity to create such focuses the mind and draws attention to the architecture of the project outcomes.  And Lord knows, obtaining focus is no small matter!

Creating a WBS is an exercise in disaggregation: breaking things down into pieces and parts from a top-level notion of what the outcomes should be.

However, I've found it handy to then add the pieces and parts up from the bottom and see if their summation reveals any gaps. 

That's the well-known 'V-model' from system engineering: break it down, then add it up and verify the top-down and the bottom-up come to the same project outcome.

Many recognize the 'V-model' as a variant of the well known dictum: "Tell them what you're going to tell them; Tell them; Tell them what you told them"!

That's why when I first saw Egeland's first bullet, I thought "right!", that's close to my thinking also.  But, alas, his detailed description seems to confuse schedule and WBS.  He writes:

1 – WBS forces the team to create detailed steps

The WBS forces the project manager, team members, and customers to delineate the steps required to build and deliver the product or service. The exercise alone encourages a dialogue that will help clarify ambiguities, bring out assumptions, narrow the scope of the project, and raise critical issues early on.

NO! The WBS does not delineate the steps to build anything. Actionable steps to do things are in the schedule.

If by 'steps' Brad means disaggregated deliverables, then ok. But if by 'steps' he refers to activities to achieve those deliverables, then NO.

There's no time line in the WBS, and as debated here before, no work in the WBS either. The WBS is just the proceeds of the work; and those proceeds--that is, deliverables--end at the 'water's edge' of the project.

 Bookmark this on Delicious  

Are you on LinkedIn?    Share this article with your network by clicking on the link.

Red Team the WBS

The idea of the "red team" as an independent review team was the subject of a blog earlier this month. In a few words: Red teams are indispensable to achieving quality workmanship, but they are also a good practice for defeating group think about the project deliverables.

So, it should come as no surprise that applying red team techniques to the preparation of a WBS is a no-brainer, particularly so if the WBS is part of a competitive proposal.

Fill in the WBS:

A WBS is technically an organization of project deliverables, something we call 'nouns' to distinguish them from tasks that are properly on a schedule. Tasks are something we call 'verbs'. String the verbs and nouns together and you have the project narrative.

Now, most teams use the schedule tool to schedule the tasks required to produce the 'nouns'.  Then the schedule analyst applies resources to tasks or teams, and then levels those resources by skill, by time period.

My recommendation is  to export this information and use it for ancillary fill in the WBS.

Thus, each crosspoint in the WBS is a capture point for several bits of information: the 'noun', the resources required, the hours/cost of the resources, and the organizational source for the resources.

WBS Math

Now, "WBS Math" requires that a WBS add-up horizontally and vertically. That is, the number of hours/cost should be irrespective of view. Obviously, a spreadsheet or simple database that can do the row/column math is the way to go. You really don't need to invest in a red team for the arithmetic check.

In some enterprise situations, the WBS numbering scheme is an extension of the chart of accounts, such that the resources from the schedule, as captured on the WBS, feed directly in the accounting ledger.

I like to say that the WBS is the 'present value' of the schedule; that is: the WBS has no temporal dimension, but it can be a tool for adding up all the resources identified on the schedule which, of course, should match the cost proposal, which in turn, should match the ledger roll-up of the project.

Enter the Red Team:

 But, the red team, if familiar not only with the customary practices of the enterprise, but also with the customary expectations of the customer vis a vis a responsive proposal, as well as some idea of the likely practices of the competition, can do a lot of good looking at the WBS from these several points of view.

Consider this example to illustrate the point:
Let's say we are bidding competitively and the red team is aware of the special attention that the customer pays to 'data management'. What does the red team do?

1. Look at every workpackage for data management and add up the total effort of the WBS. Does it comport with the customer's expectations? [typically a benchmark as a % of the total program]. 


2. Identify workpackages that are either over or under resourced on this activity and recommend corrections that will avoid issues that could reasonably be expected to be raised by the customer.

3. Look horizontally -- in other words, in the functional view -- to get the big picture of the data management service/function/product being offered. Can it be proposed more effectively by distributing resources differently? Are there synergies that have been missed? Does the big picture hang together and make sense to a data management professional? After all, the customer is likely to have a data management specialist who is going to take this somewhat parochial view of the WBS

4. Look vertically -- in other words, in the product view -- to see if each product is adequately covered with this product of special interest to the customer. Would it make sense to the customer's product manager?

5. Finally, evaluate the WBS against an enterprise checklist of quality attributes that comport with the enterprise brand in the market.

In sum: walk a mile in the customer's shoes by viewing the proposed WBS in the same way the customer will.

 Bookmark this on Delicious

Are you on LinkedIn?    Share this article with your network by clicking on the link.

WBS yet again

From time to time, the debate reemerges about the definition of the WBS. And so it happened again last month with a series of exchanges about 'work' vs 'the product of the work'.

This time, the fireworks began with a posting my Mike Clayton, followed by several responses from readers and critics.

In my response to Mike's post, I said:

Hey Mike: On this side of the pond, the WBS originated in the Defense Department, going back into the ’60s at least, as now given in MIL HDBK 881A, now in its upteenth upgrade and reprinting. PMI is a very late comer to the ‘definition’ game. DoD has always defined the WBS in terms of the product of the work, not the work itself. The 881A definition is: “A product-oriented family tree composed of hardware, software, services, data, and facilities. The family tree results from systems engineering efforts during the acquisition of a defense materiel item. ” You can read all about it at http://www.acq.osd.mil/pm/currentpolicy/wbs/MIL_HDBK-881A/MILHDBK881A/WebHelp3/MILHDBK881A.htm

But really, I think all the controversy can be reduced to one word: "Microsoft".

Microsoft can be blamed for everything.  Microsoft beget MSProject, and MSProject captured the market for an inexpensive and easy to use scheduling tool decades ago. Being mostly a database of tables and fields, with some application code written around it, MSProject allows the user to expose certain fields that have a built-in data definition. One of these fields is entitled "WBS".

Verbs, nouns, and narrative
However, schedules are the world of 'verbs': actions that are to be scheduled. The WBS, on the other hand, is the world of the 'nouns', things that are memorials to completed actions.

The project 'narrative' is just the verbs from the schedule put into sentences where the nouns from the WBS are the objects of the verbs [hopefully, everyone recalls sentence diagramming from the 5th grade]

Application smarts
MSProject's application is not smart enough to distinguish between the 'nouns' and the 'verbs'. So, even if you have been diligent by making the summary row a noun with the subordinate rows containing the scheduled verbs, when the WBS column is exposed all records [rows] in the database [schedule] acquire a WBS number in an indentured and sequential order. The numbering is part of the application functionality.

So, naturally there is a confusion between schedule and WBS if you do not give the field [aka 'column' in the application] a user-defined 'title'. I like 'index', as shown in the figure below, but pick your own. Caution: do not rename the 'field name' since the field name is sacrosanct in the database.

 Bookmark this on Delicious

Are you on LinkedIn?    Share this article with your network by clicking on the link.

Decoupling for threats

Here's another musing on SWOT. If you missed my earlier missive, click here.

"Threats", as given in most explanations of SWOT, are future, probabilistic, external events or conditions--in other words, risks--that could stall, cancel, or redirect project activities.

And, given this explanation, what remedy is available internally to the project? [We'll stimulate to situational awareness that should always be in effect, and could provide an opportunity to work mitigations in the external community]

The best remedy comes right out of system engineering: loosen the coupling among WBS elements, especially final deliverables, as much as possible. That way, if lightening strikes one aspect of the project, the other workpackages continue onward.

If you are a sailboat guy, it means every sail should have rip-stop seams that 'decouple' one segment of the sail from another. If one segment blows out, the whole sail is not lost if there are rip-stop seams.

There are other examples: firewalls, and diversified investments to name two more

So, how do you know if you've got loose coupling in the WBS, and how would you measure it? The system engineering measures are sensitivity and correlation. And for risk managers, there are measures of diversification, statistical independence, lack of a Bayes effect between outputs.

Sensitivity is a measure of the intensity of impact--or intensity of reaction--on one element caused by another. High sensitivity means a strong reaction to a stimulus.

Correlation is a measure of the coupling, or transmittance, of the impact from one element to another--in other words, it's the 'resistance' of one element to another. Low correlation means a high resistance to the transmittance of effects from one to another WBS element.

Diversification is a practice that means: "don't put all your eggs in one basket....have multiple baskets that are independent of each other". One basket gets damaged, the others don't. For risk managers, this is detectable in a Monte Carlo simulation: if the variance--meaning the statistic called 'variance'--of the output seems to go up and down with the number of elements in the simulation, then there is good diversification and statistical independence.

We explained Bayes in other musings. It simply means that if one project probabilistic phenomenom affects the probability of another, there is a Bayes coupling of probabilities from one to the other. There are ways to measure the Bayes affects, and most risk managers are aware of how to do it.

Have someone check out your WBS: you might be able to avoid a lightening strike!

 Bookmark this on Delicious

Are you on LinkedIn?    Share this article with your network by clicking on the link.