01709 898025 / 07796 595332
Disclaimer

The following article is provided on the following basis:
- The information contained is not advice, it is provided free of charge and as information only and for personal use only. It does not, in any way, constitute a contract between yourselves and Smoothstone Consultancy Ltd.
- Nothing contained herein confers any right to copyright or intellectual property. Such rights remain with Smoothstone Consultancy Ltd.
- Smoothstone Consultancy Ltd. are not liable for any damages arising from the use of material available on this site.

The Challenge of Projects

Oh how simple the question sounds.

“What is a project?”

Straightforward, innocuous, harmless? Well maybe, but personally, I would advise caution.

The simplicity of the question stands in stark contrast to the complexity of the answer. Moreover, any attempt to answer i

t leads to a train of thought that raises some issues that are anything but straightforward and goes to the heart of what project management is all about.

This cosily simple facade disguising a fiendish conundrum is, of course, something I take great advantage of.  As a practising consultant, I spend much of my time working with groups of project management professionals honing, polishing and expanding their understanding of, and capability within, project management. I find the question particularly effective if it is posed just as the delegates are settling into a comfortable sitting position and, like judges on the X-factor, seemingly preparing to rate my attempts at entertaining them.

However! Before we consider appropriate answers to this question I feel it is more important to consider the importance and relevance of the question. To do so, let us imagine for a moment that we could not answer it.

If we cannot differentiate between projects and other endeavours then how can we object to every creative process being called a project? Further to this, if every creative process is a project how does project management differ from any other type of management? And if this is the case what is the point of having a “Project Management” course/ book /qualification? The word “Project” becomes meaningless and can be struck out; “Project Management” becomes just generic management. Consider the implications of this for all of us who declare our profession as being Project Managers, our skills would be as appropriate to building the Channel Tunnel as they would be, say, to running a bakery.

For the concept of “Project Management” to have any relevance at all it is imperative that we are able to define what a project is and how it differs from other endeavours.

Back to the delegates. After recoiling from the shock and impertinence of the question their discussions drift towards assertions such as the following.

“Well there is a creative process and an output, there are a group of people involved, it involves a budget and it also has a timescale.”

Delegates are usually cheered to hear me agree with them that all these characteristics apply to projects. However, they are usually less cheered when forced to acknowledge that these same characteristics apply to almost all commercial endeavours. They do not differentiate and hence define a project.

The question is actually anything but straightforward.

 

In the first article of this series, “Space Rockets and Kinky Boots”, the question was approached from the perspective of the organisation undertaking the endeavour. Differentiation between projects and non-projects was explored in the context of the fundamental imperative of the organisation undertaking them. Whilst there is much merit in that approach, this article will explore the issue from a more practical perspective and will concentrate on the nature of the work itself rather than those undertaking it.

So then, “What is a project?”.  As delegates continue to struggle with this it is usual that at least one enterprising member will reach for the course manual and see what others have said. I have always maintained that teachers can learn much from their pupils …. so let me reach for my reference books.

The Association for Project Management in the UK and Project Management Institute in the USA offer the following.

“A Unique transient endeavour undertaken to achieve a desired outcome.”

APM

“A temporary endeavour undertaken to create a unique product, service or result

PMI.

These excellent definitions warrant further examination.

The first point to note is that there is a startling similarity between the two. Both consider a project as an endeavour leading to some kind of output, but in differentiating projects from other commercial endeavours we need to focus on the adjectives used. The only adjective the two expressions have in common is the word “unique”. The other words that come close are “Transient” and “Temporary”. Reach for your dictionary if you like but even then you will find it difficult to discriminate between the two words. “Not permanent” seems to equally apply to both and so for the time being we will treat them as synonyms and for convenience use the word “Temporary”.

So then, what makes projects different from other undertakings is that they are “Unique” and “Temporary”. To further explore the significance of this we shall consider two different examples.

In the first instance we are in a factory making washing machines. A production line churns out washing machines at the rate of two hundred units a day. It is 10:30 a.m. and work is about to start on the fifty eighth machine of the day. In the second instance, final government approval has just been given for the construction of a barrage across the river Severn for the purpose of power generation.

Unique

