CHAPTER

Project management: content, history and current issues

Introduction

Aims and objectives

Project management is an important topic in operations management, and is a core business process in both ongoing activities and organizational change. This chapter highlights the concepts and the methods used in project management.

After reading this chapter you will be able to:

Identify projects and their role in operations and in organizational change

Classify project management approaches

Break down a project into key project processes and phases

Apply the main tools and techniques of leading-edge project management.

Projects: an introduction

Projects are low-volume, high-variety activities. Each project is at least somewhat unique in the process it uses or in the desired outcome. Because projects are finite – like the Sydney Olympics, they have a definite beginning and end – they are different from other process types (see Chapter 4), which are often repetitive processes. The importance of the project transformation processes is evident in that it is the only process type in operations management to have its own subject area.

Projects have two roles in operations; delivering what operations does, and changing the operation. Both roles within projects take place at both the individual and organizational levels.

Operational projects conducted by organizations are usually very different from individual projects. Peters (1999) estimated that about 50 per cent of all revenue-earning activities at the organizational level are conducted as projects. These include consulting contracts, advertising campaigns, new product introductions and building construction. Besides the economic contribution of projects to businesses, not-for-profits use projects to achieve their goals – for example, charity fund-raising.

Projects are also used for individual and organizational change. Individual change projects might include studying a new project, going on holiday or moving house. Organizational change projects might include redesigning key business processes, or introducing information systems or other new working systems. Table 8.1 shows some examples of both.

Organizational projects can be described using the terms that have been used to describe process design: scale, scope and competitive objectives. Scale describes the size of the project or the amount of resources involved. Scope describes the amount of work that the organization will perform directly. The competitive objectives for the project are provided by the operations strategy, typically as time, cost and quality objectives for the project.

Projects may also be classified by whether they are carried out:

By one individual, such as a short review of a procedure or a presentation

By one function, such as end-of-year reporting by Finance

Across functions, such as implementing a new ERP system

Across organizations, such as jointly developing e-business systems.

Many organizations are now project-based, particularly in hyper-competitive industries such as mobile communications, where in organizations such as Motorola and Vodaphone the role of project management has evolved from being peripheral to core within the business.

Table 8.1 Examples of operational and change projects

	Operational projects	Change projects
Individual	Carry out work tasks	Study a course
Organizational	Earn revenue	Introduce new methods of working

Approaches to project management

Project management is critical for all functions, not just for operations. As this section shows, project management has become increasingly important, although this development has not evolved as quickly as operations management (particularly operations strategy).

Project management has developed through three stages, from no defined methods to well-defined methods to strategic project management, as shown in Table 8.2.

Table 8.2 The development of project management

Stage	Era	Characteristics
1	Pre-1950s	No generally accepted or defined methods
2	1950s	One best way approach, based on numerical methods established in the USA for managing large-scale projects
3	1990s	A contingent approach based on strategy and the convergent model of operations

Obviously, small- and large-scale projects were undertaken before the 1950s. Individuals managed events and other situations – for example, the Pyramids were constructed, wars were fought, and products were developed. However, project management as a way of integrating individuals and activities in any formalized manner did not exist until the 1950s.

During the 1950s, formal tools and techniques were developed to help manage large, complex projects that were uncertain or risky. The chemical manufacturer Du Pont developed Critical Path Analysis (CPA) for scheduling maintenance shutdowns at the company's production facilities. At the same time, the defence contractor RAND Corporation created Programme Evaluation and Review Technology (PERT) for planning missile development.

These tools focused nearly exclusively on the project planning phase, and there were no close rivals for their use. Since then other methods, such as Critical Chain Methods, have been developed that can be used for planning and controlling projects.

As well as project planning and control, the role of projects is today being reconsidered (see for example, Maylor, 1999; Gray and Larson 2000). As for other areas of operations, a strategic approach is taken to the design of the project process, rather than the highly reactive approach that has been prevalent until recently. Conventional methods developed to manage large-scale direct-value-adding projects with timescales of years, such as heavy engineering, are too cumbersome when projects require short-time scales to exploit market openings quickly, in particular in an information-based economy.

