Learn from the engineers

Can IT project lessons be learned from the building site? We talk to a man who has tried both

Can IT project lessons be learned from the building site? Julia Vowler talks to a man who has tried both

IT projects are notorious for coming in late and over budget. But is there any value in comparing them with engineering projects in the physical world, to see whether they can shed any light on IT's dismal reputation?

Geoff Reiss, chairman of ProgM, the British Computer Society's special interest group on the subject, is in a good position to compare the two worlds - he spent the first half of his career putting up hospitals and factories all over the world.

"In project management terms, [IT projects and heavy engineering or construction projects] have the same problems," says Reiss, although there are significant differences.

One difficulty is in the environment in which the projects have to operate. As Reiss observes, the only environmental issues that a construction project has to allow for are of the natural variety - from blizzards to earthquakes. For IT projects environmental issues can be more disruptive.

IT projects do not have the luxury of isolation. Building a factory, says Reiss, can be done in a desert. It's completely isolated and self-reliant. On one construction site in Azerbaijan, the first thing Reiss did was build a bakery for the workers, it was so isolated.

The project manager can be totally focused on the construction task. "There's no other agenda," says Reiss.

Not so in IT. There are painfully few IT departments with only one project under way at any time. And none of them put a "closed for the duration" sign on the door until they are finished.

As well as a hundred other projects going on simultaneously, the greatest curse of the IT project manager is business as usual. The decks can never be cleared sufficiently to give any one project a good clear run.

"The project management environment doesn't recognise the conflicts between multiple projects and business as usual - it's a big issue. Thinking of an IT project as if it were in isolation is fundamentally flawed," Reiss says.

Another problem is that the other non-IT staff who are needed to complete the project all have day jobs to do.

"The project management paradigm does not reflect the organisation's structure," says Reiss.

That's fine when building a dam, he says, where the rest of the organisation is in another country, but not in an IT-driven change project. An IT project is critically dependent on resources in the rest of the organisation - over which IT has no absolute or even adequate control.

"When the project manager plans his resources he has no relationship with those resources which work for functional departments - and those people often have to work for more than one project and keep the business going as usual. Each project ends up overloading those resources," Reiss warns.

The effect on the progress of the project of such over-stretched, over-committed workers, whose priorities are elsewhere, is depressingly predictable. But it may not be easily measurable - and that is another key difference to engineering projects.

"When I wanted to know what had been achieved so far on a building site I put on my hard hat and took a look - I could count the square metres of walls put up," says Reiss.

"But in IT, if you ask people what's done and what remains to be done there is nothing to see. In an IT project, you go from zero to 100% in the last second - unlike building a brick wall where you can see when you're halfway done. We've moved from physical to non-physical deliverables."

To make matters worse, if a construction project is lagging, trucking in another dozen or so brickies and chippies is relatively easy. There are plenty of them and they can be productive instantly. Not so when it comes to adding another round of Java programmers to try to speed up an IT project.

"Effort," points out Reiss, "is the scarcest resource - not time."

The outcome of that, he says, is to highlight another key difference between an IT and an engineering project. "An engineering project is task-centric - you're given a timescale and you need to specify the resources you need," says Reiss.

IT projects, by contrast, "are resource-centric. Relatively speaking the IT team is fixed," he warns. That means, "You do what you can with the resources you've got."

Inevitably, the available resources will be inadequate. "That means you have to prioritise the projects."

Even when funding for extra resources is granted (assuming the required skills can be found in the marketplace), they can't be as instantly productive as an existing team member.

Each IT project will be unique, with its own business drivers and designed for a particular organisation. Those have to be learned by anyone joining the team.

"It takes two months to get a Java guy up to your speed [on your project]," say Reiss.

For Reiss it's clear that the circumstances within which IT projects have to be conducted are the real killer. It certainly isn't the technology. However tough a technical challenge any software engineering task may be, they're nothing like the ones "real" engineers face.

"I've put up factories with floors the size of a nine-hole golf-course and I've built an office block in Cairo where the underground car-park was below the water table," he recalls.

Read more on IT jobs and recruitment