1.1.1

Pipelines, railways, and road construction can also have multiple access points although less so. However, there is a very distinct sequencing to the application of different stages of the technology. An undersea pipeline, on the other hand, is more of a single workfront project.

1.2.1

The existence of a bottleneck or ‘pinch point’: environmental or infrastructure limitations that constrain the delivery of materials or the disposal of excavated waste material.

2.1.1

The number of sub‐divisions (contracts) should be limited by the same principle as the number of people reporting to a manager (five to seven).

2.1.2

The type of contract (see contract choices paragraph 2.4), competitive tendering and the incentive mechanisms to be used all have a major influence on project execution.

2.4.1

The type of contract for performing each sub‐division of the project should depend on who is best able to manage and control the risks and who is best able to estimate and carry the risks. The choices are:

This list of contracts has been itemised, in descending order, of risk to the contractor. From a client perspective, the order in each risk category should be reversed. The analysis is based on the named payment mechanisms being taken as written. Every client will have their own quirky way of administering them so that they can end up being quite different from the name they have been given. On one occasion, a contractor asked for my opinion on a contract that ended up being the complete opposite of what the name implied because of the obligations and consequent liabilities written in the contract document. It cannot be over‐emphasized that the true risk category is not revealed by the designated payment labels but is disclosed by the words in the terms of the contract. So read the words.

2.4.2

The choice of contract type involves balancing the degree of client involvement ( reimbursable contracts) against the loss of client control (fixed‐price contracts). ¹⁰

The characteristics of the different contract types are summarized in Figure I.C.1. The arrows indicate that a particular characteristic is maximized in the direction of the arrow.

Figure I.C.1

2.4.3

‘Tell me how someone is paid, and I will tell you how they will behave’. This is equally true of contracts. All contract forms and incentives have been developed to change people's behaviour. The two basic forms of contract are at the opposite ends of a behavioural spectrum. With a fixed price contract, the contractor will try to cut corners. Whereas with a reimbursable contract, they like to get involved in the detail and over‐design in order to expand the man hours.

2.4.4

Traditionally contracting has been confrontational. The fixed‐price contract says: “Leave us alone, and we will deliver an end product.” The reimbursable contract says: “Tell us what you want us to do, and we will provide you with the necessary service.” Today's emphasis is to build on this collaborative approach and work together for mutual benefit. Thus the choice of contract should also be based on inducing the right behaviour.

2.4.5

If we take risk as the financial impact to the contractor, then a guaranteed maximum contract is the highest risk since it is in effect a fixed‐price contract, but the contractor only keeps 50 per cent of any saving, whereas with a true fixed‐price contract, the contractor keeps 100 per cent of any saving. Lump sum, as used by some people, means that you don't get paid your ‘fixed’ price until the project is completed, as opposed to a conventional fixed price, which can involve progress payments. A firm price removes the significant risk of inflation and as such is the lowest risk of this ‘fixed’ price, contractor risk category.

2.4.6

In the shared risk category, the client basically says: “We haven't decided on the scope yet, so please provide some rates for the listed work activities and the material quantities. When it is complete we will re‐measure the work involved and reimburse you according to the schedule of rates.”

2.4.7

The target cost contract is perhaps the only contract type that attempts, if structured correctly, to change behaviour. It can be seen as a lower risk since any overrun is shared with the client. However, any underrun is also shared, and consequently, has a higher financial impact than the other shared‐risk contracts in which the contractor gets paid for all the work that they perform. There is not much to choose between the rest of the shared‐risk category, apart from a bill of quantities. A bill of quantities is likely to include some additional risks in the words of the document, in addition to the pricing risk. Of course, if the contractor is asked to take any additional risk involving the quantities or scope, then this contract would move into the contractor‐risk category. Day works and time and materials are basically the same. They should only be used by a client for unforeseen, unscheduled, and un‐priced work. As a consequence, they can be quite lucrative for the contractor; however, the quantity of work should be small.

2.4.8

In the client‐risk category, the contractor is reimbursed their costs so that there is no pricing risk as in the other categories. No contractor should be allowed a cost plus percentage fee contract, but I still come across them now and then. If you have one, look after it!

2.4.9

There is also an option to start the project with one of the types of reimbursable contract and then at an appropriate stage, when the scope of work is adequately defined, ask the contractor to convert the costs into a fixed price.

4.1.1

