The Sensible 12: No. 4

4. The project must deliver a quality product or service.
There is no sense in embarking on a project unless the quality of the product or service that results from that work meets or exceeds the expectations of the customer. Even if the project is delivered on time, within budget and with the defined scope, it will be a failure if the quality isn’t there. Quality should be considered from the beginning of the project and at the forefront of everyone’s mind throughout the project.

Quality is a fake forth factor in projects. The only 'quality' is that the technical performance is delivered when required to produce the return sought (they always go together). There is no separate 'quality' parameter!
If technical performance is not achieved, the project is not 'done'. "Quality" then becomes an irrelvant overlay.
For example, a door has to stay on its hinges and latch shut when closed. If it does not  do this, then it is not that it is a 'poor quality' door, but that it is not functioning as a door at all. There is no door if the lump of wood won't swing on hinges and latch closed.

The project machine?

In his post on Better Projects Jon Whitty reports on a mini-experiment that he ran (write up here) on people's drawn responses to projects: kind of like art-therapy, I suppose.


He said:

What I discovered from this simple experiment is that our perceptions of project work is (sic) massively distorted by the various common artifacts (billboards if you like) of the project management community. The Gantt chart is a prime example. It reflects very little of the project experience ahead. An itemised to-do-list would do a better job. And in many cases I’ve found this is actually what is used.

It would indeed be a concern if people mistook the artifacts of project management for the conduct or the outcome of the project! It's also amazing that a gnatt chart and not a network of some kind is the representation of choice for a project's activity sequence.

If people are so wary of gantt charts, I am led to wonder if a quantified delivery risk is applied to each activity, or each work package, and if this is accumulated at stage gates for tracking (as per the critical chain method), and if there is a firm grasp of the outcomes and how they are to be firstly achieved, then measured. That is, what do we need to do and how do we know we've done it?

But, more than this disquiet, the enquiry betrays a machine view of projects, when this is as far off the mark as one can get.

It is naturally possible to model and run a project using some machine like representations, but these are only the documentation of a community process and represent an abstraction required for the organisation of the more intense and responsive discourse and joint action. And, no, I'm not going 'touchy-feely' in using this language, but being fair dinkum. A project is done by a collection of people, in various contractual relationships moderated by a joint desire for (mutual?) success. It is this informed interaction that gets projects done. It is the work of, what I like to call, a 'community of intent'; characterised by communication to find resolution and progress.

This has attracted various terms over the years, but I find the thinking that Hal Macomber used in his Reforming Project Management blog, and that David Ing at Coevolving Innovations refers to to be on the right track.

Just think about a project you've been involved in (I mean a serious project, not the kiddie stuff that recruitment agencies sometimes refer to): if it is anything like one's I've worked on, it is run by lots of meetings and less structured conversations, a zillion e-mails and phone calls, and a high degree of flux; sometimes at a frenetic pace. All this is done in the light of the theme expressed in the formal documents and representations; which, in a well organised project, will be updated continuously and in the light of the outcomes sought and risks met and dealt with.

In many ways this is like the work of general management (see Henry Minzberg's various writings on what a manager really does); its artifacts are similarly uninformative about the work: cash flow statements, production schedules and balance sheets; but few people mistake these for the business.

Jon gets down to the to-do list and hangs his hat on it. Well of course. Day in day out, its a simple list of what you need to do, or what the project needs to achieve that lubricates activity. In construction this is the 'look ahead program' (a similar concept is commercialised in the Last Planner method): the next two or three weeks' rolling schedule done in great detail to co-ordinate interfaces between work packages and project events.

In my experience a project is produced by the complex information flow between participants, organised, themed and paced by a set of artifacts that recognise the limits of information and contraints of risk properly quantified and expressed.

If you want to talk to upper management about a project, you've got to use risk talk and not let them get locked in to a too neat gantt chart that over-simpifies reality and ultimately mis-informs them. As Glen Alleman insists, quoting Tim Lister: risk management is how grown ups manage projects.

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.