Tuesday, July 30, 2013

Show me the money

Every time I've had a cost plan prepared, by a quantity surveyor, or sometimes an estimator, but I expect more from QSs, after all, I went to Uni with some of them, I don't fail to be disappointed.

The cost plan process starts early in the design cycle, typically, and to accommodate uncertainty, there are usually contingency allowances made: a 'design contingency', sometimes a 'project contingency' if the project scope is in flux, and a 'general contingency' to allow for architectural fantasies and client wishful thinking.

The contingencies are applied in a seemingly rote fashion: 10% here, 5% there, and so on.

I once asked a QS if he reviewed completed projects to see how the contingency allowances bore up to the real world. The answer was a staggering "no"! Here we are, with a great source of data to allow good calibration of many building and project types, and it's let blow in the wind.

The other thing I notice with project cost plans is that the estimate tends to increase as the project advances and more detail becomes available.

But, I think that it should go the other way. In the early days of the project, the margin for uncertainty should be quite high (worked out by the statistical history of similar projects), and as more detail is produced, it should drop, with the margins for uncertainty assigned quite clearly to particular elements of established risk. Then we'd be getting what we paid for!

Wednesday, July 24, 2013

The basic project questions

It may be a little bold to use the definite article, but for my part, here goes:

What do you need to achieve?
When do you need the results?
How much can you spend?

And the supplementary questions:

Why do you need it (to get the business context, or the overall 'mission' you want to conduct)?
Why do you need it then (just what is causing the timing)?
What value do you need to produce (in NPV terms, I'm thinking)?

Once the project is cooking;

What do we need to deliver?
How will we deliver it?
Has this been done before (by the owner, the project manager, the delivery crew...anybody)?
What resources and skills do we need?
Who will do what?
What could stop us?
How will we know when we've finished (that is, what will achieve the required performance?)

Another take on this is the Five Immutable Principles of project management.

Friday, July 19, 2013

A coffee would help...

A little while ago I attended a business presentation at one of my consultant's offices. The presentation was on using i-nexus software to develop and deliver projects that aligned with business goals (now, there's a novel thought).
I left my desk at about 10 to 9am after a busy couple of hours on EOFY work, sped down to the venue and dropped into a seat at the board table.
After a flat out morning, I looked around for a coffee; a couple of other attendees were nursing mugs, so I thought, well, I'm a few minutes late, perhaps coffee was for the early starters; but the start time was 9am, not 8:30, so that was unlikely.
Well, the story was, there was no coffee offered, either before or after. The two with mugs must have just been special.
The presentation, of course, had us doing the tennis swivel as we swung our gaze between the mostly pointless images projected onto the screen at one end of the room, and the speaker, sitting at his laptop computer at the other. Good neither for neck nor comprehension!
Then, we got to the actual software on screen. It was great, except that it loaded slowly, endured continuous band-width apologies, and the colours were such and the images so small that it was barely visible and made little sense!
If you are going to use Powerpoint, at least use it with a semblance of professional capability.

I might blog about the software another time, but here are some lessons:
  1. If people are giving you their time, at least provide a coffee and some light snacks; it's dirt-cheap and for the money is a great investment in a convivial atmosphere. The hospitality shows that you care about your guests' experience.
  2. If the 'presentation' (I mean, the talk) has no graphic content, don't bore or distract us with Powerpoint slides. Keep them for what's important and learn how to blank the screen between times: press the W for a white blanking, B for a black one! Not hard.
  3. At least check the equipment beforehand and make sure it works. Don't rely on a live connection, especially if you are overseas: have some videos on a DVD, or a sequence of screen shots to show what you need to; but don't ever think you will impress people with excuses for non-performing software.
These are the main ones for doing a presentation; particularly one where you are basically touting for business.

But, there were minor problems as well.

One that sticks to mind is the presentation of graphs showing proportions of samples doing and not doing things. The almost inevitable, and almost unreadable pie-charts; '3D' pie charts at that were flung onto the screen. Not good. Not only are the area relativities almost impossible to grasp by inspection, it is impossible to build the chart to further comparsions. A simple and elegantly done column chart would have been far better. I recommend Charlie Kyd's or Juice Analytics' work on this.

Wednesday, July 17, 2013

Is there a design theory?

In a previous post, I claimed that there was no architectural design theory and suggested that this got in the way of efficient design management -- if you don't know where you're going, you don't know if you're getting there!

But, there are elements of architectural design theory around; proper scientific theory, not the art school hoodwinking that passes for design theory and that abounds to the building industries' detriment.

As one example, the work of Space Syntax comes to mind: its work grows out of a theory as to how movement makes meaning of spaces.

Some of the work of the Lean Construction Institute could also go in this direction as would the Design Structure Matrix approach to setting out design interactions.

The elements are there...just needs to be pulled together used as a springboard to further theoretical development.

Wednesday, July 10, 2013

The iron triangle

One of the most popular if time-worn characterisations of projects is the so-called 'iron triangle'. This is usually presented in a diagram with the sides of the triangle labelled 'time', 'cost', 'quality'.

I'm of two minds as to whether this is a useful motif for projects.

On the one hand it is simple, memorable and roughly correct. On the other, it is an oversimplification that omits the principle driver of the three project parameters: the out turn value of the project to its promoter.

The general contention is that to vary any one of the parameters, the others must 'give'. So, to decrease cost, the quality may have to be reduced, or the time extended, because usually to decrease time for a project's completion increases cost. Increase the quality, and you have to perhaps lengthen the project's life or increase the cost, or both.

Within bounds, this makes some sense.

But the terms themselves don't represent the reality of projects: I'd prefer delivery (because we don't manage time, we manage our activity with respect to time to achieve delivery), budget (which should include a buffer for the probability of risk) and performance, which brings together the specified quality and project scope to deliver the required business value (or we could alliterate it into 'price, production and performance'). Changing any of the three will change the value delivered, but sometimes value opportunities can be gained by increases. For example, increase the budget on a retail centre to achieve delivery before Christmas to delivery greater business value.

Max Wideman has some rather complex motifs, but I think that this over-cooks the mix; simplicity is best, but only as a point of departure; and the substitution of the terms I suggest helps, I believe, to clarify their implications; but what should be expressed, rather than implied, is that the result has to always be seen in terms of the business value produced.

Wednesday, July 3, 2013

Project graphics

In my previous post on this question, I suggested that the quest for an all encompassing project graphic representation was probably misplaced. Projects, at least large ones, but even smaller ones, are too complex and have too many information flows to lend themselves to comprehensive graphic summaries.

But, that said, a useful summary of progress vs plan at the 'whole project level' (that is, not at the more detailed level of WBS responsibility, resourcing and completion progress) could be as follows.

An actual vs. planned, per month, usually, of:

  • expenditure
  • earned value
  • commitments (that is $ committed via contract, or work package commencement)
looking ahead, commitments vs planned is the best indicator of expected production. EV, of course, is the best rear vision indicator.

and tracking of numbers of
  • unresolved issues
  • activities commenced vs.plan
  • activities delayed
  • activities completed vs. plan
Getting closer to the action, the project manager needs a 'look ahead' schedule at the work package level, or whatever is meaningful in the project, showing work planned, preparation (lead times for materials and resources), and execution, including resources. This descends to daily calendars for actions to be taken: particularly for lead times on work package preparation.