The project triangle re-jigged

I fluctuate between supporting or avoiding the 'triangle' project badge. My no. 3 post on 'the sensible 12' touches on supporting with modification. But its hard to get past Glen Alleman's representation of the triangle: more informative and more useful, in my view, and including risk in the project structure, just as it should be.

For convenience, the diagram is copied below.

The Sensible 12: No. 3

3. The scope, budget, and schedule must remain balanced throughout the project.
In project management there is a key concept called the triple constraint or the project management triangle. The idea is that while managing a project the project manager must keep three constraints in balance; the scope or work that is required to produce the projects end results, the amount of time required to perform the work, and the cost or budget for the project. Scope, time and cost are almost always competing constraints. Typically, you cannot change one constraint without affecting one or both of the other constraints. The key principle is that as change happens, you must keep these three constraints balanced.

As a rough rule of thumb the 'iron triange' is a useful aphorism, but it is not good business to take just a 'cost' view of a project. Any project is an investment of resources and effort over time; the investment has to give a return to the investor that is better than alternative investments. The question is investing to produce business value through achieving the required performance (or delivering the required capabilty).

Sure, any project decision will have implications for expenditure, delivery and performance, but 'scope', 'budget', and 'schedule' is only part of the story. The project manager has to manage the whole story, including the value sought to produce the investment return. The PM has to be concerned with the outturn value of the project as a result of the delivery efforts.

So, I prefer to frame a project as investing (cost) to deliver (schedule) capability (scope) to maximise return (value).

Let's go 'all thumbs' on this one.

While I'm on the fumble theme, another project nightmare. But worse, ye gods: this one killed people!

It wasn't crippled by 'dodgy' installers. It was crippled by rushed policy, lack of industry consultation, imagining that a group of politicians and their child advisors could just jump into a business, no evident risk management...they didn't even appear to know that there were risks. It was hubris writ large!

And this in a country with a sophisticated construction industry with architects, building professionals (the white collar guys I mean) and engineers like grass seeds: everywhere! And, I might add, a public service that, at least in the states, includes highly industry-aware staff that design industry engagement schemes day in and day out, and successfully.

How more wrong could it go?

In my local municipality, the council has been building a re-developed aquatic centre for nigh on two and a half years (give or take) for a project of, about $12m.

It is badly over due for any reasonable completion time (it was advertised as 12 months), having commenced in January 2012 and has attracted attention as a result. Understandable given that multi-hundred million dollar retail centres don't take that long!

The council has explained it thus:

The construction is a complicated project and is taking longer than expected due to a number of factors including:

• earlier wet weather during demolition and excavation
• poor ground conditions
• the unavailability of key construction components including the pool hall roof, forcing a redesign,
• tweaks to the design along the way brought about by design clashes and improvements being incorporated into the final product
• and the availability of the key subcontractors that will make this a quality product.

Now, an acquatic centre, while moderately complex, is a well known type of facility and should be able to be reliably delivered.

Just looking at the council's explanations for delay, it looks like a few fundamental and frequently made mistakes may have occurred:

