5.1 Introduction

This chapter is concerned with how development programmes, of all types, should be managed to achieve the desired results. In this respect, it deals with ‘project management’. The context is programmes for new technologies or new products, and the term ‘project’ is used in this chapter to refer to these programmes of work.

At one level, the development of new technology and products can be seen as an essentially technical process, concerned with, for example, ideas, drawings, calculations, and tests. The core processes of development do obviously centre on activities of this type and many more. However, that is not to say that ‘management’ has no part to play, in either a facilitating or overseeing role. In particular, the effectiveness of development will only be as good as its planning and subsequent direction. This is increasingly the case as technologies or products advance in development maturity. Inevitably, the projects associated with them become bigger and more complex as they move towards production, and hence, they become potentially more difficult to manage. Effectiveness will also depend on how the people staffing the project are led and how the host organisation(s) function.

At one end of the spectrum, there are small‐scale research projects involving just a few people over a period of months or a few years. At the other end, there are major projects, such as the design and construction of aircraft carriers where the engineering effort is measured in millions of man‐hours and which may run over 5–10 years.

Clearly, large projects require more management than small ones, but some basic principles apply to every situation. A distinction also needs to be drawn between projects with a high level of built‐in uncertainty versus those where the tasks making up the project are more concrete.

Every project contains an element of learning, but technology development projects, with a significant level of uncertainty, are as much about learning as they are about the end‐result. Some projects are deliberately set up in this way, for example, the US ‘X’ aircraft projects (X‐1, X‐15) in the 1950s. Major ‘delivery’ projects, on the other hand, focus on very specific outputs that are usually contractually specified in terms of time, performance, quality, and cost.

In this context, research, technology, and software projects may have defined aims, but achievement of those aims involves a lot of exploration, iteration, and false starts. Projects of this type cannot be neatly programmed and managed as a series of predictable tasks. That is not to say, however, that they will not benefit from some basic management attention, which will increase the probability of project success.

Large‐scale product development projects, on the other hand, can be programmed in much more detail, and typically such projects are subdivided into multiple tasks, or subprojects, involving many people over an extended period. Classic project management methods apply in these situations, and such projects will employ professional project managers or project management organisations to handle them. That is not to say that problems will not still arise, but, if identified clearly and early, they can usually be contained.

This chapter, and this book more generally, places the emphasis on work of a modest scale but with relatively high levels of uncertainty. The principles, however, are valid for all projects.

5.2 The Basics

It is surprising how many projects are attempted without paying attention to even the most rudimentary planning. This leads to a waste of good effort. Attention to just a small number of basic points of good practice, which apply to all projects whatever their size or level of uncertainty, can make quite a difference. These points can be summarised as follows:

1. Develop a project mandate. A short, one‐page summary provides the background, purpose, and objectives for the project.
2. Write a project description. A narrative account of the details of the project − the process of writing this will be as valuable as the end product.
3. Compile a milestone plan. A summary, in chart form, of the project's overall timescale and its intermediate checkpoints.
4. Estimate a project budget. A calculation of how much money is needed and when; it also includes an estimate of the manpower required.
5. Draw up a risk analysis. A chart showing the areas where people have expressed concerns that may affect the project outcome.
6. Draw up a responsibility chart. A list of the people required, ideally by name, and their roles, responsibilities, or specialisations. This is sometimes known as a ‘RACI’ chart (responsible, accountable, consulted, informed).

Attention to these points and their wide communication will get a project off to a good start but does not provide a complete solution. Each point is described in more detail below, but, first, two different approaches to project management need to be outlined.

5.3 Different Approaches

The classic approach to managing work of the type described above is to break it down into tasks or activities, build up a cost, timescale, and resource for each task, and then reconstruct it in the form of an overall programme, usually presented in the form of a network. This approach is fine where the tasks are reasonably stable and predictable, do not interact to a high degree, and do not depend on the outcome of earlier tasks, other than their completion. It can be scaled up to very large projects and lends itself to digital methods of project control. Where the project involves learning and hence uncertainty, as is the case with most technology development projects, trying to plan ahead in detail is a futile activity – most of the tasks will have changed by the time they are reached.

