Is project management an exact science?

Project management is about knowing exactly what the customer’s objectives are; it is about assessing exactly the right deliverables; it is about assembling exactly the right team to arrange the deliverables. But what happens when we do not get it exactly right?

As with most human endeavours (with some exceptions) attributes within every project have some tolerance for inexactness. The issue is, will it make a difference and, if so, how much?

Consider the airliner that lands a little too far down the runway. This may result in high braking and wear and tear, thus higher maintenance demands on equipment, but this will be within operational tolerances. But overshooting can also have more dire consequences.

Consider an incorrect line of code in 10,000 lines: identified immediately this is of little consequence. Allowed to proceed too far, however, and a major reworking may be the consequence with its attendant delays and costs or a opening for access by hackers.

There are many other instances in project environments where ‘exactly’ is not achieved and for which we accept the consequences and make appropriate adjustments. Beyond those tolerances, however, we deal with an outcome which inevitably suggests project failure either in terms of the traditional iron triangle (time, cost and quality) or more importantly, business failure through the inability to meet a functional requirement, thus distorting the business benefits upon which the project may be based.

In each instance the consequence of the failure to meet the exactness specified (within agreed tolerances) is an outcome requiring additional effort, scope adjustments, rework of work already undertaken and the necessary control of consequential events for which an allowance has not necessarily been made.

These are the bushfires of project management which contribute to cost and time overruns, team stress, operational dysfunction and, at the extreme, business failure, either in respect to individual projects or, more significantly, the business objectives at the program level.

Part of our methodology for handling inexactness is found in our management of uncertainty or risk. It therefore holds that if we can minimise uncertainty, that is, increase the exactness of our activities and processes, our projects will progress much more effectively.

This requires the creation of good planning space at the commencement of a project but, unfortunately, the environments in which we operate do not always provide such space, although invariably the time and associated costs required for rectification is usually forthcoming.

In terms of project outcomes, if we fail to achieve our time, budget and quality success criteria, such failure is due to our inability to achieve the ‘exactness’ required for the endeavour while planning the physical attributes of the project (the product).

If, on the other hand, our time-cost-quality criteria are acceptable but the project fails to meet business requirements, such failure is due primarily to our inability to determine the exact business requirements and properly scope the project (the process).

The result in both cases is that acceptable tolerances have been exceeded and the exactness we sought has not been achieved. The lesson we continue to ignore is that an extra kilo of planning is far less costly than a kilo of rectification.