These projects are characterised by a visible and physical end product involving heavy capital investment. There is a primary emphasis on safety and the physical environment. A range of multidisciplinary skills are required, using a wide range of materials.

4.1.2

Offshore projects are really process plants mounted on a large support structure. Apart from lifting one onto the other, their prime difference from an onshore plant is that everything has to be prefabricated or modularised due to the exorbitant costs of working offshore.

4.1.3

Construction is different. Although much of the work is similar from job to job, unlike home office design and supplier manufacturing, it does not have a specific workforce or a specific work location. One contractor never builds the same plant at the same site for the same client with the same labour force. For this reason, the concept of progressive, incremental improvement which may be achieved in manufacturing, is not feasible in the field. “When a Japanese car factory has a quality problem, they go solve it; when a British engineering construction project has a quality problem, they write a procedure.” ¹¹ At least the implementation of a proper procedure for each activity will lead to steady improvement.

4.2.1

A key feature is the historic separation of design and construction. The architect defines what is required but rarely talks to the builder who is responsible for how the work is constructed, thus compromising the outcome. Nevertheless, specific contracting approaches (for example: design and build) are now used in order to address this deficiency.

4.2.2

Another key feature is that there is no single point of responsibility. The quantity surveyor is cost focused, and the architect is design focused. Architects aim for the highest architectural standards even when it is inappropriate in corridors and service areas. Further, as professionals, they give advice and do not assume any liability or responsibility. The traditional contract conditions nominate ‘the engineer’ (a client employee!) as an arbiter. On the other hand, a project manager makes decisions (as in the new engineering contract) for the benefit of the project, balancing aesthetics against practical considerations and cost.

4.2.3

The nature of the work is primarily civil with other disciplines having a reduced input. The emphasis is usually on cost, with attention paid to quality due to the high cost of remedial work. By contrast a modern building, for example Terminal 5 at London's Heathrow airport, can be closer to a process plant with 70 per cent of the cost being mechanical and electrical services.

4.2.4

Comparison of Engineering and Building:

4.3.1

This is a mature industry. Consequently, there is a strong focus on the specification and detailed design. The technology is ‘common art’ with little development required. The consequence is that open competitive tendering for turnkey, fixed‐price or lump‐sum contracts is common. There is a heavy client involvement with independent consultants. Projects are usually financed by loans or aid agencies.

4.4.1

Historically the pre‐privatization water industry in the UK was dominated by a civil engineering culture but has subsequently accepted that it is a process industry. They started with a lack of project management skills and have subsequently developed their project management philosophy from a variety of industry practices.

4.5.1

This industry is characterised by progressive development up to a prototype stage on a reimbursable basis using one or two contractors. These contractors then tender fixed prices for the execution phase.

4.5.2

Aerospace tends to be a series of repetitive projects managed as a programme of work. There is, however, the problem of timescale. They are too long for consistent personal commitment to get to the end, and project managers will change.

4.6.1

Governments tend to believe that they are purchasing an end product rather than project managing the development of a project. Projects can lack one point of control, and the project management is weakened by the power of a contracts department. There is a tendency to top up their level of ignorance as personnel are moved onto other assignments and new personnel are brought in who have no project management expertise.

4.6.2

Try to avoid what can be termed political projects. The rules of engagement tend to change, and the project manager gets stuck with the problems.

4.7.1

These are usually programmes of incremental capability acquisition as described in Part II, Section A. They are subject to the external influences of politics and have too many internal organizational elements.

4.7.2

A major problem is the advances in military technology that takes place during the long development stages of the project. For example: an armour‐piercing projectile is developed. However, the opposition develop better armour or introduce sloping armour, so further development or new concepts are required.

4.7.3

Techniques need to be developed whereby key technology elements can be extracted in modules and changes retrofitted.

4.7.4

The major flaw in defence projects (as with all government work) is that there is too much concentration on the procurement process and not enough on project management.

4.8.1

The industry is still relatively young. The characteristic that distinguishes it from other industries is that the hardware involved, the design techniques, and the software languages change very quickly. However, the developments in the software have not kept pace with the potential of hardware. This encourages people to add extra functions to the requirements. It is also poorly understood by management. The project managers are rarely trained, and the creative nature of the project personnel produces organizational behavioural problems. The IT discipline seems unable to accept that conventional project management has anything to contribute to the management of their projects. The discipline has a habit of reinventing ‘new’ management processes. The biggest problems are not technical but human problems.