The third stage of project management emphasizes the strategic role of projects, especially the processes that the project manager must put in place to deliver the end objective of the project and satisfy the needs of all the project's customers. In this new approach project managers become project integrators, responsible for integrating the required resources, knowledge and processes from the project beginning to end. A key integrative skill is recognizing needs and sourcing their provision within the context of key project processes.

Key project processes

Projects are run through processes, as we have seen in past chapters for other aspects of operations. These processes are often common to many projects. Indeed, studies of world-class organizations show that ‘the best are better at getting better’, and this is achieved through continuous improvement. The 3-D model (shown in Figure 8.1) describes three phases in continuous improvement for project management:

Phase 1: Design it – map out the process that will deliver the project output

Phase 2: Do it – carry out the process

Phase 3: Develop it – critically review all of the activities (including planning) to see what could have been done better, and capture this knowledge for future projects.

The project manager plays a different role in each project phase. In Phase 1 the project manager is concerned with the design of the project process, including project planning. The output from this phase is the plans and objectives for the project team. The project is often reviewed at the end of Phase 1 and the decision to go ahead or not is made.

Figure 8.1 The 3-D model.

In Phase 2 (provided the project goes ahead) the project is executed.

In Phase 3 the processes and outcomes of the project are reviewed to make sure that knowledge – at least ‘what worked’ and ‘what were the problems’ – is captured and used for future projects.

Project complexity

Project complexity determines the nature of process design and the role of the operations manager. Scale and scope together describe project complexity. Project complexity can be defined as:

Overall complexity = Organizational complexity × Resource complexity × Technological complexity

Organizational complexity results from the number of people, departments, organizations, countries, languages and time-zones that members of the project will have to deal with.

Resource complexity describes the project size or budget.

Technology complexity results from the novelty of project elements – while a technology may not be new, it may be being applied in a new way – or their interaction with other project elements.

Overall complexity is related to the scale of the project management task. A small project within a single department is generally much less complex to manage than a large, cross-organizational project such as the Channel Tunnel.

Project formality also affects the scale of the management task. In many projects detailed documentation must be prepared at each stage of the process, and any changes approved. Other projects focus on the end results, with a generally informal process.

The Project Management Institute Body of Knowledge (www.pmi.org) defines the following areas as where there is established knowledge relative to the different parts of the project process:

Project Integration Management – developing an overview of the project plans and how they will be delivered, and how changes to these requirements will be managed over the life of the project.

Project Scope Management – deciding what is included and, just as importantly, what is NOT included in the project. Scope management also leads to a process of approval or sign-off, where the key project customers or stakeholders agree the scope and how, if at all, it can be changed during the project.

Project Time Management – taking the overview plan and breaking it into activities, which are then placed into a schedule. The time management element also includes a plan of how progress will be monitored.

Project Cost Management – considering the resource requirements for the project and, by combination with the time plan, showing when they will be required. This leads to the compilation of a budget and provides a key means for cost control (such as monthly cost reporting).

Project Human Resource Management – planning how the organization will be structured for the project, how to put the right team into place to work on the project, and how this team will be developed over the life of the project.

Project Communications Management – planning how the objectives of the work will be communicated to the team and other parties with an interest, how information will flow (e.g. how do people know when to start doing an activity?), and how progress and team performance will be reported.

Project Risk Management – identifying potential problems and their magnitude, and deciding how these can be prevented or mitigated.

Project Procurement Management – considering how and when supplies are needed, the plan for their procurement, and how the process will be administered.

These provide an overview of the key processes that the project manager is concerned with. To these we would add:

Project Strategy – developing the strategic role of project managers to make a positive contribution to competitive advantage through this capability (see below for further discussion of the strategy process).

Project Stakeholders – managing the expectations and perceptions (as discussed in Chapter 1) of the group of stakeholders (both customers of the projects and those involved in the process).

Such aspects provide for a comprehensive consideration of the project process by the operations manager. The first task, which incorporates aspects of every one of these, is process design.

Designing the project process

A strategic approach to processes requires a direct link between the organizational strategy and operations strategy (Chapter 2), and between operations strategy and the project. The link between operations strategy and the project is expanded in Figure 8.2.

Figure 8.2 The project process.

Programme of work

