Book Review: Breaking the Code of Project Management

Breaking the Code of Project Management
Alexander Laufer

The genesis of this book come from Laufer’s observation that traditional project management principles need overhauling.  He argues that the growing realisation of the power of empowerment, the poor historical record of project management, the flawed foundation of a major project management tool (PERT), and ‘emerging paradigms’ in research and practice require a new investigation into what is needed to ensure project success.

Laufer is big on using stories as a means of learning and presents his reasons why.  The book brims with stories.

It gave me some discomfort when Laufer referred to the ‘Agile method’ as a ‘project management approach’, given its limited focus on product development (primarily software products).  He also makes the mistake of referring to the ‘four values’ (a pet peeve of mine).

No project management tools appear in this book.  You won’t find discussions of the WBS, PBS, Gantt Charts.  The focus is on what it takes to deliver projects successfully.

Laufer concentrates on what he calls ‘Results-Focused Leadership’, a framework of guiding principles, colour-coded for vividness: yellow for the spirit of will to win, green for planning, brown for implementation, red for people and organisations, and grey for communications.

Recommendation: A practical book on how to deliver projects, yet very different from the standard project management books which cover the tools and principles of project management.  It almost ignores traditional project management.

PROJUCT MANAGEMENT

With a slip of the tongue, I came up with a wonderful, terrible portmanteau:

"Projuct". Defined as the product of a project.

*** 

Book Review of ‘Fundamentals of Project Performance Measurement’

This short book (119 pages) covers the basics of measuring project progress via earned value management.

The author (Robert R. Kemps) argues that you cannot measure project progress simply by monitoring cost expenditures versus budgeted expenditures. If your actual expenses by a certain date is less than the budgeted expenses by that date, that information doesn’t really tell you anything – are spending less than expected or are you simply running behind schedule? Adding the work completed to the measure gives you better understanding: you can now tell why your project is spending less than expected. It could be because, some of the work that was expected to being had not yet begun.

Kemps also underlines the importance of technical performance as the third measure to factor in. Just because work is reported as being complete does not mean it is complete.  Unfortunately there is not much information in the book as to how to measure technical performance besides ensuring that it is tracked.

A baseline is important, the author asserts, because without it, the integrity of the project progress measures (and by extension, project management), is at risk, because readjustments to cost and schedule and technical performance leaves no trace behind.

It lists neither references nor a bibliography.

Recommendation: A basic book on earned value measurement, useful as an introductory reference for both the motivation behind earned value and how to do it.

The Work Breakdown Structure (WBS), part 2

Since the WBS is a hierarchical structure, it has bottom level parts.  The WBS can be constructed like a table of contents, like so:

WBS Item 1 WBS Item 1.1 WBS Item 1.2 WBS Item 1.3 WBS Item 1.3.1 WBS Item 1.3.2 WBS Item 1.4 WBS Item 2 WBS Item 2.1

The lowest level items (shown above in bold) are called ‘Work Packages’.  The Work Packages are discrete pieces of work to be assigned to someone in the project, perhaps an individual, a business unit, and internal, team, or a contractor.  The key is that there is someone responsible for delivering the Work Package.

WBS’s should be oriented towards the deliverables, not towards the functional groups.

The reason for breaking down the project into smaller work packages is for management and control. 

The smaller a piece of work is, the easier it is to estimate how much time is needed to do the work.  Work packages also facilitate the scheduling of the project. The work packages can be the components mentioned in the master schedule. Work packages can be scheduled individually, and the resulting duration be fed into the master schedule, which only shows the work packages.

It is also easier to estimate the cost of smaller work than bigger work.  To estimate the cost of the project, just estimate the cost of each individual work package and sum them up.

The WBS is often claimed to be the backbone of the project, and some writers have said that project failures can be traced back to faulty WBS’s:

“Component or full-project failures, when they do occur, can often be traced to a poorly developed or non-existent WBS”(Norman, Brotherton, and Fried, "Work Breakdown Structures: The Foundation for Project Management Excellence")

The Work Breakdown Structure (WBS)

After the Gantt chart and the network diagram, there is perhaps no other project management tool that is more ubiquitously discussed than the WBS. 

As the Gantt chart is the primary tool for documenting the project schedule, so is the WBS the primary tool for documenting the project scope.

What is a WBS?

The PMBOK Guide describes the WBS as “a deliverable-oriented hierarchical decomposition of the work required to be executed by the project team to accomplish the project objectives and create the required deliverables.” 