An alternative approach is to break the project down into a series of intermediate goals or milestones, representing ‘states’ through which it must pass. This approach is sometimes known as ‘goal‐directed project management’ and is described in detail in Ref. 1. Each goal takes the form of a statement such as: ‘when …….has been achieved’. Detailed activity or task planning is restricted to the upcoming goals, whilst those later in the project are not planned until they become relevant and the learning from earlier stages has been absorbed.

5.4 Different Forms of Project

Figure 5.1 illustrates the different forms that projects can take. The danger zone is the top right‐hand corner where projects are both complex and involve a high degree of learning or uncertainty – these usually go badly. Projects can also drift by accident into this zone; for instance, a major product development project, apparently of low uncertainty, can find itself in the danger zone if elements of its technology prove to be underdeveloped or if the scope of the project creeps beyond what was agreed.

		DANGER ZONE!
High		Large research projects
	Small research projects
Uncertainty		Public‐sector IT projects
		Drift!!
Low		Major construction projects
	Routine work
Uncertainty		Major product development
		projects
	Low Complexity	High Complexity

Technology and product projects can start using the goal‐directed approach and then move into the classic approach for the commercialisation phase. The key to this transition is knowing when the technology development has reached a point where its later risks are relatively low and hence the classic approach can be used. Chapter 3 covers the topic of technology maturity.

5.5 The Project Mandate or Charter

The project mandate or project charter is the first step in formally defining a project. An example is shown on Figure 5.2. It should be confined to one page, to make it manageable, and used to gain acceptance in principle for a project by laying out the basic approach – what it's called, who is supporting it, who is running it, what are its aims, goals, and objectives, what it will cost, and when it will be complete. If these points can't be agreed, there is no point in going further. As with most early‐stage activities, the value comes more from the dialogue that the mandate creates rather than the finished document.

5.6 Project Description

Once the mandate has been agreed, the project can be fleshed out in more detail. Figure 5.3 provides a summary of the potential content of a project description. The details will vary from one project to another, but this is a starting point. The volume of content will also vary widely: a small project might only need four or five pages. Large, complex project may need hundreds. As with the mandate, the value comes more from the dialogue that the document creates rather than the finished item, although in the case of the project description it is likely to prove useful as a future point of reference and it should be updated as the project proceeds.

This structure might be considered the minimum for a reasonably comprehensive project description. Others would advocate more detail. For example, in his book Total Design, Stuart Pugh (Ref. 2) recommends over 30 categories of information. There is always a balance to be struck between too little and too much information: too little and the product might not meet market or customer requirements; too much and the scope for initiative is reduced. As an example of the latter, the author has experience of a publicly procured rail project where the buffet car's microwave oven enjoyed five pages of specification. In this situation, there is very little opportunity for innovative solutions and problems are likely to be blamed on the specification.

5.7 Timing Charts

A timing chart or Gantt chart represents the simplest and clearest way of laying out a basic plan. The method was developed originally in the early 1900s by Henry Laurence Gantt, who could trace his ancestry back to the Norman invasion of England in 1066. Interestingly, William the Conqueror's success has been put down to careful planning and not launching his ‘project’ until everything was in place.

Gantt himself was a mechanical engineer and a colleague of F.W. Taylor, with whom he developed the principles of ‘scientific management’. He is still remembered by the ASME Henry Laurence Gantt Medal.

It is essentially a graphical method of planning the work on a project, showing interdependencies, and recording progress. It was first applied as a production work scheduling tool in a factory environment – see 1903 paper ‘A Graphical Daily Balance in Manufacture’. It does rely on the activities being quite finite and predictable, with clear start and finish points, but even where this is not the case, a timing chart provides a basic frame of reference from which to manage the work. Figure 5.4 is an example of a very simple chart for a hypothetical technology development project.