A programme of work can be defined based on the operations strategy, which determined the scale, scope and project objectives. A programme usually includes many projects, and spells out the budgets and priorities for each one. European mobile communications providers are working to develop their third generation (3G) products. Within each 3G programme there are many individual projects being undertaken – e.g. developing the network infrastructures, the interfaces with the phone manufacturers, and the products that will be offered through this medium.

The aggregate plan shows the workload for people and teams for the project and other operations workload. Without an aggregate plan in place, organizations often significantly overload people and teams, causing them to become unfocused (like the operations described in Chapter 2). For example, one of the authors of this book encountered a particular organization's new product development team that had 72 projects going on at one time, with only eight people and one manager in the team. A staff member described it as chaotic, with work scheduled by ‘whoever shouts loudest’. Project efficiency and staff morale were low, and stress levels were high. Aggregating the projects and matching the workloads to the available resources is capacity planning, and is used extensively in other aspects of operations (see Chapter 6).

Even if the aggregate plan is acceptable, multiple projects can reduce efficiency due to changeovers. As with operations processes, there can be significant ‘set-up’ costs when people switch between activities, since they often need to refamiliarize themselves with the work they were previously doing. In IT, for example, programmers need to concentrate on what they are doing, and changing them to working on something else requires time to regain their original speed. This is a strong argument for operations focus – working on only one or a very limited number of tasks at a time.

Budgets are allocated as part of the programme of work. These are usually made annually and reviewed quarterly.

The priorities for different projects are also assigned at this stage.

Project planning

Project planning takes in the project objectives, usually stated as time, quality and cost objectives. It recognizes that there may be trade-offs between these – for example, when you are working to tight deadlines on a personal project, you may have to compromise either on the quality of the work (not as extensive as you first wished) or on costs (hiring in outside help to complete part of the work). The most important thing at this stage is knowing whether time, cost or quality is most important, so that the process can be planned accordingly.

Once the main objective has been identified, the project manager's next responsibility is to turn these objectives into reality. This process is shown in Figure 8.3. Key questions are associated with each stage.

Once time, cost and quality objectives have been set, the project manager must show how the project will be delivered (or at least that it can be delivered). An overview plan states how this will be done, and is required by many clients as part of awarding contracts. After the overview plan has been developed, detailed plans are generated by the project manager, a project planner, or other administrative support personnel in the project office.

Figure 8.3 Turning the objectives into reality.

The overview plan

The overview plan answers three questions:

1   How will the project be delivered?

2   Is the project feasible?

3   Is the project worthwhile?

If the overview plan shows that the project is possible, the project manager must also demonstrate that it is feasible, and that it can be carried out within the time, cost and quality constraints. Feasibility is a particular problem in project management. A goal of repetitive operations is reducing costs, but the operation has a relatively stable base since it is ongoing. No such stability exists for projects, particularly when many firms are bidding for a contract and the cost target may not be clear. Here, the project manager must balance incomplete information about the work to be done with the costs of finding out more without a definite chance of a successful contract bid.

Most organizations also require projects to be worthwhile – there must be some recognizable benefit relative to the resources of time, money and effort invested by the project team. Many organizations stop with the feasibility question. The criteria for being worthwhile are only partly financial, as other projects will be competing for the same resources. The organization's strategic objectives should be considered here. However, a critical issue is the managerial time and energy that must be devoted to each project – what will be the return in present or future benefits to the organization? This also raises the question of opportunity cost – could these resources be put to a better use elsewhere?

Having determined the project objectives, the next task for the project manager is to engage in planning – initially at an overview level and subsequently, should the project be attractive, at a detail level.

Project planning

Work breakdown structure and stage-gate planning

How do you eat an elephant (or its vegetarian equivalent)? Just one slice at a time.

An overview plan breaks the project down into manageable units of work, known as a Work Breakdown Structure (WBS). This simple-sounding process is vital because it defines the relationship between different parts of the project. For example, a railway refurbishment project was broken down as shown in Figure 8.4.

Once the overall project has been broken down into subprojects (for example, renovate trains), each subproject can be assigned to a firm that specializes in that particular area. Each subproject may also be broken down further (level 2 and so on) until a micro-level list of tasks is identified that can be performed either by individuals over short time periods or by subcontractors, who perform them as projects. Tasks are numbered following the following convention, which is similar to a Bill of Materials in manufacturing planning:

