Passing the buck

Picture the scenario – I'm sure you've been there a thousand times: Contractor's surveyor: 'Ere, they've forgotten to give a slab level on this construction drawing, but it scales as 12.75 m.

I'll set out at that, shall I? Contractor: Excuse me, Mr Engineer, can you tell me the structural slab level? Engineer: Sorry. I'm waiting for the architect to confirm the finishes so we know what allowances to make from the finished floor level. Mr Architect? Architect: Oh dear, I can't tell you yet. I'm waiting for the client to confirm what level of use he's anticipating, and for the interior designer to confirm that it's available in his preferred colourway. Just let me check with the client.

Client: Our corporate colour is green, but our facilities manager is keen not to have carpet and wants to use this new lino he saw at a conference in Holland. Oh, and I can't tell you the long-term use of the space as we're only leasing the building for two years – you'll have to check with the landowner.

All this for one simple question. The example may be simplistic, but it illustrates the hierarchy of decision-making that can lead to the lengthy delays between the issue of an apparently straightforward request for information and the receipt of an answer. So, would you prefer this scenario? Contractor's surveyor: 'Ere, they've forgotten to give a slab level on this construction drawing, but it scales as 12.75 m.

I'll set out at that, shall I? Contractor: Yeah, but I'd better check. Excuse me, Mr Engineer, can you confirm the structural slab level is 12.75 m? Engineer: Yes. (Thinks: That gives the architect 50 mm to play with for his finishes. That'll have to do – he'll probably never notice anyway, and I can always claim the contractor didn't comply with the concrete tolerances if the edges don't work out OK.) Still not terribly realistic, perhaps, and I would hope that engineers manage to have a constructive conversation with the architect rather than making a snap decision and hoping for the best.

Sometimes, the ripples of a snap decision can lap on the shores of far distant ponds. There was the junior architect, entrusted with handrail details, who decided that a particular dimension of stainless steel rail would look fetching. The rail had to turn down the stair, but because it had a minimum bending radius, the stairs had to be set out again, this time slightly differently. Because the stairs moved, the lifts had to move. Because the lift moved, the lift pit had to move. The pit was already constructed, and moving it cost the client £15 000.

So how are decisions extracted? Who decides who has to make the decision? Invariably, it depends on the individuals involved – some are only happy when issuing instructions left, right and centre; others will make a decision only after prolonged cogitation. Again, it's a question of balance. It can become a question of delegation, too.

If I had a pound for every time someone told me effective managers delegate, I’d be able to afford Peter Mandelson’s house

If I had a pound for every time someone told me that effective managers delegate, I'd be able to afford Peter Mandelson's house in Notting Hill. But there has to be a point at which delegation stops.

I remember one occasion when an electrical engineer was asked to write a specification, but since he was pressed for time, he asked a junior colleague to dig out the last specification that was written and amend it to suit the current project. The young engineer, intimidated by the document, didn't actually read it but asked a secretary to find it and change all references to the project title.

The spec was produced in time, but it wasn't until tenderers started asking questions that it was realised that it was for a computer centre and not the small nursing home intended.

So, delegate, yes, but maintain control. Ask advice, yes, but within reason. "A problem shared is a problem halved"; "two heads are better than one" – there are any number of adages in support of sharing problems, and any industry that involves creative design and evolving technologies can operate effectively only when knowledge is pooled. But sharing a problem doesn't necessarily mean that responsibility for solving that problem is passed on.

Telling someone about a crisis may make us feel better, but it doesn't bring a solution any closer. Increasingly, construction professionals are passing the buck and asking someone else the difficult question rather than coming up with an answer themselves.