The approach can be expanded out into very complex networks for large‐scale projects. The sequence of activities can be shown in terms of which tasks must precede others or finish concurrently. Critical paths, which determine the overall timescale of a project, can be identified and subsequently managed. Activities can be assigned to resources – either people or physical assets or computing resources – and hence the loading of resources can be estimated. This enables detailed cost estimates to be compiled as a function of time. Actual cost expenditure can be monitored and compared with the value of the work completed – sometimes known as the earned value.

Detailed plans of this type are relevant to high complexity/low uncertainty projects such as construction programmes where the details can be predicted accurately and well in advance. Several large‐scale software programmes are available for such projects. Using such tools, the concentration of management effort is on identifying problem tasks, which are off‐programme, and then remedying them. If too many tasks become problematic, then such projects can become close to unmanageable, emphasising again the importance of reducing risk before projects are initiated.

5.8 Milestone Charts

An alternative approach, especially valid for early‐stage technology development projects with more in‐built uncertainty, is a milestone chart, of which Figure 5.5 is an example. The project is first broken down into a small number of separate result paths, which represent the principal streams of activity in the project. Milestones are then agreed, representing key points of development in the project – there are 12 in the example.

These milestones need to be spread evenly across the project, acting in a similar manner to ‘way points’ in aircraft or sea vessel navigation. The milestones should have clear deliverables associated with them, and it should be easy to judge whether a milestone has been achieved.

The process of agreeing to these milestones will create a common understanding about the details of the project if it is carried out as a collaborative, team activity. Conversely, an imposed plan will have little ownership and will not be respected.

The planning method outlined above concentrates on results – ‘what’ must be completed – and provides a clear basis for monitoring whether the desired result has been achieved. The achievement of the results requires more detailed planning of tasks or activities, which can again be done as a team activity once the major milestones have been agreed. It is important that this logical sequence is followed as there is little point in planning details if the principles haven't been agreed. The approach could also be considered as a ‘pull’ system, similar to Kanban in manufacturing, where information is generated to match the needs of an immediate deliverable rather than just generating engineering information, whether or not it is needed.

The term (vertical) value stream mapping is also used to describe this approach, although this terminology can lead to confusion with value stream mapping as a means of identifying waste in established and relatively stable processes.

A milestone‐based approach is commonly used in early‐stage software projects. The milestones are sometimes described as ‘scrums’ and the intervening activities as ‘sprints’, whilst the overall approach is described as ‘agile project management’. Chapter 12 provides some more information on this topic, as does Ref. 3.

5.9 Risk Management

All projects carry risks which can undermine the achievement of project goals. The purpose of risk management is to bring these risks out into the open so they can be identified and then addressed. Risks which are hidden through ignorance or fear will come back later, causing problems and delays. In this context, the section of this chapter is concerned with project risks, rather than technical risks which are the subject, in detail, of Chapter 7. However, a project risk could be an inadequate technical risk management process.

Figure 5.6 illustrates how a project risk management process might be tracked – somewhat simplified. The steps are:

1. Identify a potential risk, with a tracking number assigned if the project is complex.
2. Assign the risk to an owner, who will have responsibility for managing it.
3. Assess the severity of the risk as originally identified – usually by estimating the impact and likelihood on a scale of 1–5 and then multiplying these two factors.
4. Compile an action plan and who will undertake the required actions.
5. Assess the current, or residual, risk once actions have been undertaken.

Risks severities using this method are usually categorised as ‘high’, ‘medium’, and ‘low’, as illustrated in Figure 5.7 and the aim obviously is to undertake actions, which move all identified risks into the ‘low’ category. Most risks may start as ‘high’ or ‘red’.

Different projects have different risks, and some are inherently more risky than others, especially if they are of an exploratory or experimental nature. However, there are a number of common risks affecting many projects:

1. Availability of people, especially in the early stages of projects
2. Overoptimism concerning timing – especially assuming that nothing will go wrong
3. Overspending
4. Availability of physical resources – issues with offices, workshops, analytical or modelling facilities, especially in the early stages of projects
5. Lack of clarity about project objectives
6. Lack of clarity of roles of either individuals or organisations, especially when the project involves collaboration between different parties
7. Failure to understand customers' needs