Figure 8.4 Work breakdown study of a railway refurbishment project.

1. Renovate railway (Level 0)

1.1 Renovate trains (Level 1)

1.1.1, 1.1.2, etc. Subtasks of the above

The firm managing the railway renovation project coordinates the different subprojects and contracts. This can be challenging, as London Transport found when new trains were delivered to run in a refurbished underground line. The new trains would not fit through the refurbished tunnels, which was due to a breakdown in communication between the contractors working on the trains and those working on the tunnels. Most subprojects depend at least partly on other subprojects, and breakdowns occur when these interfaces aren't managed.

Whilst the WBS structures the project, there are other means for structuring the process. Breaking down the process for delivering the project into phases with gates between the phases is a way of putting checks in place to make sure the project is meeting objectives. This is known as the stage-gate process (Cooper, 1988), which originated in the Phased Delivery Processes (PDP) developed by the US military.

The project review at a gate will determine the answers to the following questions:

Is the project making satisfactory progress compared with its original goals?

Do the project objectives need changing in light of any events since the project was started (e.g.technological or market change)?

Are there any problems that need other management attention?

Should the project go on to the next phase (a go/no-go decision)?

Without phases and gates in place, projects can run on without meeting their objectives. In the 1970s, Sir Clive Sinclair set out to produce a family vehicle for under £1000. This would have been a real breakthrough, particularly as it was planned to be electric and therefore seen as environmentally favourable as well. The project team lost its way as the project progressed, and the C5 recumbent electrically-assisted tricycle was universally derided on its launch in 1980. Phasing the project with clear gates would have prevented the project from being completed.

Early gates in the project process are intended to catch ‘lemons’ – projects that have a low chance of success, but continue because managers become attached to them (Drucker described them in 1955 as ‘investments in managerial ego’). This prevents them from consuming further resources.

Some gates are also milestones. These are events in the process, not only the beginning or end, but also significant intermediate events such as completion of a particular component of a new product or a particular subproject in a contract. Companies often receive interim or stage payments for the work already carried out at milestones.

Both the WBS and the stage-gate break the project into manageable units of work by the time in which the work must be completed.

The detailed plan

After the overview plan has been developed and project planning has taken place, the detailed planning stage can begin. This stage focuses on the time, cost and quality objectives.

A good saying to remember here is: ‘If you fail to plan, you plan to fail’. Whilst planning alone will not guarantee project success, it can be used to model a process, which facilitates:

Process optimization, to change the way that resources are deployed or processes arranged

Elimination of potential problems or mitigation of their effects.

Modelling can be done away from the process (off-line) without having to create a real operational process to experiment with. This lets planners save both time and costs. Project managers can draw on a number of modelling techniques. Later in the chapter we will introduce three methods for project planning; the Gantt chart, critical path analysis, and the critical chain.

The overview plan lists activities that various contributors (individuals, functions, suppliers and contractors) to the project will carry out. This list comes from the WBS, and is phased. The next job for the project planner is to find the relationships between activities, specifically which depend on other activities to start or finish. For example, access to particular data might be required for a consultancy project. The project manager must negotiate this access so that the consultants can obtain the data in time for the investigation to proceed. These dependencies are typical of all projects, from small personal projects such as study or work assignments to very large projects. Knowing these dependencies in advance prevents unnecessary delays – in a consulting project, consultants would not be able to do their jobs until they had access to the data.

Identifying dependencies allows the project planner to make verbal statements of these relationships – ‘Complete activity A before starting activity B’ or ‘Complete activity C before starting activities D and E’. This is useful, but rapidly becomes unworkable with many activities and/or dependencies. Different modelling techniques can be used to describe activities and their relationships, including Gantt charts, Activity-on-Arrow diagrams and Activity-on-Node diagrams.

Gantt charts

Gantt charts were discussed briefly in Chapter 6 because they can be used in all types of operations planning. They are often used in project environments. Gantt charts were developed by Henry Gantt, a consultant who worked with F. W. Taylor, in the late 1800s. They were used for production planning as a simple way to show activities and the time they take using a horizontal bar chart. The Gantt chart proved very useful for scheduling highly routinized tasks in mass production systems, since it allowed the tasks of individual workers to be planned out in great detail (in minutes or even seconds).