'Tweaks to the design' and 'design clashes: They scream out "we rushed". Not enough time or effort into pre-construction, we did the design on the cheap, we didn't let the consultants use 3D clash detection, we probably didn't budget properly and we didn't have effective project launch workshops (links to three firms I've dealt with).

Wet weather? There's always wet weather, and we should always allow a delivery contingency for it. Not merely a 'stab in the dark' but something that's based on meteorological records. They're available for free from the government!

Poor ground conditions? Basic risk; that's why we do ground tests and retain geotechncial engineers, then use them to guide footing design. Skip this step and you are up the creek before you know it.

Contractor availability? Basic procurement risk mis-management. Or was the head contractor on such a skinny price, that he didn't have a secure hold on his subbies? Either way, the liquidated damages provisions of the contract should ensure that the rate-payers get their damages back.

Component availability? Design management not done well for this to occur. Were the 'hard to get's' specified instead of practical design being the objective? I don't know, but in a mature industry, I'd think that one has to go out of one's way to specify components that would bring delays.

None of which is, as they say, 'rocket science', but good building project practice that has been developed over decades. There are plenty of practitioners who would have easily got it right; but then, that requires an investor that will take advice; and that may be the nub of it. Particularly when the investor is not familiar with the building type.

The Sensible 12: No. 2

2. Planning is critical to success.
The most critical part of a project occurs during the planning stages. A successful project is preceded by careful planning including the identification of the tasks which when executed will meet the vision of the project and deliver value to the customer. The plan should include provisions for impending risks to the project as well as contingency for unknown risks. Additionally, it is wise to be prepared for and be aware that change will be introduced into the project…be prepared to change the plan.

Risk management is usually a tack on to a project, but planning has to include uncertainty: and that gives rise to risk. So the plan on any project of any decent size has to allow for the variability of estimates of cost and time for completion of project activities. The 'contingency' for unknown risks is wishful thinking. We don't know, so how do we allow for it? We can only reasonably allow for what we know of the type of project, but cannot evade the investor's risk that all projects have. It just might not work that way! How could Sony have 'managed' the risk that the market would prefer VHS to Beta video taping?

Planning flows out of project definition and relies on a high degree of certainty of understanding of the capability that is required of the project.

Project dimensions

Looking on the web-based project management offerings, I'm coming to think that many are designed for projects that I would regard as trivial: you could manage them with either bits of paper, or Excel. They don't seem to lend themselves to what I regard as a serious project. For me that means large construction projects: retail, industrial and institutional projects of at least $100m.

The life-blood of managing these projects is the information torrent.

Matters of schedule, expenditure and performance are there, of course, and set the 'tempo' and objectives of the project, but to get things done, information management is what happens day in and day out.

I conceptualise these projects along two basic dimensions: the project breakdown, and the work breakdown. For spatially large projects there's a spatial breakdown too. For example, a retail centre will fall into a number of organising zones: food court, groceries precinct, major boxes (for the large department stores), fashion precinct, car parking (which will be subdivided in most cases by location).

An industrial complex might fall into warehousing, administration and amenities block, production, packing and distribution.

Hospitals fall into a number of units too, for large campus developments: medical services, wards, ancillary services, research and education wing, etc.

Dimensions

The two basic dimensions which apply irrespective of size are the project elements (the parts of the project) and the work packages (how the parts get delivered).

Elements are unrelated to schedule but organise information, work packages are schedule related and organise activity.

In projects I've applied this scheme to I've thought that the hierarchy of elements can only realistically go 3 or 4 deep, and not across the whole project, or its gets unwieldy. In practical terms the hierarchy has generally been 2 deep, elements being subdivided into items, such as the element 'external works' broken into items: site preparation, bulk excavation, paving and line marking, planting, site services (lighting, drainage, water reticulation, service mains, services diversions, security and communications), retaining structures, fencing, signage.

Work packages are large units of work that deliver a completed project component, or sub-project in some cases.

A work package is delivered through 'activities' (these are the things that usually appear in a scheduling application like Primavera, they roll up into work packages, or summary activities quite easily).

To complete activities a number, sometimes a large number of tasks are done, such as the activity 'clear site' might require the tasks: remove vegetation, protect structures and trees, remove refuse, install siltation barriers, etc.

In summary we have: Elements --> Items; Work packages --> Activities --> Tasks.

Thus, one can see how trivial Web-based 'project management' applications that facilitate 'tasks' have to be; they do not and often cannot put tasks into a useful project context.

Now, how do they relate?

Using examples from construction, in some cases a work package will be identical to an element. For example, the 'external paving' element could be delivered by a single work package for paving (although at the element level, 'external paving' could comprise both vehicular and pedestrian paving, which could be two different work packages, or more, delivered in different locations or at different times, even if done by the one contractor). In some cases, a work package and an 'item' might have identical coverage. More usually an element would be delivered through a number of packages: 'external envelope' could be delivered via work packages for brick laying, curtain wall, glazing, external doors, louvre installation.

Some of these might be items. The item 'external doors' would usually be delivered by a single work package.

Activities could be aligned with 'items', but this would not always be clear cut. The item 'external doors' could be delivered by a package for external door supply and installation, but the item 'water mains' might be finally delivered through a number of work packages: site clearing, bulk excavation, trenching and shoring, mains diversions, pipe laying and connections. In brief, work packages tend to relate to elements, and tasks typically relate to items, but they are not always 1:1 relationships and one does not always exhaust the other.

'Elements' and 'items' serve as means for compiling related production data and project information for consolidated views of the project by its management and delivery teams.

For the manager, the two hierarchies allow selective visibility of progress, but allow risks, issues, documents and changes to be attached to elements for a comprehensive view of factors affecting the project at any time.