That is, the WBS, “defines the total scope of the project.”

According to this definition, the WBS is a “decomposition of the work required”. 

But work required to do what? There are two kinds of work:

1. Work required to accomplish the project objectives
2. Work required to create the required deliverables

Together, these two kinds of work define the sum total of all kinds of work required: all project work falls into at least one of these two.  We say at least, because it is possible that some piece of work can be properly thought of as belonging to one or the other – that is not a matter of great concern.

The first kind of work is about work that need to be done in order to successfully complete the project objectives, even though they are not the purpose of the project.  An example of this type of work is developing the project schedule (which is needed to help attain project completion date objectives).  Other examples include developing a WBS,  supervising the work-force, and conducting project communications.

The second kind of work is covers what’s needed to deliver what the project needs.  Examples include designing a piece of software, integrating components, reviewing the quality of sub-components, and testing the components.

Note that the WBS is “deliverable-oriented”, but it is not a compilation of the deliverables.  It is a compilation of the work required, hierarchically organised around the deliverables.  The star of the show is the work, not the deliverables.

A software development project with the goal of delivering a commercial software product (and nothing else, not even documentation), the list of deliverables will not change, whether you use an Agile approach or a waterfall approach.

However, the WBS for the Agile approach will be different from the WBS of a waterfall approach.  Examples of the differences include:

• The Agile WBS will include such work as ‘Write User Stories’
• The Waterfall WBS will include such work as ‘Develop Design Document’

The deliverable is the outcome, the work is the effort and activities required to produce the outcome. 

Given that there are many different ways to produce the outcome, the WBS is a reflection of the plan chosen to produce the outcome.  Change the strategy, the WBS can potentially change.

THE TRIPLE CONSTRAINTS ANOMALY

You cannot possibly be a project manager and not have heard of the term 'Triple Constraints', and the surest sign that you are a novice project manager is your belief that the Triple Constraints is made up a 3 things.

That is one of the odd things about this term.  Originally, it was indeed about three constraints: Cost, Time, and Scope – project and programme managers have to deliver the goods (Scope), within the budget (Cost), within the schedule (Time).

Later, thinkers thought to add 'Quality' because well, sure, you can deliver the goods, but are the goods you deliver up-to-spec?. So the Triple Constraints began to consist of four items.  There are some heretics (or perhaps they are prophets of wisdom) who insist that Quality is just part of Scope, and ought not be considered separately from the other.  The argument is, if you delivered 600 green umbrellas rather than the required 600 red umbrellas, it is not a 'Quality' problem but a Scope problem – you simply didn't deliver what was asked for.

Project managers with more than a week experience, began to realise that despite their personal charm, the world doesn't revolve around them or their naive assumptions. 

Things go wrong.

"We need to add another constraint - Risk", came the chorus. And so the Triple Constraints became five (and have to be redrawn as a pentagon – we are not geometrical ignorami, after all)

Courageous project and programme managers soon began to point out their specialty: delivering goods within the constraints of time, cost, scope, quality, and risks. There is no need to be mean-spirited by reminding them that postmen and newspaper delivery kids and mothers and housewives, have been doing the same since the invention of anything.

But no matter how well we think we manage the five constraints, projects still tend to head south, and so we need another constraint to lay the blame on.

Resources.

"Surely Resources are a constraint!" came the battle-cry of the project and programme manager. "Even if I have a budget of $50 million if I cannot find Fortran programmers, my Fortran project cannot succeed." And of course, when they burn up my $50 million without delivering anything, they can point to the incompetent resources they had to work with. 

But let's take a step back (after first checking we are not on the edge of a cliff; risk management in action).

We can take the view that the constraints are about what a project manager has to deliver against. Or we can take the view that the constraints are 'natural' limitations that enterprises have to balance when deciding which projects to undertake.

We want to finish the project as soon as possible so we can reap the benefits and start other projects as well. But to finish faster means applying more resources. This is a natural constraint in our world.

We want to do it right the first time, but it will mean more time and more cost, so we may need to cut a little bit of scope here and there. Another natural constraint.

We want to deliver the project as cheaply as possible, but if we put a limited number of resources will take the project that much longer to finish. Another natural constraint.

I think the Triple Constraints are about having the enterprise (not the project manager) balance between the 3 (not six) constraints.  The project manager, for his part have to deliver the Triple Constraints while working through the constraints of Risks and Resources. (Quality is part of Scope).