The Gantt chart was first used in project management in the 1950s, and is among the most accessible of project management tools and techniques. Of course, projects aren't usually planned in minutes, but in days, months or weeks. A project to run a short course was verbally stated as:

1   We will meet on 8/01/01 to decide whether or not to go ahead with the course.

2   Following this we need to determine in detail the target market. This will take 2 days.

3   Once we have done that, we can outline the course content (3 days) and book a venue (nominally 1 day).

4   With these in place, we can develop the marketing material (5 days) and then will need a further 5 days to have it printed and sent out to our target market.

5   While we are awaiting responses and taking bookings, we can develop the actual material that will be presented on the course. The material will take 10 days to develop.

6   We need to allow 15 days for people to reply to the marketing material.

7   We will then run the course over a 2-day period.

Figure 8.5 shows a Gantt chart developed for the project. This clearly shows the benefits of using even a simple graphical technique compared with the verbal statement. Even though there are only a few activities in this example, the Gantt chart is easier to interpret because it shows both the dates and dependencies (arrows) between activities. It also shows which activities are sequential (one after the other) and which are in parallel (at the same time).

The Gantt chart, although simple and popular, does not allow much scope for optimizing the project plan or identifying potential problems. The optimum plan might be to run the course as soon as possible and to do further work to shorten the development cycle. For example, the marketing materials could be adapted from other courses, and the printing and distribution might be expedited. To prevent problems, the project manager might consider which activities are most likely to go wrong. An appropriate venue might not be ready, and the course might have to wait. If booking the venue became one of the first activities, more time would be available for this problem to be solved.

The main weakness of the Gantt chart is identifying critical activities – those activities that will hold up the process. The next two techniques are much better for this.

Figure 8.5 A Gantt chart for developing a short course.

Activity-on-arrow diagrams

Activity-on-arrow (AOA) diagrams are slightly more complex than Gantt charts, but are more useful for analysing projects. Activities are represented by arrows that run left to right between events, as shown in Figure 8.6. Events are points of no time duration, and are shown as circles. The completed diagram is a project network.

Figure 8.6 An activity-on-arrow project network.

In Figure 8.6, Activity A starts at Event 10 and lasts for 5 time units (days or weeks, as stated in the project plan). Once Activity A has been completed Event 20 occurs, which is followed by Activities B and C. Activity C must finish before Activity E begins, and Activity B must finish before Activity D starts. Event 50 marks the end of the project, once activities B and E have been completed.

Figure 8.6 also shows a useful way of numbering events – in groups of ten – which lets the project planner add an additional activity or event (for example, 15 or 35) without having to renumber the entire diagram.

The project planner will need to calculate the project duration once the AOA diagram has been drawn. Two additional pieces of information can be added to the diagram; the earliest event time (EET) and the latest event time (LET). The earliest event time is the earliest time that an event can occur. Conventionally, the very first event (Event 10 here) is assigned an EET of 0. The EET for the second event (Event 20) is calculated as the EET of the event where Activity A starts (Event 10) plus its duration (5 units), which makes Event 20’s EET 5 units (0 + 5 = 5). Using the same method, the EET for Activity B is 13 (5 + 8 = 13) and the EET for Activity C is 12 (5 + 7 = 12).

What happens when an event occurs after more than one activity? There could be two possible EETs for Event 50. The EET for Event 50 following Activity D is 19 (13 + 6 = 19), and following Activity E is 21 (12 + 9 = 21). Which of these is correct? Event 50 cannot happen until Activities D and E have been completed. When Activity D stops at time 19, Activity E is still going on. Therefore, the EET for Event 50 is 21. The EET will always be the maximum of its predecessors, not the minimum.

Calculating the EETs for a project from start to finish is known as a forward pass. This tells the project manager the project duration – in this case, 21. The project manager now performs a reverse pass, from project end to project beginning, to calculate the latest event times (LETs), which are the latest time that an event can occur without delaying subsequent activities and thus affecting the project duration.

