Tuesday, May 6, 2014

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.


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.

No comments:

Post a Comment