Information, knowledge, and diversity

Project organisation relies on extensive information recorded in documents and information systems. As explained in Chapters 4, 6, 10, and 11, information can readily be moved from one computer to another. However, project organisation depends on people acquiring knowledge from documents and information systems so they can make appropriate decisions when needed. It is seldom recognised in project management texts that converting information into knowledge in the minds of people is difficult and presents special challenges.

Another challenge is that it is difficult to ensure that all the information is consistent and as free from errors as humanly possible.

One of the most effective ways to manage uncertainty is systematic checking, exploiting diversity in perception, interpretation, thinking, and action. Different people see the same things differently; that is why it’s best for documents to be checked by someone other than the authors. The more the checker thinks differently from the author, the more likely the checker will be able to notice mistakes in a document. The mere expectation that work will be systematically checked by senior engineers can improve performance just by raising expectations on the expected standard of work. Encouraging diversity within an engineering enterprise is likely to expose mistakes and misunderstandings earlier, resulting in fewer costly consequences.

Document-reading skills are especially valuable in this context, as explained in Chapter 6.

Project life cycle

Every project starts with discerning needs and negotiating possibilities, along with securing funding and regulatory approval. In practice, funding and regulatory approval precede each of the main stages through a ‘stage gate’ decision-making process that is usually unique to a particular enterprise (Figure 14.1). For more, see The Making of an Expert Engineer (Chapters 10 and 11).

Design and technical problem-solving come next, to the extent that they are needed. In practice, design and problem-solving are often interwoven with analysis and prediction processes in a series of iterative refinements. Even the requirements may be renegotiated in the early stages.

Detailed planning and preparation of all project documentation is usually the last step before the critical final investment decision (FID) is made to proceed with the rest of the project. Typically, by the end of this stage, between 5% and 10% of the project budget will have already been spent. From this point, everything gets much more expensive.

Procurement and logistics, manufacturing, installation, commissioning, and acceptance testing use up the bulk of the capital investment in any project. Predictability is the key in this stage: engineers are under a great deal of pressure to make sure that everything is completed safely and on time, within the planned budget, and delivered with the required technical performance.

Only in the last stage does all this investment start to provide some useful value for people through the tangible products or services provided. This is when payments start to flow back to the investors who provided the funding for the venture. The product must work reliably for its expected service life, and often much longer. Maintenance plays an important part in achieving this, which means keeping everything working so that the predicted performance is achieved throughout the service life of the product or process. Ultimately, there will be a decommissioning step when the artefacts are removed for reuse or recycling. In the case of a manufactured consumer product, this can happen throughout the life of the product.

Figure 14.2 shows the project activities enclosed within a coordination ring that continually guides the implementation steps towards the intended objectives. A web of social relationships coordinates each of the technical activities. The ring consists of informal (and often invisible) processes grouped on the left and their formal equivalents on the right. In a way, the formal coordination processes are also invisible: they are often regarded as ‘non-engineering’ activities.

Notice how design and technical problem-solving are relatively insignificant aspects in these diagrams. Technical problem-solving is avoided as much as possible; it is usually much more preferable to use solutions that have been tried and tested in the past rather than devising new ones with uncertain efficacy. In many projects, engineers reuse designs from previous projects as frequently as possible. Once again, this saves time and reduces uncertainty.

Notice how the coordination ring also acts as the foundation for the whole endeavour.

The coordination ring involves continual interaction between all the participants, including the client(s), financiers, engineers, contractors, suppliers, production and service delivery workers, technicians, regulators, government agencies, the local community, and special interest groups.

In the coordination ring base, work starts with negotiations on constraints, even before funds have been committed. Constraints include

• capabilities of suppliers, production capacity

• technical requirements

• schedule

• regulatory requirements

• health & safety requirements

• environmental impact, emissions

• reliability requirement, client’s maintenance capacity

• client’s financial capacity

• external financier(s) requirements

• tolerance for uncertainty

• intellectual property

These negotiations shape decisions on funding at each stage of the project.

On the formal side of the coordination ring, we find engineering management systems, including project management, configuration management, environmental management (e.g., ISO 14000 series), health and safety management (e.g., ISO 18000 series), quality management (e.g., ISO 9000 series), asset management (or sustainment, e.g., ISO 55000 series, formerly PAS-55), document management, and change management. You will encounter these systems throughout your career.

On the informal side, there is a continuous renegotiation of meaning as the project team comes to understand more about the requirements and constraints. Different participants initially attach their own meanings to the terms used to describe every aspect of the project, but as the project proceeds, these differences must be resolved or at least understood and acknowledged.

