Bang goes the theory

In times of project crisis, tear-up the rulebook, grip the controls and brace, brace, brace youre about to pass through the complexity barrier. Thats the view of Janet Smart, director of BT Centre for Major Programme Management at Said Business School, University of Oxford.

"Many, many years ago, I watched a film on TV with my family on a Sunday afternoon. It was about a flying ace who was attempting to fly his single-seater aeroplane through the sound barrier. The plane was being buffeted by vibrations and was in a steep nosedive.

Our hero struggled to turn the plane out of the dive by pulling fiercely on the joystick, trying to pull the plane upwards and out of danger. Still the plane hurtled towards the ground. At the last moment, in a stroke of genius, he pushed the joystick forwards, against all standard training and the advice being screamed into his earpiece from air traffic control. And guess what, the aeroplane did pull out of the dive, and our hero survived.

This phenomenon, which occurs as aeroplanes pass through the sound barrier and achieve velocities beyond the speed of sound, was known as control reversal. The changes to the turbulent airflow over the planes wings resulted in different control actions being required.

The interesting thing is that the plane propels itself into that state, and undergoes a period of intense stress and vibration, which appears to be about to cause the planes disintegration. However, this stage passes, and the plane is in a new and unfamiliar state where the standard engineering practices no longer apply. Were they to be applied, the situation would be worsened, rather than improved, culminating in a spectacular crash.

This situation is similar to that experienced by the managers of complex, major projects and programmes. Perhaps without realising it, they pass through a complexity barrier into a different realm where the normal engineering assumptions do not apply.

This theory is explored in a number of textbooks about systems engineering and project management. They are the foundations on which the natural sciences and engineering are built, and may be summarised as:

Positivism, that reality is out there and can be measured and therefore predicted and controlled, rather than being socially constructed by the participants.

Reductionism, that a complex system is nothing more than its components and the interactions between them.

Normative, that a standard procedure can be established that should be followed by every project team, thereby achieving a successful outcome.

The foundations of systems engineering can be traced back to efforts in the 1940s to develop weapons and defensive systems in the USA, in response to the Soviet threat. The engineers who managed the military-industrial-university complex at that time were living in a very different age and their projects lacked aspects of structural and dynamic complexity that confront modern project managers. Todays challenges include:

Rapidly developing technical capability within the environment
Long time scales of five, 10 or 20 years
Evolving strategic context of the organisation, leading to changes in vision and strategy, as well as funding
Consortia of organisations collaborating on the delivery of a project, with different cultures, currencies, and reporting styles
Project management software and PMOs, with formalised reporting procedures and a large number of project tracking metrics.

The changing world view has also impacted dramatically on the assumptions of yesteryear. Positivist scientists and engineers seek to measure what is out there, but many of the metrics of progress on a project are subjective, in that they are based on human judgment.

Furthermore, many of the metrics do not follow a strictly linear scale. For example, although 50 per cent of the requirements may have been met, they may be the more straightforward requirements, and so the remaining 50 per cent will take up a lot more time and resources. So positivism looks a little shaky.

Complex projects are constantly challenged by the unforeseen interactions between modules or components that had not, or could not, have been foreseen at the outset of the project. These interactions require extra funding and time in which to address the issues that they raise. Reductionism may be OK for simple, familiar projects, but complex projects give rise to interactions that are hard to anticipate and manage.

What about the normative approach that there is a right way which provides a template that can be adapted for all projects? Up to a point. Management sciences contingency theory says that there is no single best way to run a business organisation culture, business sector, nationality and other contingent factors all affect how a business manages itself, its employees and its customers.

Different ways of working

Projects and programmes are temporary organisations, so like any other business organisation they too will have very different ways of working within and beyond the standard template to accommodate the culture and requirements of the stakeholders and project team members.

Whatever the recommended practices say, experience tells us that projects run into difficulties from which they may recover, or they may fail and be delivered late, over budget and below expectations. Even more contrarily, it is now being suggested that at times of project crisis, it is not more of the standard medicine that is needed, but fewer, or different procedures completely. In fact, continuing to apply the standard methods could drive the project more quickly into failure.

But how do you know when the time is right to abandon the standard approach and a project has passed through the complexity barrier? It seems that there are two ways.

(Above - Janet SmartBT Centre for Major Programme Management at Sad Business School, University of Oxford.)

Complexity

The first is to start knowingly start in a zone of high complexity, working on a project with high technology, many stakeholders, and a large and changing project team.

The second way to get into the complexity zone is to start out with a well-planned, large project, and wait. The project will drive itself into a zone of complexity as the accumulation of changes and disruptions shifts the fundamentals of the project away from the original plan.

So, youre in the complexity zone, heading into a nosedive, and the project is shaking itself to pieces, and Control is screaming into your earpiece. Maybe this is the time to zone out and think of some counter-intuitive interventions.

Some software engineering projects use agile methods, Skunkworks or Extreme Programming to deal with technologically challenging projects from the outset. Some long-lifetime Big Science projects are organised in thoroughly democratic and visionary styles that hold to the clear goal through thick and thin."

The one constant in each case is the realisation that once the complexity barrier has been passed, the project management joystick should be pushed downwards, rather than up.