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.

The Sensible 12: No. 1

The Sensible Project Manager provides a set of 12 Principles of Project Mangement. This is way more than Glen Alleman's 5 Immutable Principles, so...is that better or worse, or just different?
Over the coming weeks I'll comment on each of the 12, with the first now:

1. The project vision must be clear and agreed to by the stakeholders.
The first principle to success begins with understanding the vision or goal of the project. There is a reason the project was initiated and the project manager as well as all stakeholders must understand the business need and what success looks like. Make sure that all stakeholders understand and agree to the project vision.

This looks right, but the language is too fluffy to turn into action. What is a 'vision' when it comes to a project? Better that a project have a clearly defined busines value with the means of realising that value built into the project. The project must have a stated mission to achieve, and a definition of the capabilty that the project will produce.

This will flow straight into the funds that can be made available, it sets termination criteria to avoid throwing good money after bad for a project bound for failure, and allows objective acceptance when 'done' is achieved.

Vision is fine, but you'd better know what the capability of the product will be and its cost if you want to stay in business.

Then, as part of the work of the organisation, the project has got to be supported by the organisation as a whole, otherwise mission critical will be turned into mission aborted. The IRR on aborted missions is a negative number!

Wrike

Letter I sent to the people at Wrike:

I've had a quick look at Wrike, and like what I see.

Wrike seems to conceptualise a project as a set of tasks, rather than an information flow. Thus information about a task seems to have to be stored at second hand, in an attached document, and is not directly accessible from a task or a folder.

Incidentally, the use of folders for multiple representations of the project is very flexible.  I would use this to organise a project by phase, static element list (e.g. 'design'), by dynamic element (e.g. WBS element, where I'd like to be able to see hierarchical summaries), supplier, functional component, etc

But, back to the information content of a task. A task will have a number of basic information parameters: obviously name, description, WBS number, cost code, RAM nominations, antecedents and dependencies, which are metadata-like, then substantial data such as performance and acceptance criteria, issues, progress notes, risks (derived from a separate 'risk breakdown structure'), Requests for Information, Answers to Requests, decisions, pending antecedents, change requests, etc, each of which will have a status and need to be tracked and reported upon.

Being able to review a project on any of these items could then be facilitated. For example, the number of pending tasks with outstanding change requests, or overdue decisions, or unresolved issues could be looked at anywhere in the WBS hierarchy, or by project element, assigned manager, etc.

I didn't see how Wrike managed communications, including logging emails, which I would guess would be possible, maintaining project requirement sets, meeting  minutes and review lists that were linked to project components and not as binary blobs (ie attached text, spreadsheet or tabular documents that need their own viewing application). In complex projects tracking document issue, receipt and revisions is  vital. I couldn't see how I could do this in Wrike, nor how even simple configuration management could be done.

Project context may be a factor here. My project area is multi $100m property development projects that might take a few years. The illustrations on your website seem to be in other domains.

Flash Blog on PM

A late and uninvited participant in the international 'flash blog' on "what project management means to me".

Simple.

Getting things done through people.

Same as general management, of course, but the things either handle or creating a change in the business environment to attain or sustain a competitive or customer service advantage, defined as broadly as you like.

Here's Glen Alleman's take on it.

The risk in risk matrices

Not only did the consultant-led risk workshop start with a limp, it also ended with one.
For all practical purposes, it drew to its conclusion with the obfuscation of using a matrix to locate risks in a two dimensional space with dimensions 'likelihood' and 'severity'.

The problem with this was in neglecting to deal with the simple measurement error it gave us a result that was misleading; potentially so misleading it was no better than no result at all. The risk cells between different risk intensities have a natural error. That is, while they are bounded by lines, they should in fact be bounded by indeterminate zones where we cannot know the location of a risk.

This means that in a typical 4 x 4 matrix, it is not possible to distinguish between cells that touch at a corner.  But it gets worse: depending on the uncertainty between risk zones, it might be impossible to distinguish between cells one row or column apart in adjoining columns or rows. That makes the exercise pointless, and can lead to gross over- or under-allocation of resources to risk response.

Cox has examined this problem in detail, as discussed by Awati. Alleman also discusses uncertainty in projects.

As Gerd Gigerenza says (Helping Doctors and Patients Make Sense of Health Statistics), the first step in statistical literacy is understanding uncertainty. In risk analysis, above all, there should be some recursive application of uncertainty to that process that is established to deal with uncertainty. Physician, heal thyself!