The LETs would be calculated beginning with the final project event, Event 50, whose LET is the same as its EET (21). Working backwards, the LET of Event 40 is calculated as the LET of Event 50 minus Activity E's duration, or 12 (21 – 9 = 12). Similarly, the LET of Event 30 is 15 (21 – 6 = 15).

Just as in the forward pass to calculate EETs, the LET of an event where two activities start creates a choice. The LET of Event 20 based on Activity B is 7 (15 – 8 = 7), and based on Activity C is 5 (12 – 7 = 5). Using similar reasoning to that above, the latest time that Event 20 can occur without delaying the entire project is 5, the earliest LET. If the LET were 7, then a forward pass would show that the project duration would now be 23. Finally, the LET for Event 10 must be zero (if the project planner gets any other answer, there is a mistake in the calculation).

Both the EETs and the LETs can be added to the project network diagram, as shown below in Figure 8.7. The EETs and LETs are shown in the nodes that represent events. The event label is on the left side of the circle, the top right shows the EET, and the bottom right shows the LET.

What new information does this project network give to the project planner? The path that links the events where the EET and the LET are the same (EET = LET) is known as the critical path. The critical path is shown in by the double arrows – the path linking Activities A, C and E. Activities on the critical path must be completed on time for the project to end on time; any delay on the critical path will delay the entire project. For the project manager, the implications of the critical path are:

Figure 8.7 An AOA network with estimated times and critical path.

The project planner should try to shorten activities on the critical path to make the entire project shorter

The project manager should monitor critical path activities carefully to make sure that they are finished on time and do not delay the entire project.

The short course example described above is drawn as an AOA project network diagram in Figure 8.8.

Figure 8.8 AOA project network for developing a short course.

Activity-on-node diagrams

An alternative to the AOA method is Activity-on-node (AON) diagramming. The principle is similar, but here the activities are represented by boxes and the logical links between them are shown as arrows. Again, the above example of the short course can be represented by the technique. The result is shown in Figure 8.9.

Project planning software

Professional project planners often deal with large and complicated projects that would be difficult to draw by hand, and even more difficult to change and update. Many software packages are available for constructing Gantt charts and network diagrams. A selection of software packages for personal computers using the Windows operating system is shown at the end of the chapter.

Figure 8.9 Activity-on-node network for training course.

Although project planning software automates drawing and revising project diagrams, it cannot manage the project itself (contrary to some vendors’ claims!). Many senior managers prefer instead to use whiteboards for planning. Very large-scale projects such as construction projects generally rely on software.

Critical chain project planning

Despite widespread knowledge of project planning, many projects are still delivered late or not at all. Most projects are delivered late, over budget, or both. Is the fault with the methods used to deliver the original project plan (baseline), or with the project managers? Until recently project managers were assumed to be at fault, but a new development – the critical chain method – proposes an entirely new approach to project planning.

The critical chain way of thinking is based on Eli Goldratt's Theory of Constraints, which was discussed briefly in Chapter 7. Goldratt (1997) identified four major problems with current methods of project planning:

1   Activity durations are usually based on estimates rather than known times. As ‘best guesses’ of project duration, estimates can be correct, too short or too long. When people estimate how long something will take, they may offer optimistic (too short), pessimistic (too long) or correct (just right) activity times. If these estimates apply to activities on the critical path, optimistic estimates will increase project duration and pessimistic estimates may cause waste, as the project could have been finished sooner.

2 Any delay in the critical path will delay the entire project. Although the probability of any individual activity being delayed depends on that activity, the effect of delay on a series of activities (even if the probability of delay of each project is low) will result in a high probability of the entire project being delayed. Therefore, calculating project duration on the critical path is not very accurate.

3   Work is never started early. Spare time on projects is usually dissipated because people tend to start work at the last possible minute (often later than feasible for completing the work on time) rather than at the earliest possible time. Late starts inevitably result in late finishes. This is compounded by the effects of computer failures, illness or other unforeseen events that seem to occur more frequently when time is tight – although in reality it's just that their effect is much larger.

4   Even if some activities are finished early, the time saved is usually wasted. Instead of the benefits of activities that complete early being passed on, methods such as the Gantt chart still lead to subsequent activities being started when originally scheduled, rather than earlier. This means that early finishes are wasted instead of being used to offset late finishes elsewhere in the project.