Project management

Any undertaking, no matter how small, faces the possibility of taking longer than anticipated and costing more than expected. In addition, there also exists the danger that the job will not be done right. Or if indeed done right, was not what we thought was needed.

The bigger the undertaking, the bigger the likelihood of unwanted problems occurring.  The culprit is complexity.

Consider the undertaking of changing your shower curtain versus the problem of defending Normandy beach from Allied invasion.  Yes, you might slip on the floor and bang your head while doing the former, many, many more things could go wrong in the latter (and many did).

One is more complicated than the other. It is this (vast) difference in complexity that makes the other undertaking much more likely to have potential problems. Complexity is like having open doors and windows where problems are free to let themselves in. The more complex the undertaking, the more numerous the open doors and windows.

We could stay small and be content with simple undertakings, but our society's progress will be limited. We can choose to limit our undertakings to nothing more complex than mastering the art of candle-making, but our society will not progress much. If we want progress, we have to face complexity. 

Fortunately, we have tools at our disposal. 

Look at the skyscrapers and other technological marvels we now have.  Science and engineering has progressed such that it is now possible to design buildings that will not randomly fall down. We now know how to design such buildings. Complexity and its associated problems have been reduced by scientific and engineering knowledge.
But we like to push the envelope, and so complexity remains.

Every undertaking requires activities. No activity, no undertaking. The more complex the undertaking, the more numerous and varied the activities are.

Activities depend on and interact with other activities, and therefore must be coordinated. Those who need to fit glass windows to a building cannot start working until the building structure has been built. Those who need to test software cannot begin until there is some software to test.

Knowing how to design a building is not the same as knowing how to organise the activities required to build that building, and vice versa. They're not the same thing.  The training, skills, and mindset is different. The orchestration of these activities demand a different kind of knowledge, attention, and discipline from that required to design a building.

To harness the benefits of science and engineering, there is another discipline that was developed to help us with our complex undertakings. This discipline is intended to help us manage the activities and ensure that:

• We can have a confident estimation how long a undertaking will take, so we can plan for it.

• We can have a confident estimation how much the undertaking will cost

• We can identify the activities required to complete the undertaking.

• We can ensure that the undertaking will take no longer than planned

• We can ensure that the undertaking will cost no more than planned.

• We can ensure that the undertaking will be completed.

• Everyone's valid expectations are met.

That discipline is called Project Management.

Is managing a project like conducting an orchestra?

Managing a project is so frequently compared to conducting an orchestra that the comparison has almost become a cliché. 

I understand the comparison. There is a slight similarity between conducting an orchestra and managing a project. The similarity lies in the fact that both the conductor and the project manager do not make the actual product. They simply orchestrate the work of those who produce.: a conductor controls the performance of many different specialists, combining the individual performances into one single harmonic product.

There are a couple of key differences though.

The first difference is that an orchestra has had time to rehearse and practice over and over exactly what they are supposed to do. Indeed, they must refine their work until it is flawless, before the actual live execution.  A project team hasn't got that luxury.  It has only one pass at executing the project.  

An orchestra will never be asked to work faster, redo a task, or cut the scope of a musical piece.  There is no such thing as crashing the music by playing faster.  Project teams have deadlines to meet and often need to redo work and work faster than normal.  An orchestra performance is an operation. It is perhaps the smoothest of operations.  There is no change of plans.  The audience's (stakeholders) mood will not change what the orchestra will play or how they play it.

But then again, why use a conductor as the focus of an analogy? Every orchestra presentation has an actual project manager orchestrating it, scheduling the rehearsals, picking the team, picking the conductor, selecting alternate members, etc. 

I think a more appropriate example is that of a coach in a basketball game.  The coach does not deliver the points, he manages the team so that they deliver the points. 

An approach to planning

Planning a project involves identifying the activities required to deliver the project and the inter-dependencies between those activities.  These activities and the dependencies are then modeled onto a network diagram.

Task duration estimates are often padded, as a matter of good practice, but also as a matter of covering one's behind.  Things often don't go according to plan and one has to allow for that.  If I estimate that task A will take 10 days, and I say it will take 10 days, and then something goes wrong, then not only do I look bad, I might also I end up delaying the next task which was set to begin 10 days later.  So the common practice is to be generous with our estimates and pad them for contingencies.  Such padding implicitly addresses the risks faced.  

There is another approach that integrates project schedules with risk management, and at the same time highlights the possible sources of these risks.