Dealing with the above will never guarantee a problem‐free passage for every project but it will reduce the likelihood of problems and will bring them out into the open more effectively and earlier. It should be remembered that postmortems on failed projects have usually shown that problems did not come out of the blue but were known about and could have been acted upon if only they had been flagged up at an early enough stage.

5.10 Resource Planning

Estimating and planning the manpower needed to undertake the work is an integral part of setting up a new technology or product development programme. It is required first to provide a cost estimate of the manpower element of a project and second to secure the people needed for the work itself. There are no first principles from which to make these estimates, which must therefore be derived from experience. The ideal experience would be similar, and fully completed, projects. Failing this, work in a similar field can be used, scaled up or down to suit the situation.

There is a natural tendency to be optimistic when making manpower or timing estimates; budgets are never quite enough and time is always short, so there is pressure to underestimate and assume that nothing major will go wrong. Hence, when using historic data, the actual resource consumed should be used – not what it should have been if everything had gone well. Figure 5.8 illustrates what a resource plot versus time might look like for a typical project. The plot of cumulative resource consumed versus time invariably follows an S‐shaped pattern, and they are widely known as S‐curves.

When estimating manpower needs, which are inextricably linked to the time allowed for the project, there are three particular points to bear in mind:

1. The divisibility of the tasks – some jobs need to be undertaken by one person, whereas others can be subdivided among several to achieve a faster result.
2. The effort to train, manage, and coordinate the team increases with its size.
3. Some tasks, such as durability tests, take a fixed length of time independent of the level of manpower applied to them (pregnancy generally takes nine months no matter how many people are assigned to monitor the progress).

These points present practical constraints on what can be achieved within a given timescale – see Ref. 4 for more discussion of these points. Early‐stage tasks usually rely on the work being done by a small number of skilled individuals, and they cannot be shared out until a certain amount of progress has been made and a brief can be given to subsequent team members. If this early effort is held back by difficulties in manning the initial stages of a project, a frequent problem in most organisations, it is very difficult to catch time back by overmanning in subsequent phase of work.

Larger engineering organisations often forecast their future resource consumption looking ahead several years, resulting in a plot of the form of Figure 5.9 below showing the aggregation of the projects ‘on the books’.

Forecasts of this nature should include some level of support to existing products, often taking some 20% of effort. Graphs of this type usually show a deficit of resource in the short to medium term as new projects pile up, resulting in a ‘bow‐wave’ profile to them. The consequence of this form of resource profile, as noted above, is that new projects either start late or are undermanned in their early stages, also resulting in delays.

One final point: once the work has gained momentum, it may be the case that adding new manpower does not necessarily speed up the work. The author has experience of one large and complex project where the work accelerated when manpower was reduced – too many people were getting in the way of each other.

5.11 Project Contingency

As well as estimating the most likely cost and timescale of a project, it is good practice to estimate a contingency amount representing, for example, the upper and lower boundaries of cost and time parameters. Management processes for large, complex projects invariably include contingencies along with procedures for releasing them and measures of contingency usage versus the level of completion of the project.

Clearly, early‐stage projects are more difficult to predict than those conducted at a later stage where there is more detailed definition of the project content. Hence, contingencies expressed in percentage terms will be higher at early stages (but lower in absolute amounts because the projects are smaller in value), reducing as the work becomes more clearly defined. These contingencies cover both the effects of estimating errors (e.g. costs forgotten) and problems encountered.

Several standards suggest the level of contingency that should be applied, in money terms, to projects at different stages of development. In the Association for Advancement of Cost Engineers' standard, for example, a ‘Class 5’ estimate, the earliest, includes overrun boundaries of +30% to +100% and underrun boundaries of −20% and −50%. The corresponding boundaries for ‘Class 1’ estimates are +3% to +15% and −3% to −10%.

Contingencies are almost always expressed in monetary terms. On later‐stage delivery projects, contingency sums can be spent to find ways of recovering the time effects of problems and thus minimise time overruns. In this situation, money can be converted into time. On early‐stage projects, the number of people involved is much smaller, and there is more specialisation so there is much more limited scope for time recovery by overmanning beyond simply putting in more time. On early‐stage projects, there is therefore an argument for regarding the percentage overrun boundaries as being relevant to both time and cost.