These four major problems affect projects even in organizations that are otherwise excellent. Lucent Technologies and various firms from the construction sector have begun to use buffered programmes, where individual activities are stripped of any safety margins created by pessimistic estimates. These safety margins are added together to create a buffer at the end of the project. Because the buffer falls at the end of the project, the problem of never starting work until the last possible time is avoided. (The further reading suggested at the end of the chapter gives more information on project control using buffered programmes.)

With this system, activities are no longer scheduled to start on particular dates but when the previous activities have finished. This creates a relay-race effect in the project, and any time saved when activities are finished early is passed on to subsequent activities.

Project managers calculate the amount of time left in the buffer to see if the project will finish on time. This is easier than calculating the start and end of all the activities left to be completed. Some firms even display the buffer time in project work areas so that people can monitor project progress themselves. This does require self-discipline. The project manager must also indicate to the team when activities must be started, and protect them from other demands so that they can complete critical path activities as soon as possible. One project team put bright orange beach balls on the desks of employees working on critical tasks to warn off anyone who might distract them! This made critical path activities visible, and was very effective.

SUMMARY

Project management has emerged as a subject vital to modern business. Within operations, projects are the means by which a significant percentage of businesses earn revenue. They are also the means by which organizations change. Project management is different from many other operations areas in a number of respects, including the level of interaction that is required with other functions and, in many cases, with parties outside the organization.

The tools for project management are now well developed to allow the delivery of projects within the key success criteria of time, cost and quality. These start with ensuring that the strategic aspects of the work are determined and that the work programme is part of an aggregate plan. The objectives are then turned into plans by identifying activities through the WBS and creating plans for time, cost and quality.

Critical path analysis is a standard tool for project managers to determine the duration of projects and which activities will delay the project if they are late. These methods are enhanced through the application of the Theory of Constraints to provide a workable buffered plan, which is readily controllable.

Discussion questions

1   Why should the proposal document for such a project be circulated to all relevant parties, and is it important for it to be available for the project team?

2   Why might having a dedicated project team be important to the success of such an important project?

3   How might ‘process design’, as discussed in this chapter, have helped this project avoid some of the problems that they faced?

4   In such a process there are trade-off decisions to be made between the objectives of time, cost and quality. In this case, suggest which of these should have been the priority.

Key questions

1   What is a project, and how does it differ from other operations activities?

2   Why is successful project management important to both organizations and individual managers?

3   How would the principles of project management be used to ensure the success of a group project that you are involved in as part of your coursework?

4   How do the methods of capacity planning in project through the aggregate project plan compare with capacity planning in other aspects of operations?

5   What are the advantages and pitfalls of using project management software in planning and controlling your projects?

6   Choose two of the packages from the list of software below. From their websites, what are the positive features of each?

Major project planning software

Supplier	Product Name	URL and comments
Microsoft Corporation	Project	http://www.microsoft.com/office/project/default.htm and see the cases of applications at http://www.microsoft.com/office/project/CaseStudies.htm
Primavera Systems Inc.	Primavera	www.primavera.com
Asta Development Corporation	PowerProject	http://www.astadev.com/content/indexm.htm
CFM Inc.	Teamflow	www.teamflow.com – a non-traditional approach to project planning, which focuses on information flow
ProChain Solutions Inc.	Prochain	www.prochain.com – lots of good information on this site and useful discussions on critical chain project management

References

Cooper, R. G. (1988). The new product process: a decision guide for management. J. Marketing Man., 3(3), 238–55.

Drucker, P. (1955). Management. Butterworth-Heinemann.

Goldratt, E. M. (1997). The Critical Chain. North River Press.

Gray, C. F. and Larson, E. W. (2000). Project Management: The Managerial Process. McGraw Hill.

Maylor, H. (1999). Project Management, 2nd edn. Financial Times Management.

Peters, T. (1999). The Project 50. Alfred A. Knopf.

Further reading

Meredith, J. R. and Mantel, S. J. (2000). Project Management: A Managerial Approach, 4th edn. Wiley.

Project Management Institute (1996/2000). A Guide to the PMI Body of Knowledge. Download from the website www.pmi.org

Project Management Journal – published quarterly by the Project Management Institute.

International Journal of Project Management – published eight times a year by Elsevier.