4.8.2

There are control problems due to the ongoing nature of the design process and the lack of a visible product. Control is exercised through man hours spent, lines of code written, or modules completed. A problem is that there is a tendency for everything to be 99 per cent complete. Finally, as for many projects, the documentation – operating instructions and so on – tend to be deficient.

4.8.3

The phases are very similar to any engineering project, but software development has some differences:

1. As in many projects, the customer may not know what they want in the initial phase of analysis, which produces a requirements specification. Further, the customer's ideas may change when they see what is proposed and also during development. Again, as for all projects, their business needs may also change. Consequently, there is a formal process of validation, which checks that the requirements specification is correct.
2. During design, there is a formal process of verification to check whether the design meets the requirements specification. Prototypes of the proposed system may also be produced. The design stage must also include a specification of the hardware requirements.
3. Implementation of the actual coding of the programs and the like is probably about one quarter of the total project effort. Similarly integration and testing requires at least as much effort as implementation.
4. A maintenance process is necessary since it is virtually impossible to test for every eventuality in a major system. Software must also be designed with appropriate consideration for possible future enhancements. Control of both documentation and change is vitally important.
5. There is no procurement (or none to speak of, though part of the system might be brought in). There is no construction.

4.8.4

Software development has been much concerned with the possibility of software re‐use. Thus there is a need to develop standards so that the input/output interfaces and performance of the software component are well‐specified. This is like buying a pump; one would buy it based on its performance specification without knowing much about how it does it.

4.8.5

The information technology world is beginning to relearn that large projects cannot be managed. Contrary to conventional wisdom (for physical projects), it is a mistake to try and define the total scope for a large software project. It is clarity of the objectives, of what one is trying to achieve, that is critical. Decide on the division of work by breaking the project into its natural smaller packages. Priortise the component parts that provide the best value for the users and hence the business, and release incremental functionality early. Roll out the various elements slowly in order to find problems before releasing the next component. ‘US government statistics show that the majority of [IT] projects that run for longer than a year with no intermediate deliveries never deliver, no matter how convincing their business cases are’. ¹²

4.8.6

Start with an extensive feasibility study and a pilot project that is thoroughly tested by a small group of experienced users, and then grow the project as it is released to a wider population of users. This approach was demonstrated and validated with the computerization of pay as you earn (COP) project – 1977 to 1983, ¹³ The first large government IT project completed on time and under budget.

4.9.1

The story of a survivor from the Piper Alpha North Sea Platform disaster provides the key to any project involving change. When the survivor was asked, “Why did you jump into the burning sea when you were probably jumping to your death?” His reply was, “There was a chance I would survive, which was better than certain death by staying on the platform.”

4.9.2

The business parallel is to recognise that if the company carries on as it is, it will slowly die, but if it changes, it might survive. Ask the questions: “Where are we and where do we want to be?” The cost of staying where we are is going to be greater than the cost of the process of change. Any project involving a change in cultural values must also involve changing people's behaviour by changing the company's procedures. Both have to be altered to achieve change that will last.

4.9.3

The absolute commitment of the chief executive is essential. They must also stay committed throughout the project. If they are not involved, don't start the project. I was appointed project manager of a productivity improvement programme; it was launched by the chief executive and because of their presence at meetings, even the most negative of the department managers (one in particular) also attended. However, at about meeting four, the chief executive excused themselves because they had to meet a client. The message received by the reluctant attendees was: “Oh, so there is something more important than this time‐consuming meeting.” The result was that the sales director also had a client to meet at the next meeting. From that point on the whole programme fell apart.

4.10.1

Manufacturing projects are different in that they perform repeat projects for the same client in a constant location with the same labour force.

4.10.2

The key to a manufacturing plant is to identify the constraints (or weakest link) in the chain of activities (the process) that delivers a finished product outside the factory gate. The weakest link (bottlenecks) in the chain of activities (the machine with the longest component manufacturing time) determines the time taken to complete the assembly of the finished product. The focus is on controlling the level of inventory in front of machines (in particular, the bottlenecks) to the throughput (the finished products that have been sold, resulting from market demand). ¹⁴

4.10.3