For example, there may be differences in the way that specifications are interpreted. Many people think a specification is a non-negotiable statement of requirements: components cannot be accepted unless they pass all tests at the required level of performance. However, others may think this only applies to production items. Pre-production versions of certain components can have lower performance. Some people may understand a specification to be ‘elastic,’ meaning that as long as the essential requirements are met, other non-compliances could be negotiated away in the form of a price discount, if and when they became apparent.

Some engineers talk about ‘reliability’ issues that others consider manufacturing ‘quality’ problems. Different individuals involved in the coordination ring construct their own knowledge and understanding in different ways, which can make the process of sharing that knowledge a lengthy and difficult one at times.

The most important idea in this discussion around Figure 14.2 is that a major component of engineering activity needed for a project is project management and coordination work. Many engineers spend nearly all their time on this; often, the time spent on calculations, design, and problem-solving can be tiny, as little as 2%. Many engineers think that their project management and coordination work is ‘not real engineering’ because it’s not taught in engineering schools and seems to be non-technical. However, these aspects of engineering work strongly influence project delivery performances, which must improve if we are to restore today’s tarnished image of engineers.

Project planning

Managing a project can be described as a three-step process:

• 1  planning and organisation,

• 2  monitoring progress, and

• 3  completing the project.

Every task within a project also requires these steps.

A well-managed project needs a detailed plan, the first of many project documents.

Even the best project managers don’t get everything right the first time. Instead, nearly every document you create is a living document that evolves and is progressively elaborated on during the course of the project. At each stage, you, your colleagues, and often the client and other stakeholders will get a clearer idea of the requirements. Some documents are still being elaborated even at the very end of a project.

Always look for ways to simplify the requirements without losing detail, and keep documents as short as possible (Figure 14.3).

Negotiate and define the scope of work, calculate the time schedule

This is the single most important job for a project manager: negotiating and reaching an agreement on defining the scope with the client and other stakeholders (see below). Some projects do not involve a paying client; they may be sponsored by someone with the appropriate authority in your own firm. The sponsor instigates the project and can, therefore, be treated as equivalent to the client.

Mostly, the sponsor or client has only a sketchy idea of the requirements. In the early phase of the project, therefore, your main role will be to clarify requirements and specify the necessary details.

Project scope is defined in one or more documents that provide a succinct definition of everything that is to be accomplished by a project.

While everything else can be progressively elaborated, be extremely cautious about elaborating anything in the project scope. This is called ‘scope creep,’ a series of small extensions to the scope, each one being apparently insignificant. Adding anything to the project scope almost invariably means increasing the cost and time to complete the project. Finalising the project scope definition right from the start is one of the most crucial skills of a good project manager.

The project scope enables engineers to prepare a work breakdown structure (WBS), a complete list of work activities to be performed by everyone concerned with the project. Each activity should normally take at least one day to complete and not more than 20 days (four working weeks). Otherwise, it can be difficult to monitor progress.

Another important document, the Bill of Materials (BoM), lists every item needed for the project and how it is to be obtained, transported, and stored.

By specifying all the constraints that determine, for each activity, what must be completed in advance, a computer can calculate the expected time schedule and display this as a Gantt chart (Figure 14.4).

This aspect of project management is almost routine and can be easily arranged with one of the many software packages that are now available.

Specifications

Technical specifications are no longer mentioned in project management courses. However, they are critical for engineering projects.

Why?

Technical specifications define how the quality and completeness of technical work will be assessed. Engineering activities cannot be certified as completed unless the outcomes comply with the required elements of relevant technical specifications and standards. Therefore, project management and costs in an engineering context entirely depend on technical specifications and how they are interpreted.

For example, the way the operating temperature range is defined for equipment influences cost. Typically, this might be stated as –55°C to 125°C, a common military standard operating temperature range. However, if it is stated as −42.5°C to 52.5°C, the equipment cost might be ten times higher. Testing equipment that complies with this latter specification might require environmental test chambers with 0.1°C precision temperature control because the temperature is specified to 0.1°C! These test facilities, required by both the manufacturer and the organisation that certifies compliance, may add considerably to the equipment cost.

What the specification rarely, if ever, describes is the end-user’s needs. Engineers interpret these needs and write specifications such that the final solution will meet those needs, in other words, ‘fit for purpose.’ However, the engineers designing the solution may conceive of far more cost-effective solutions if they can fully understand the ultimate needs or requirements. Almost invariably, that means finding potential end-users and listening carefully to understand their needs.