An active process of contingency identification and management is always a good way of dealing with the sensitive and inevitable subject of how to deal with project problems.

5.12 Organising for Projects

All projects, no matter how small, are organisations in their own right with very specific purposes. They may need to draw in a very wide range of skills, in addition to the technical and engineering skills often forming the core of technology or product development projects. For example, they will need manufacturing, marketing, financial, and commercial skills. Some will be required full‐time and others for part of the time, and perhaps for only part of the project.

Given this background, there are then two ways in principle in which organisations can arrange their projects, with a wide variety of hybrids of the two models:

1. Functional model. The project's participants remain part of their ‘home’ discipline but are deployed onto the project for part, or all, of their time.
2. Project model. The participants are transferred, including physically, to a project for the bulk of its duration.

Both models have their advantages and disadvantages. In the case of a start‐up organisation, the company may, in effect, be the project so no choice is available. With larger companies there is a choice. The relative merits of the two models are (Figure 5.10).

Where companies have large, multiyear and complex projects, the functional model is rarely effective and most companies in this situation adopt the dedicated project model. However, the disadvantages are real and the functional model can be made to work on relatively large projects if attention is paid to personal interaction and team development. This often goes against the grain with engineers who like to be given a task and be allowed to get on with it, undisturbed.

Many times, however, some form of hybrid is used, sometimes referred to as a ‘matrix’ organisation. Examples include:

1. Strengthening the project axis by having a permanent project organisation with heavyweight project managers but retaining the functional organisation and its advantages
2. Having a permanent project core team but deploying other resources into the team when needed
3. Having a permanent project team dealing with a range of related projects rather than one, in effect taking responsibility for a business stream rather than a project

As such, they have a degree of independence from the host organisation, creating both advantages and disadvantages.

5.13 Monitoring Small Projects or Subprojects

All projects, especially those with a strong element of learning or exploration, need to be monitored and kept on track. By their nature, such projects throw up issues rather quickly. This does not mean there must always be frequent and radical changes of course. Rather, the nature of development projects means that effective solutions to issues need to be found frequently and quickly as work progresses. This thinking applies to all projects, either to small projects in their own right or to the individual elements of larger projects.

The most effective way of doing this is the daily or weekly ‘stand‐up’ meeting where all the participants get together to discuss progress, problems, and immediate action plans. Given the interactive nature of development work, such meetings are also opportunities to raise emerging or partially understood issues.

A project board, or a ‘project on a page’ document, can be used as the focal point for such meetings. Figure 5.11 is an example of such a board.

As well as background facts about the project or subproject, the board has three principal areas:

1. Graphical presentation of the timing plan and resource and cost consumption versus time, updated as the project proceeds
2. Summary of the current risks and their red/amber/green status
3. List of current tasks and issues, including responsibilities

The approach is informal and relies heavily on personal interaction but is very effective. The concept can be extended to creating a project war‐room (Obeya in Japanese) with all relevant project information on display and placing the emphasis on visual management, including reporting to senior management, rather than relying on written reports. It is one of the approaches used by Toyota and is an element of Toyota's rapid product development systems. Something similar is used in the field of software development where the project room is sometimes known as an ‘information radiator’.

These approaches can also be used for elements of large projects, but these will almost certainly need a more formal, documented approach for senior management review.

5.14 Approval and Formal Monitoring of Large Projects

A common way of overseeing large projects is through a ‘stage‐gate’ or ‘phase‐gate’ process. In this approach, a project is divided into a series of phases with formal evaluation gates at the end of each phase. For the project to proceed to the next phase, it must demonstrate that the pre‐agreed criteria for the previous phase have been met; it might also be necessary to show that the resources are available for the next phase (money, people, and facilities).