In the car component industry, the good news is that you have been awarded the contract. The bad news is that in year two we will expect a 10 per cent reduction and in year three a further 10 per cent reduction. We may then have to invite competitive tenders in case you have become too complacent or because of developments in the marketplace. This is the approach that anybody outsourcing services, such as providing canteen facilities or computer services, should adopt.

4.11.1

It is incorrect to group research and development together. In a development project, a deliverable has been determined (see aerospace above), and thus it conforms to the norms of project management. Research projects, on the other hand, contravene most of the essential principles of project management.

4.11.2

In principle, a research project manager is responsible for supporting creative thinking in small subject‐oriented units and making sure that the thinking results in some kind of concrete output. Further, this output should preferably be on time and to budget. However, if there are fixed goals with certainty of the results, then it is not research. Additionally, if there are no failures, it can be argued that the researchers are not doing their job.

4.11.3

Research is more project leadership than management; direction comes from the work itself rather than from a manager. It is to a large degree about influencing and persuading partners.The research leader's task is to present a unifying vision and nurture a project environment where an assembly of individuals can be turned into a committed and effective team. It should feel responsible for, not only their own individual contributions, but for the collective team output. Researchers have a desire for a large degree of autonomy in their work and democracy in decision‐making, Hence, a high degree of delegation and attention to interface management is required. A democratic‐authoritarian management style is needed. That is, consensus with qualification, see Part VI Section B, paragraph 1.2.

4.11.4

Listed below are some of the paradoxes of research project management:

1. There is a need for a risk‐taking approach to be innovative. By contrast there is the need to reduce risks abd to ensure the delivery of the desired result on time and to budget.
2. There is task and process uncertainty. There is unpredictability of the research outcome. New research opportunities arise during the course of the project, as against the need for predictability of project output.
3. The quality of any output may improve if deviations from the plan are allowed. Continuous adaption and adjustment is required. Flexibility is necessary in order that the project goals can adjust to future changes in the project. That is, change is a good thing!
4. Focus on getting the right things done, not so much on controlling how and when they are done. Effectiveness is generally more important than efficiency in research projects; the result is more important than the process.
5. Rather than setting one common goal, the first phase should be about juggling several versions of the project in the air at one time.
6. The phases should not be considered as a deterministic linear process where each phase succeeds the other. They consist of a number of fundamental project tasks that overlap and gradually take turns in dominating during the life of the project. The conceptual phase will continue to influence the project but with diminishing intensity.
7. Participants are more likely to have powerful hidden agendas: co‐operating in a project but in competition with each other for acknowledgement of their contribution. They have a need for recognition of their work and to be published.
8. There is a lack of management information and a difficulty of interpreting management information. There is uncertainty of the end product and the process versus the need to act as if there is certainty and making management decisions continuously. Realistic planning is not possible in view of the high level of uncertainty.

4.12.1

A theatre production is a series of repeat projects that continue for as long as they produce the business benefits for the client (the producer). Each repeat project will be slightly different, depending on the users' (audience) reactions. The business‐oriented client tries to control the creative project manager (the director) who often has little interest in cost issues but works to a ‘drop dead’ (see 5.2 below) opening date. There is almost always an extensive feasibility and protyping stage (rehearsals and provincial tours before a major city launch). It is, in effect, a ‘tower project’; it has to start at the begining and continues in sequence (as defined by the specification – the script) until the end is reached. Theatre is led by the creative team (actors) who use the site (stage) first and then the technical team come in to work around the actors, and adjust the scenery in order to complete the scope. Once the execution phase starts, the project manager has no more involvement and the team (cast) is self‐managing. A theatre production is a project being produced live – the end product is transitory and, on its own, leaves no permanent physical mark.

4.12.2

By contrast there is a permanent end product for film projects. They are in effect pipeline projects with multiple access points; that is, they can be done in any order. Films sometimes leave out the feasibility stage (rehearsals) and take multiple shots at getting the execution stage right, which is the reason for cost overruns. However, if the quality is right, the business returns swamp the cost overruns. Films set up and do all the technical work first, and then the creative team (actors) come onto a finalized project location (set).

4.12.3

A film will perform a product breakdown geographically with a location focus. Even if the action takes place over hundreds of years, all outdoor sequences, indoor sequences, or all the scenes involving certain features, settings, or actors are grouped together for cost efficency. Film projects also involve large numbers of subcontractors and thus need much more formal and detailed planning. Filming individual scenes takes on the characteristics of a drop‐dead date. Conversely, if they meet problems with the setting availability or resources outside their control, the creative director will change the specification.