The specifications will also refer to drawings or, more likely, digital representations of the object to be created—encompassing most, if not all, aspects of the design. These representations of the complete object also provide the details needed to construct the bill of materials and WBS.

On many fast-moving projects, it is common to include a ‘contingency’ in the budget: an amount of money to cover items not specified at the start.

So, the next logical question is: how is a specification structured as a written document?

For this, we need to understand the purpose of a specification: it defines what is acceptable and how we can determine whether the particular deliverable is acceptable or not.

Although the client does not need to understand every detail contained in the specification documents, the people who are responsible for delivering the artefact, material, service, or information will need to understand. As an engineer, one of your primary responsibilities is to decide the level of detail required for the specification document. One way to reduce detail in a specification document is by referring to national or industry standards where details of requirements and testing methods are already available.

There are two basic types of specifications: test and method.

Inspection and testing plans

Apart from the specification documents, the project will also need inspection and test plans (ITPs). ITPs require careful thinking and writing. Along with specifying methods and tests, an ITP must also define what is to happen if any of the inspections or tests reveal non-compliance.

Here is an example of where that was not done. The hydraulic control unit shown in Figure 14.5 was subjected to a long sequence of acceptance tests before leaving the manufacturer’s factory. When the tests were performed on the first units that came off the production line, some of the tests revealed failure conditions often associated with the bundles of black cables visible at the top of the photograph. The test engineers requested that the cables be replaced before repeating the test that had produced a failed result. However, they did not return to the start of the test sequence: they simply repeated the failed test. If the unit passed, then they continued with the remaining parts of the prescribed test sequence. Many of these units subsequently failed within a few weeks of being installed at the end-user’s facilities, even though they were designed to have a service life of at least 30 years. The procurement engineers working for the project management organisation forgot to include a requirement to repeat all the tests after making any repairs to rectify failures detected during the factory acceptance testing. The cause of the failures was unreliable cable connections. When the cables were replaced, new faults were introduced that were not detectable unless the entire testing sequence was started from the beginning.

Risk analysis and management

Project planners assess the likelihood of foreseeable but unpredictable events that can influence the project schedule or outcomes. Each is assessed as critical, moderate, or unimportant by considering the consequences; controls (or back-up plans) are created to reduce the likelihood and/or consequences of such events.

Approvals

Engineering projects can cause significant, unintended consequences for the surrounding community. Because of past failures, engineers now find themselves under detailed scrutiny by government regulatory agencies, which mostly employ engineers. Therefore, engineers find themselves devoting considerable effort to writing applications seeking approval for their projects from government agencies.

Even a small project can require 20 or 30 separate approvals, both within the project organisation for the plan and the budget and from government regulatory agencies. A large project in an industrialised country may require as many as 150 or even 200 separate approvals from several different local, regional and national government agencies.

Final Investment Decision (FID) approval

The most critical approval is the one that authorises finance for the project, beyond the initial project definition and planning.

Experience shows that projects with detailed plans prepared are much more likely to achieve their objectives. The concept of ‘front-end loading’ represents the degree of effort devoted to planning and preliminary design for a project in order to maximise the chance of achieving the stated objectives. Once final approval is given to proceed, work on the project activities listed in the WBS can commence; the monitoring stage of project management also commences at that point.

Monitoring progress—continuous learning

Once the project work commences, project management shifts from planning to monitoring.

As explained before, the essence of project management work is coordinating collaborative work performed by many different people, possibly in many different locations. To do this, it is essential to monitor the progress of every activity, which is not as easy as it looks.

Monitoring requires a cycle of activity, much of it composed of learning. The cycle is repeated regularly, but the time interval depends on how the project is being managed and by whom (Figure 14.6).

Many describe the monitoring process as a simple, endless, repeating cycle: plan, do, check, act, plan . . . One starts with a plan, and then people follow (do) the plan, someone checks the results against expectations, one takes any necessary corrective action and then adjusts the plan, if necessary—repeating the cycle until the project is completed. However, this can easily overlook the learning steps along the way, finding information in documents and computer systems, and discerning what is relevant.

A project engineer or manager not located at the site will typically check on progress every week. They will visit the site and spend the first hour or two with the site supervisor or site engineer, working through every activity and reviewing records of progress. Then, together, they will walk around the site looking at locations where there are hold-ups, unexpected issues, or mistakes that need to be rectified, as well as simply conversing with sub-contractors, tradespeople, and technicians.