In the first instance the word unique simply does not apply. The fifty eighth washing machine of today will be identical to the other fifty seven made today, the hundreds made this week and the tens of thousands made last year. This contrasts sharply with the second example. There are very few examples of estuary barrages around the world and certainly none on the perilous and shifting sands of the Severn Estuary: it is a unique undertaking.

Apply the following questions to these two

How much will it cost?

How long will it take?

What precise sequence of actions are to be followed to complete it?

What resources will be required?

What will it look like when it is finished?

In the case of our washing machine, a non-project environment, all these can be answered at the very outset with considerable precision and accuracy. For our project environment no such luxury exists. Here the answers are little better than wild guesses and come with a level of imprecision and inaccuracy to match.  It becomes obvious perhaps, that the project environment is characterised by huge gaps in knowledge, and hence high levels of uncertainty, at the start of the undertaking. This enormous degree of uncertainty at the outset is one of the main reasons why projects, and their management are so very difficult.

Much of a project manager’s efforts are spent trying to mange this uncertainty and in particular trying to reduce it as much as possible, as quickly as possible. However, even if she or he is successful in this we will find that in the very early stages of every project, at the very time when their decisions will have the most impact on the success of the project, they are faced with the most uncertainty. This ability to make decisions in the face of such uncertainty is the very essence of Project Management.

There are very many consequences of this but perhaps the most significant one is that there is every chance that the wrong decisions will be made. Projects face a high risk of failure!

The probability of our fifty eighth washing machine being a total disaster is negligible. The probability of our barrage failing to deliver its intended benefits is very considerable.

Apart from there being a greater chance of mistakes in the first instance, for a project environment there are less opportunities for indentifying the error. Consider the following.

For our washing machine there are opportunities for the partially completed product to be assessed continuously throughout its manufacture. Within the organisation there are numerous model specialists (the supervisors) who know precisely what an acceptable washing machine looks like at the various points. Further, this experience and expertise can, and is, expressed in a set of procedures and rules, and often specialist gauges and tooling, that can be used to exert a very effective control over the creative process. Simple adherence to these rules will almost invariably result in a successful outcome and in the rare instance of any dispute there is access to the model specialists and their knowledge.

This is very different to the situation posed by our barrage builders. Here, the product is unique: they are building the first of its kind. Accordingly no-one knows for sure what it should look like at the various points of its construction. Procedures, rules  etc. to control the creative process  are far less prevalent and there is far more reliance upon those undertaking the work to attest to whether “it feels right”. In instances of dispute there are no model specialists as such to relate to. The ultimate reference point here is the peer group of technology specialists.

Douglas Bader, the controversial wartime hero, once famously said that “Rules are for the obedience of fools and the guidance of wise men”. There is much in this statement to object to but it does invite differing perspectives on rules that are relevant here. A non-project environment characterised with total knowledge and a repeated process can achieve good governance using extensive rules that are strictly enforced. The bespoke, uncertain and often haphazard nature of the project environment does not support this approach and considerable latitude and scope for judgement must be granted to those doing the work. In such circumstances a strict and inflexible rule-based governance approach will simply not work. This is a lesson that many project organisations have learnt only at great cost. Put another way, as Douglas Adams did “A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools.”

There is another consequence of this high risk of failure. With non-project environments such as those involved in mass manufacture, the risks of failure are amenable to control and often can be reduced to a negligible amount. As a consequence the differentiator between competing organisations often comes down to cost. For this reason those involved in managing a manufacturing process are constantly striving to do the same thing but cheaper and quicker. Innovations that offer reduced costs usually incur a small increase in risk. In an environment that both strive for low cost and that can effectively mitigate risk, such innovations are welcome.  The imperative is efficiency.

In a non-project environment with high levels of risk the reverse is true. If the project fails then all the invested money is lost and so the marginal benefit of increase in efficiency offered by an alteration is often wholly outweighed by the marginal increase in risk associated with it. As a consequence the imperative is effectiveness.

The ongoing battle between “efficiency” and “effectiveness” within any organisation is very revealing and gives a fascinating insight into its culture.

Temporary.

“We are building pharaoh’s tomb” was the expression a PM colleague of mine once used. His cynicism was forged in the dockyards of Glasgow at a time when threat of redundancy loomed large for those in the old “Smokestack industries”. He was relating to the fact that for reasons of security, when the slaves had finished building their pyramid they faced execution and burial in the lower levels of their magnum opus. He was commenting on the inevitable redundancy we faced on completion of our current project. Project organisations are indeed temporary (they do not last forever).