The film The Making of Gone With the Wind demonstrates that Gone With the Wind was completed on time and to budget because it used a significant range of project management techniques and skills. Particularly noteworthy is its use of product and work breakdown structures, taken down to the task level, in the form of story boards.

4.13.1

Projects in the medical world are unique in that they form part of the client's own body. For minors, the client and the key stakeholder are separated. The client's cost, time, and quality/performance triangle are totally skewed. In conventional project management, the client sets the objectives that must be achieved. In medical projects, the project manager (the consultant) decides on the objectives for the project, and the balance between time and quality and cost is now also considered. However, this is not done alone but in conjunction with their colleagues, the other project managers/consultants. For the client, the objectives are aspirational, and their whole emphasis is on quality with a secondary interest in time. In the National Health Service (NHS), the client ignores cost. For private work, cost will be a major consideration but will hopefully be covered by a project insurance policy.

4.13.2

The feasibility and planning phases of a medical project, for example a surgical operation, are dominated by intermittant tasks (pre‐assessment, tests, and so on) in a multi‐project environment. None of these early task performers understand the whole picture (project plan). All the tasks interact with each other, and the interuption takes precedence. In order to complete the interupted task, there is a reassessment and, consequently, the overall duration of the work takes longer.

4.13.3

Somewhere in the organization, there is a programme manger using a multi‐project approach juggling availability and allocation of resources. The result is that the client/patient may never see the same team member more than once, performing the same task. Thus the client/patient is totally dependent on a functioning system rather than a single point of contact in charge.

4.13.4

The project (patient) is passed in a relay with a handover file from one specialist technologist to another, with little or no prior knowledge of the project. The handover file grows in size as the interactions accumulate and the project moves from one stage of the process to the next. There is an enormous emphasis on interface management to ensure that the correct project/patient is being addressed.

4.13.5

The execution stages are very similar, if not identical, to the model describing the conventional process in Section B. The main difference is in the people, and in particular, the project management function. There is a manager projects (the senior consultant), but they are also the head of a functional department, and they hold meetings with the project managers to agree the plans for the various projects.

4.13.6

Whilst I can make a good case for a project manager not being trained in the technology of the project that they will manage, this does not apply in the medical profession. The project manager/consultant has to have been trained through the route of technologist (the registrar). There may also be an assistant project manager (nurse practitioner) who will be permanently assigned to the project manager on all the projects that they are involved with. Whilst it is theoretically possible for an assistant project manager to eventually qualify as a consultant, this is unlikely. Whereas in the technical industries, this is more than likely. There is not a conventionally understood deputy project manager. The registrar is in effect a project engineer in training to be a project manager. Further, as on small technological projects the consultant project manager may also perform the technology/operation.

4.13.7

Another difference is in the project team for the execution phase. As a generalisation, a team is normally selected from whoever is available; however, for a surgical operation, the theatre team has been pre‐selected and has worked together so that team building should not be necessary.

4.13.8

The main part of the project, the operation, is project managed as a stranger project with elements of a repeat project (see the first paragraphs of Section A). It is reassuring to see that “surgeons will use a pre‐operation checklist:

• Does everybody on the team know each other's name and role?
• Has the surgeon briefed the team on the goals of the operation?
• Do you have the right side of the body you're operating on?
• Only then do you begin. ¹⁶

4.13.9

The whole approach changes for the necessary postoperative tasks and ongoing support functions – runner projects. However, by good definition of the tasks and how they should be performed, many become standardized routines.

4.13.10

At the end of the project, the setting to work stage, the technological and medical projects are very similar. In both cases the project manager discusses with the client any short fall from the 100 per cent performance that the client wants, that can be or may have to be accepted. However, something that the medical world does well, compared to technological projects, is the postproject completion stage when follow‐up projects are discussed.

4.13.11

Accident and emergency projects are totally dependent on a good process (capable of a wide‐ranging flexibility in capacity) with good systems and procedures. The first step is a pre‐feasibility stage (triage) in order to determine priorities/urgency and filter the various technologies. Is it a pipework job, electrical, software, or is it a piece of machinery that doesn't work? At the feasibility stage, a preliminary assessment is made; is the project a runner, repeater, or stranger? Can it be repaired, do parts need to be substituted, or in the ultimate case, does the machinery need replacing – a major project.