Before each inspection visit, a project manager will predict the results from each currently running activity: what they expect to see. By comparing actual progress with expected progress, one can ‘calibrate’ one’s expectations so that predictions become better and better over time.

Critical to all of this, of course, is establishing some way of assessing progress on each activity. Anything that results in tangible production is relatively easy to monitor. The difficulty with a lot of engineering work is that it is intellectual and cannot be directly observed. Intermediate results often give little indication of actual progress. Design work ultimately emerges in the form of drawings and documentation, but these appear relatively late in the process. In the early stages, the best one can expect to see is often just a series of sketches backed up by a conversation with the designer. Here, one can begin to appreciate how important it is to think in advance about the questions posed earlier in relation to each activity.

• How can we assess progress, quality, and other attributes of the work in question well before it is actually finished?

• How can we tell if it’s going to be completed on time, at an acceptable quality, within the budget, and sufficiently long before it is actually needed so corrective action can be taken if required? And, finally–—

• How can we tell that it really has been completed with sufficient quality, accuracy, and within the allocated budget?

One of the most difficult aspects of monitoring progress is a tendency for many engineers (and others) to engage in self-deception, particularly with engineering technical work that is highly intellectual and depends on abstract thinking, such as design and planning.

Many engineers tend to overestimate the proportion of work that has truly been completed. It takes someone with intimate knowledge and deep experience to ask appropriate questions that can expose the gaps that engineers believe have been covered and resolved.

So, as we can see from this brief discussion, the monitoring phase of a project—with its repeated prediction, inspection, evaluation, and review steps—is time-consuming. A project manager’s job is not easy. Also, it can be difficult for others to appreciate the amount of time and effort involved. The project management literature—while often neglecting issues such as the effort required to learn the content of relevant documents—describes many different methods that can be applied to assess overall project progress.

Checking that each activity has been properly completed is also critical for financial management of the project. Project managers authorise payments for contractors once they have completed agreed-upon work on the project. If a payment has been made and, subsequently, mistakes are discovered, it may be difficult or impossible to persuade the contractor to rectify the mistakes, even if there are warranty clauses in the relevant contracts.

Completing the project

A project is completed when all the agreed-upon objectives have been achieved and accepted by the client. Completion is relatively straightforward if the project definition phase included all the necessary details on how the completion of every task was to be certified with appropriate acceptance tests and inspections. Inspection and testing activities would normally be included as an activity in the WBS. Therefore, completion of the project corresponds with the completion of all the activities.

In reality, most projects end up with substantial lists of items that need to be inspected or rectified. The benefits of detailed documentation at the start of the project now become apparent: without details, a project manager can easily end up in protracted negotiation with the client on how to complete each activity. Naturally, the project manager wants to keep the overall expenditure within the budget or as close to the budget as possible (Figure 14.7). The client, on the other hand, has a vested interest in minimising payments to the contractor (or the project organisation).

Normally, the project manager is under intense pressure to deliver the agreed-upon objectives within the original project budget. Unless project documentation is sufficiently detailed, this tension presents the project manager with the tempting option to remove non-essential items from the scope or to simply ignore them, particularly if they will cause the project budget or completion timescale to be exceeded. It’s not easy for a project manager to negotiate an extension to the budget or time schedule as the project draws to a close unless there are well-established reasons that were documented earlier in the project. Inevitably, therefore, many issues are simply ignored and become operating and maintenance issues that must be sorted out later, often by a different owner.

References

1. Hartley, S. (2009). Project Management: Principles, Processes and Practice (2nd ed.). Sydney, Australia: Pearson.

2. Merrow, E. W. (2011). Industrial Megaprojects: Concepts, Strategies, and Practices for Success. Hoboken, NJ: John Wiley & Sons.

3. Project Management Institute. (2017). A Guide to the Project Management Body of Knowledge (6th ed.). Newtown Square, PA: Project Management Institute, Inc.

4. Twort, A. C., & Rees, J. G. (2004). Civil Engineering Project Management (4th ed.). Oxford: Elsevier Butterworth Heinmann.

5. Whyte, J., & Lobo, S. (2010). Coordination and control in project‐based work: Digital objects and infrastructures for delivery. Construction Management and Economics, 28(6), 557–567. doi:10.1080/01446193.2010.486838

6. Winch, G. M., & Kelsey, J. (2005). What do construction project planners do? International Journal of Project Management, 23, 141–149.