This characteristic is, of course, entirely consistent with the “Deliver and Disband” attitude exhibited by organisations adopting a pure projectised culture and discussed in the earlier article but there are also practical implications that derive from the “non-permanent” nature of projects.

Consider again our washing machines. The production cycle is of a short duration and is constantly being repeated.  At any time of the day, within our factory, washing machines are being assembled, tested, packed and shipped. The demand made upon the specialist resources is therefore stable. A permanent resource pool is therefore established to meet this constant level of demand.

Not so for our barrage builders. Here the production cycle is of a very long duration and will not be repeated. Consequently when the foundation specialists have completed their work their involvement is finished but the barrage constructors can start. In turn, when they finish, the turbine installers can start, subsequent to that, the generator installers can start etc. Projects do not make stable demands on their resources and as a consequence the organisations delivering them are in a constant state of flux as specialist resource join and then leave the organisation. References to the “Rotating doors” syndrome are common place in such environments.

It is appropriate here to differentiate between “Temporary” and “Transient”. Whereas they both imply non-permanent, the later suggests constant change and eloquently describes this “constant state of flux” referred to above. Both words apply to projects and both have enormous implications for their management. We shall examine just two: resource and information management.

Regardless of the nature of any endeavour, changing the number of resources available is difficult and slow. Recruiting and training personnel takes a lot of time, as do the various steps involved in reducing a workforce. The demand for resources for our washing machine builders is constant. For our barrage builders the demand undergoes a very high rate of change. Unsurprisingly it is easier to have a close match between supply and demand for a non-project environment than it is for a project environment. It is for this reason that the “Feast and famine” nature of a project team’s workload becomes a certainty. It is also the reason why project environments are so inefficient in terms of resource usage compared to non-project environments. In both instances work is impeded if the demand exceeds the availability. The stable demand profile within a non-project environment allows a supply profile to be established that is only a fraction above the level of demand. The margin between the two represents inefficiency and in this environment it is very small. The volatility of demand within a project environment presents a much larger challenge and to prevent periodic impediment to work (ineffectiveness) by insufficient resources, project environments, typically, are obliged to operate with a generous surplus of resources, and hence inefficiently. Establishing appropriate and timely supplies of resources for projects using multiple categories of resources is an extremely difficult proposition. It is also another example of the conflict between efficiency and effectiveness.

Information is the lifeblood of projects. They demand, consume and generate vast quantities of it and there are many reasons why information systems suitable for a non-project environment differ enormously from those that are appropriate to a project environment. One such reason is that the sheer complexity of projects usually means there are huge amounts of information in the first instance. Another reason is how the gradual reduction of uncertainty through a project life cycle requires frequent changes to revisions of documents. However, the ”Revolving Door” scenario described above is yet another. Carrying on the work of others, and subsequently having others continue your work, applies to both our barrage and washing machine manufacture but in the case of the latter, those other people are still available in the organisation. This is not the case in the project organisation. Some of our barrage builders will be picking up on the work completed by others who left the project months, if not years, earlier. Continuity cannot be achieved by word of mouth. Instead it is achieved with the aid of written records. How much time and effort does your team put into “As-built drawings”, operating and maintenance manuals, installation records? How many times have you spent months investigating something only to find someone else did the same last year but failed to archive the result? It is this requirement for continuity that is largely responsible for the massive demands projects make on information management systems.

Conclusion.

All endeavours are not the same. Projects and non-projects are different.

Without the capability to differentiate between the two the discipline of Project Management has no relevance whatsoever.

Consideration of the degree to which an endeavour is unique and / or temporary allows for its classification as either a project or non-project.

Projects have characteristics that pose specific challenges. The collection of the various tools and techniques that are appropriate to addressing those challenges is what we refer to as project management.

Project management is appropriate for managing projects but not for managing non-projects. Likewise management techniques for non-project environments are not suitable for managing projects.

Is your endeavour a project or a non-project and are you managing it appropriately?

 

Adrian Taggart, 2009

©Smoothstone Consultancy Ltd.

Article – The Challenge of Projects