This approach is used in both product and facility‐related technologies and has its origins in the mid‐1980s through the work of Professor Robert G. Cooper, who studied the practices of successful companies at that time, many of whom were using already some form of gated processes – see Ref. 5. It is used widely in the oil, gas, and process industries, as well as in product‐related organisations.

In the context of developing a new technology, a stage‐gate process of this type only becomes relevant when the technology has entered the ‘product development’ phase of its maturity, i.e. there is a committed plan to commercialise the technology through a launch product. The technology readiness would therefore be at approximately TRL5 (technology readiness level) when being scoped into a project and TRL 6 when the business case is agreed and a commercialisation project, including a new technology, is launched.

A five‐phase model is quite common with, for example, the following phases:

1. Defining the scope of a project
2. Developing the business case and agreeing the go‐ahead
3. Development of the product itself
4. Validating the product
5. Launching the product

The criteria for evaluating whether a gate has been passed can include:

1. Technical development status
2. Manufacturing development status
3. Marketing readiness
4. Commercial factors
5. Business case

A tabular summary of a potential stage gate structure is tabulated in Figure 5.12.

There is also the question of the rigour, which is applied to any evaluation – tasks that are allegedly 90% finished are a particular problem. A distinction can be drawn between essential criteria, without which progress cannot be agreed, and desirable criteria, where some level of tolerance might be applied. In fact, some weeding out of nonessentials is frequently required.

The process can be applied in a very structured way, with preset deliverables, predefined criteria, and specific project decisions categories such as: proceed, resubmit, hold, or cancel. Hence, the process does require some independence of thought, a willingness not to fudge issues, and a preparedness to cancel projects. The approach is best suited to large companies with multiple projects, but the same disciplines can be used in small and developing companies even though reviews and decisions may be made by a limited number of people without the support of teams preparing large quantities of data.

5.15 Project Management versus Technology Maturity Assessment

This chapter has dealt with the management of technology and product development projects. It may appear to overlap with Chapter 3, which is concerned with evaluating the maturity of technology. There is, however, a clear distinction between the two. Project management relates to the tasks, costs, and timescales for achieving prescribed objectives, which could be technical (such as achieving defined technology maturity level) or could be business‐related (such as launching a new product). Technology maturity development, on the other hand, is concerned with achieving a certain level of technology readiness, as measured by TRL scales and implying a certain level of technical risk reduction, with project management as a mechanism for overseeing this process. A good understanding of technology maturity is a prerequisite for competent project management.

5.16 Concluding Points

New technologies and new products are generally delivered through projects, that is, time‐bounded activities with specific objectives. As technology advances in maturity, the projects for delivering new technology or new products become more structured, more complex, and more commercially focused, with an expectation by investors that results will be achieved. Whilst agile or highly responsive attitudes can dictate the speed with which projects are completed, the basic disciplines of project management are valid at all phases of development − the ‘fuzzy front end’ through to multimillion‐pound commercial projects − and should be understood by all engineers whether they are working at research‐oriented or delivery‐oriented activities.

References

The goal‐directed approach was first developed in Norway and is not very well known but is well thought through. Its principles are quite similar to “agile” methods (see below):

1. 1 Andersen, G. and Haug, K.P. (2009). Goal Directed Project Management, 4e.

This book is one of the classics of product design and contains a lot of very practical information, although the details have been overtaken by time and the work precedes the widespread adoption of CAD and other digital methods:

1. 2 Pugh, S. (1991). Total Design. Englewood Cliffs, NJ: Prentice Hall.

For a straightforward overview of agile methods, this book is a good introduction:

1. 3 Layton, M.C. (2012). Agile Project Management for Dummies. Hoboken, NJ: Wiley.

There is some interesting material on how to plan and estimate the resources needed for software, and technology, projects:

1. 4 Brooks, F.P. Jr. (1982). The Mythical Man‐Month – Essays on Software Engineering. Reading, MA: Addison‐Wesley.

Robert Cooper was one of the first to publish material in the 1980s about stage‐gate methods, and his work is always well researched:

1. 5 What's Next?: After Stage‐Gate Research‐Technology Management January – February 2014, pages 20–31, Reference Paper #52 by Robert G. Cooper