One way to bring this planning to a different level is to first make a realistic and optimistic estimate of how long each task will take.  Let's say if a task will take 7 days if no problems occur, then we start with 7. We do the same for each task. Then we study the task and its dependencies and try to understand what could go wrong that can cause its accomplishment to exceed 7 days.  Then we try to address those things that can go wrong.

Let's say the person executing the task will normally take 7 days to accomplish the task, but has other stuff on their plate, so may take more that 7 days to complete the task.  Why?  Because their time and attention could be diverted to the other tasks.  If we don't highlight this reason then we can't manage it.  Suppose we identified that this person really has other stuff on his plate, then we can take steps.  We can schedule his task to be done after he has finished his other stuff, or we can arrange things so that he suspends work on other stuff, or we can just accept things as they are and simply pad the number of days.  At the very least, we have identified a possible cause of problems.  

There could be other factors to consider: this person could get sick during that time, their machine might break down, they could misunderstand the specifications,  or what's required of them and then we will need to redo things, and so on.

By thinking through the possible reasons for exceeding the optimistic estimate, we begin to identify possible causes of delays and we begin to be able to plan for those causes: try to minimize their chances of occurring, minimize the impact if they occur,etc.

***

Tip of the Day - Estimating

When scheduling any task, especially a time-consuming task, it is always prudent to assume the task will take longer than you expect.  

Things happen.  

Therefore, add an allowance as a contingency.

This is not padding schedules for the purpose of billing higher.  Neither is it about covering your behind and ensuring you deliver before the target date.

It is simply common prudence.

If you believe a task will take 3 days and you promise to deliver it in 3 days, whoever is depending on your task may decide to commit himself to starting their task 3 days later, on the assumption that you will have delivered by that time.

If you fail to deliver as scheduled, then he will probably fail to deliver his task as well.  This chain could go on through to several persons.

Not adding a contingency to your estimate is not merely being gung-ho, it's plain irresponsible.

In addition to adding a contingency to your estimate, however, you must also be prepared to work on the next task if the current task gets completed sooner than scheduled.

Project Management

Every undertaking, faces the possibility of taking longer than anticipated, costing more than expected, and or not completing successfuly. The bigger the undertaking, the bigger the likelihood that unwanted events and outcomes occur.  One key culprit is complexity.

Consider the undertaking of changing your shower curtain versus the problem of defending Normandy beach from Allied invasion.  You might slip on the floor and bang your head seriously while doing the former.  However, many, many more things could go wrong more seriously in the latter (and many things did go wrong).

Launching an invasion is more complex than changing a shower curtain. It is this (vast) difference in complexity that makes the other undertaking much more likely to have potential problems. Complexity is like having many open doors and windows where problems are free to let themselves in. The more complex the undertaking, the more numerous the open doors and windows.

We could stay small and be content with simple undertakings, but our society's progress will be limited. We can choose to limit our undertakings to nothing more complex than mastering the art of candle-making, but our society will not progress much. If we want progress, we have to face and deal and master complexity.

Fortunately, we have tools at our disposal.

Look at the skyscrapers and other technical marvels we now have.  Science and engineering has progressed such that it is now possible to design buildings that will not randomly fall down and will even resist powerful earthquakes. We now know how to design such buildings. Complexity and its associated problems have been reduced by scientific and engineering knowledge.

But we like to push the envelope, and so complexity remains.

Every undertaking requires activities. No activity, no undertaking. The more complex the undertaking, the more numerous and varied the activities are.

Activities depend on and interact with other activities, and therefore must be coordinated. Those who need to fit glass windows to a building cannot start working until the building structure has been built. Those who need to test software cannot begin until there is some software to test.

Knowing how to design a building is not the same as knowing how to organise the activities required to build that building, and vice versa.  The orchestration of these activities is also different and demand a different kind of knowledge, attention, and discipline from that required to design a building or build a building.

To harness the benefits of science and engineering, there is another discipline that was developed to help us with our complex undertakings. This discipline is intended to help us manage the activities and ensure that:

• We can have a confident estimation how long a undertaking will take, so we can plan for it.
• We can have a confident estimation how much the undertaking will cost
• We can identify the activities required to complete the undertaking.
• We can ensure that the undertaking will take no longer than planned
• We can ensure that the undertaking will cost no more than planned.
• We can ensure that the undertaking will be completed.
• Everyone's valid expectations are met.

That discipline is called Project Management.