GPM First
Chapter 16 of Project Management for Supplier Organizations (978-1-4724-1109-9) by Adrian Taggart

Project Control

Chapter 16

Anyone who has been involved in project management will be very familiar with the need to plan before doing the work.

The sequence is entirely appropriate since, for all the reasons offered in Chapter 14, the act of planning dramatically increases the chance of the successful implementation. Also, since the ability to influence the project diminishes over time, the project manager (PM) has more of an opportunity to influence the project during the earlier activity of planning than the later act of implementation.

However this is not to say influence cannot be exerted over the project during its implementation, it can, but it is associated primarily with control; of ensuring the project proceeds in accordance with the plan.

Control Theory

In 1943, during the Second World War, the average accuracy of bombs dropped from the air was 1,200 feet. By 1991, during the war in Iraq, for a certain category of bombs this figure had reduced to 10 feet (Correll, 2010).

The category in question is, of course, ‘Precision Guided Munitions’; bombs which are able to control their direction during their flight.

Open Loop Control (Feed Forward Control)

The bombs of the Second World War were subject to ‘Open Loop Control’ (also known as Feed Forward Control). See Figure 16.1.

 
Figure 16.1 Open Loop Control (Feed Forward Control)

graphics/fig16_1.jpg

In many respects this is a misnomer since there is no control post-launch. By this, at the commencement of the operation, an assessment of the conditions is made. A plan is conceived and enacted without further intervention.

For our bomber crews, the conditions (altitude, wind speed, aircraft speed, air pressure) were assessed. A plan conceived (‘taking aim’), whereby a heading and altitude was adopted by the aircraft, and the bomb released at a certain point. However, from hereon in no intervention was attempted (or indeed possible).

The approach has the advantage of simplicity, but the disadvantage is that it cannot respond to any subsequent change in the conditions. In some instances this disadvantage is not significant.

Imagine a commercial bakery making bread. The dough mix, the ambient conditions, the temperature of the oven, are well-known and consistent. In such an instance it can be known with some confidence that putting the bread in the oven for a planned period of time will result in a perfect loaf. Of course the planned period (equivalent to our bombers’ ‘aim’) is ‘known’ from many previous repetitions of this routine operation and, since all the other variables are controlled, the result will always be the same; a perfect loaf.

The bakery is, of course, an example of a routine operation and ‘Open Loop’ control is deemed entirely satisfactory in many such situations.

However, for many other situations, the environment is more complex.

If the environment is characterized by considerable uncertainty in relation to the variables which affect the result, and little experience of the outcome of previous attempts then, the Open Loop approach will give unpredictable results.

Closed Loop Control (Feedback Control)

The dramatic increase in the accuracy of the Iraq war was achieved because they were subject to ‘Closed Loop Control’ (also known as Feedback Control). See Figure 16.2.

 
Figure 16.2 Closed Loop Control (Feedback Control)

graphics/fig16_2.jpg

By this, again an assessment of the conditions is made and a plan conceived but, crucially, this is not the end of the matter since, during its descent, the guided weapon has a capacity to analyse its exact position; compare this with where it should be; and, if necessary, make adjustments to its moveable fins, such that its flight is brought back onto the correct path. Even more sophisticated devices allow the target point to be altered during the descent (for instance when targeting a moving vehicle).

There is, of course, a huge price to be paid for such a facility, in terms of complexity and resource consumption. Converting a ‘dumb bomb’ to a guided weapon requires the addition of many features:

  • An ability to identify where it should be at any point in the descent.

  • An ability to identify its exact position throughout the descent.

  • An ability to compare between the two, resulting in a revised instruction.

  • An ability to actually change the direction of travel.

 

However, the Closed Loop Control conveys enormous advantages. Firstly, it allows the projectile to deal with variable and unpredictable conditions in the environment (wind speed in this example) and secondly, it reduces the need to be absolutely precise over the initial planning (the ‘aiming’).

The attraction of this approach to the control of projects is enormous.

Plan-Do-Check-Act

An approach that is frequently applied to the management of projects, that includes the four required features of Closed Loop Control System, is the Plan-Do-Check-Act cycle.1[37] See Figure 16.3.

 
Figure 16.3 Plan-Do-Check-Act cycle

graphics/fig16_3.jpg

By this, firstly we ‘Plan’ our work on the basis of our best estimates. This identifies the expected performance (the first feature listed above).

We then ‘work the plan’, that is to say we actually ‘Do’ the work.

At some appropriate point in time, after we have started to ‘Do’ the work but long before we have completed it, we pause and examine what we have achieved (the second feature). We then ‘Check’ this with what we would have expected the outcome to be at this point, on the basis of our earlier plan (the third feature).

This comparison gives an insight upon which we can ‘Act’. If the outcome is as expected we may choose to continue enacting the plan. Alternatively, if the outcome is not as expected then we may choose to either alter the plan, or else how we are carrying it out (the fourth feature).

Whatever we choose, we continue around the loop. This is an iterative process and one that takes us gradually closer and closer to the eventual goal. Its attraction is its dynamism and ability to respond to imperfect initial plans, imperfect execution or indeed other external, unexpected influences such as risks becoming events. Its similarity to our guided munitions is obvious; uncertain winds may blow during the journey but the system will respond and, in any case, take us to the chosen final destination.

Variations on a Theme

As with many great ideas and models, there are always attempts to improve it which results in a myriad of similar, but different versions, and so it is the case for the Plan-Do-Check-Act cycle.

Some variations maintain the four-step cycle and simply substitute some of the words, for very similar meaning words, which some feel better express the steps involved.

Other evolutions introduce new steps and interactions. For instance, readers familiar with the Guide to the Project Management Body of Knowledge, produced by the Project Management Institute (PMI) (2013), will recognize this cycle as being the basis of the five-element process approach to their management of projects.

Alternatively, readers familiar with the ‘Six Sigma’ approach to quality management will recognize this cycle as being the basis of the Define Measure Analyse Improve Control approach to process improvement initiatives.

Application of the Cycle

It should be recognized here that the sequence can be applied to just about any task, big or small. It can be applied to the idle task of throwing pebbles at a tin (each time the aim is improved on the basis of previous throws); it can be applied to the management of a day-long meeting (‘it is now time for lunch and how many of the agenda items have been addressed?’); and it can be applied to a city’s transport strategy (‘construction of the new bridge has not relieved traffic congestion to the degree hoped for, what other bridges or infrastructure should be constructed?’).

In each of these instances the time taken to progress around the cycle is very different. For pebbles it is matter of seconds, for our transport policy it will take very many years.

In addition to time, it is appropriate to consider the cost of completing the cycle. Pebbles have a negligible cost but the construction cost of a bridge is colossal.

Clearly we cannot take the ‘pebble tossing’ approach to a transport policy by simply building dozens of bridges in the hope that eventually we will build one that is appropriate. Accordingly, the ability to control should not be used as a substitute for careful planning. As discussed earlier, there is nothing quicker and cheaper than getting it right first time.

‘Waterfall’ Versus ‘Agile’

The recent evolution of ‘Agile’ techniques provides an interesting perspective on the application of the Plan-Do-Check-Act cycle to the control of a project’s product.

The classic approach to project management (adopted within this book) is based upon lifecycle models that have linear phases. They are sometimes referred to as ‘Waterfall Models’ and a quick reference to Figures 5.3 and 7.1 will show why.

Inherent within this approach is an acknowledgement that late changes to the deliverable are ruinously expensive. This is perfectly understandable if we consider a construction project such as that for an Olympic stadium, and trying to instigate the location change discussed in Chapter 4. In response, considerable energy and resources are invested early on to ensure the requirement is fully understood and the conceived solution robust.

In recent years, however, very many projects have involved the creation of computer software and these projects have certain key characteristics that differentiate them from more traditional projects. These key differences relate to the requirement and the cost of change.

  • Computer science is evolving fast and within this environment the ability of a client to fully specify their final requirement at the outset is questionable.

  • Software is relatively cheap to produce and subsequently easy and cheap to change. For example, it does not involve the expensive concrete and logistics of construction projects.

 

In response to this scenario, ‘Agile’ techniques were evolved on the basis of the ‘Manifesto for Agile Software Development’ that was conceived by a group of software developers known as the ‘Agile Alliance’ at Snowbird, Utah, in February 2001.

These techniques relax the need for precisely understanding final requirements at the outset in favour of rapid, time limited, prototyping followed by a formal review of the prototype against the latest understanding of the requirement. By this, late changes are welcomed and not resisted.

Within ‘Agile’ techniques the focus is predominantly on the ‘Check’ and ‘Act’ elements of the cycle, whereas for the ‘Waterfall’ approach, the focus is on the ‘Plan’ element, and thus reducing the need for subsequent changes during the ‘Check’ and ‘Act’ elements.

The superiority of one approach against the other is the subject of ongoing debate but the cost of making late changes would seem to be a significant factor and as such ‘Agile’ would be restricted to projects that produce products that are quickly and easily changed. This can apply to the creation of computer software or else the phase products, such as a design, produced during the earlier phases of a traditional ‘Waterfall’ lifecycle.

Different Levels of Project Control

Project Success

When applying the concept of control to projects, we are concerned with the ongoing management of efforts such that we achieve our objectives. It is therefore a perquisite that we are able to define those objectives.

In the context of our guided munitions, this is quite straightforward since success is measured by just one parameter; the final location of the projectile relative to the target.

In the context of the project environment the situation is far more complex. Firstly, in Chapter 1 we discussed how projects have ‘complex outcomes’ and the implication of this is that the concept of ‘project success’ is not quite as straightforward as it may appear. Secondly, as we have established, not all project objectives are shared by both the Owner Organization (OO) and Supplier Organization (SO).

Project Success for the Owner Organization

To explore the concept of ‘success’ it is helpful to adopt a diagram commonly used in the world of systems engineering, known as a V-model. In essence it is a depiction of the project lifecycle. Consider taking the lifecycle model offered in Figure 5.3, putting your foot in the middle and your hands at either end and pulling it up into a V-shape (see Figure 16.4).

 
Figure 16.4 V-model of Owner Organization project lifecycle

graphics/fig16_4.jpg

The project progresses down the first leg and then up the second. At the start of a project an Owner Organization (OO) conceives of some benefit to be had. A power company, for instance, needs electricity to sell.

Moving on from there, it becomes appropriate to specify a project product whose operation will realize that benefit. Typically this would identify constraints on the cost and duration required to build the product, as well as the technical constraints. In the short term, these criteria (often known as ‘success criteria’) can be used to judge competing potential solutions. The benefit of electricity can be generated by coal-fired, nuclear, wind-powered stations, etc. and in our example an early decision must be made as to which of these ‘options’ should be adopted; a selection process referred to as ‘optioneering’.

The quantified benefit, the ‘success criteria’ and favoured option will be identified in the Business Case.

Detailed planning can now occur and baselines for the work scope, duration and cost will be included in the PMP.

The actual work of creating the deliverable can commence and, at some point, a partially completed deliverable will be available.

Later, the deliverable will be completed at which point the final cost, duration and technical capability of the deliverable will be known.

After this, the new asset can be put into operation and the benefit realized.

The V-model allows us to consider the multi-faceted nature of project success.

Was the Project Worthwhile? (Benefits Realization Review)

In the final analysis, for the Owner Organization (OO), the only important measure of success is the degree to which net benefits (benefits less cost over the Extended Project Lifecycle) were realized as compared to those anticipated in the business case. However, this can only be known at the very end and so it is of no relevance to the control of the project at hand since, at this point, there is nothing left of the project to control (it is only possible to influence future events, not those in the past). This lack of relevance to the individual project is one of the reasons why such retrospective analysis of benefits (known as a Benefits Realization Review) is rarely carried out.

The analysis is, however, of fundamental interest to the Owner Organization (OO). It has relevance to the control of a larger entity that the project may be part of, that is trying to achieve some specific benefit (such as a programme or overarching strategy), for example in answering questions such as ‘Has sufficient benefit been realized or do we need another project?’.

It has an enormous value to the OO in the sense of ‘lessons learned’ and ongoing capability improvement since the review contains the whole extended lifecycle, including project selection and justification, and so is the only truly holistic and comprehensive review of the project.

Within the OO, responsibility for benefit realization lies with the sponsor and this review primarily addresses their performance.

It is this fundamental analysis of success, and hence judgement as to whether the project was worthwhile, that is anticipated within the Decision Gates discussed in Chapter 4.

Was the Project Delivered Satisfactorily? (Post-Project Review)

Within an Owner Organization (OO), the project manager (PM) and the team are responsible only for the delivery of the product and will be disbanded at the point of handover.

For practical reasons it is necessary to assess how well the PM and team have performed prior to their departure and such assessment can only be made on the basis of information available at the time. Whereas, in most instances, assessment of the benefit can be made only after many years of operation posthandover, at the point of handover, the actual cost, time taken to create the new asset, and its technical capability are all known. These can be compared to the success criteria laid down earlier. The formal assessment of whether these criteria have been met is made at a Post-Project Review.

As discussed in Chapter 1, satisfaction of the success criteria is not the same thing as the realization of benefit. Many projects create products that are late, over budget and fail to fully meet technical requirements and yet go on to realize far more benefit than expected. The reverse also can be true.

This comparison of actual performance against the original success criteria is a vital control point for a project since it is when closure of the project is applied for (a ‘Check’ element). There is an option (an ‘Act’ element) to decline the request and instruct further work to be carried out.

Although this degree of control can be applied here, any major corrective actions so late in the project, most likely, will be extremely expensive.

Reviews at this stage also have considerable value in the sense of ‘lessons learned’, though not quite as comprehensive as a Benefits Realization Review.

Is It Likely That the Success Criteria Will be Met? (Project Evaluation Reviews)

The significant advantage of exercising early control is tempered by the significant disadvantage that final cost, time and performance data is not known. We are therefore faced with having to anticipate the likelihood of subsequently meeting the success criteria, on the basis of parameters that can be measured before the fact.

The parameters in question are known as Key Performance Indicators (KPIs) and are assessed at the periodic Project Evaluation Reviews that are typically held every week, month, or quarter during the project. It is these reviews (and the periodic progress reports they require) that comprise the most obvious control activity within the project.

Inevitably, KPIs relate to achievement of work (lines of code written, square metres of runway surfaced, etc.), incurred cost and elapsed time As well as being easy to measure, anticipated values for the KPIs must be included within the PMP. This facilitates easy comparison between the actual and planned values, upon which the likelihood of success (of meeting the success criteria) is indicated and, hence, the basis for control decisions.

The need for regular comparisons through the lifecycle imposes constraints on how the baselines are to be expressed, for instance the cost baseline must be expressed as a graph of expenditure over time rather than just a final total figure.

Chapter 17 further addresses the management and presentation of this information. But, before leaving the topic of KPIs it is worth reflecting on their less obvious implications and, in particular, their influence on behaviour. Publishing performance as measured against specific parameters, most likely, will encourage team members to improve their score, so measured.2[38] Whereas this can be taken advantage of (pay-by-results incentive schemes) they can often result in inappropriate behaviour. Factories and building sites were in the habit of putting up large signs at their entrance declaring slogans such as ‘562 accident-free days’. Whereas the intention was to promote careful and safe behaviour, it was later discovered that it simply stopped people reporting any accidents, thus stifling the very improvements sought. KPIs need to be carefully selected and managed.

Project Success for the Supplier Organization

Whereas much of the above analysis has relevance to a Supplier Organization (SO) as well as an Owner Organization (OO), their situations are different, not least because the reason why SO engage in projects is fundamentally different to that of the OO. The latter seek operational benefits, the former a profit from the supply contract. Accordingly, a different V-model is required, based upon the SO lifecycle model. Figure 16.5 applies.

 
Figure 16.5 V-model of Supplier Organization project lifecycle

graphics/fig16_5.jpg

Supplier Organizations (SO) are concerned with making money, now and into the future. This is most easily evidenced by an increase in shareholder value.

In pursuit of this they engage firstly in marketing; identifying customers and products that may result in profitable work.

The following selling activity seeks to establish attractive contracts. Chapter 12 discussed instances where the SO may identify strategic benefits associated with a contract, such as breaking into a new market, but these are rare; attractiveness is primarily based upon potential profit.

A contract will define the level of performance that the SO must meet relating to time and technical performance of the deliverable and the price to be paid,3 but not the cost of the work.

After the contract is established, the PMP will be completed and contain baselines for scope, time and cost. The targets implicit within these baselines will be a statement of the performance expected by the SO management team and inevitably will be more onerous than the limits imposed by the contract.

Subsequently the work is undertaken and partial completion achieved.

At some point the Supplier Organization (SO) will assert that the work is complete and will invite the Owner Organization (OO) to offer formal acceptance.

Chapter 18 will address in detail what work will be required after this point. It includes aspects such as the settlement of any claims and servicing of the warranty period.

As with the OO lifecycle, various control points can be identified using the V-model of the SO lifecycle. However, as discussed below, the situation is different for the SO

Was the Project Worthwhile? (Supplier Organization’s Strategic Review)

As with the Owner Organization (OO), the ultimate measure of whether the project was worthwhile is whether it achieved the net rewards that were originally identified.

If this reward is solely concerned with the profit associated with the individual contract then the difference between the total revenues and total costs must exceed that originally envisaged by the marketer. The principal difficulty here is that the total costs will include the costs of any claims for which they are liable, including warranty claims; and the total revenues will include any claims to which they are entitled. These will not be known until after the resolution of any disputes and the expiry of legal obligations of the Supplier Organization (SO).

The situation is more complex if the rewards are associated with a strategic initiative, such as the contract in question leading to further work since, again, the timescale can be significant, extending well beyond OO acceptance.

As with the equivalent point in the OO’s model, although this is the ultimate test of project success, it is too late for the control of the project at hand, but it does have relevance to the SO.

It has relevance to the control of any greater initiative of which the project is part. For instance, on the basis of their experience with a project, a SO may choose to abandon a market sector.

The main value of this review is in the sense of ‘lessons learned’. As with the equivalent review within the Owner Organization’s (OO) lifecycle, this review encompasses the whole ‘cradle to grave’ activities of the Supplier Organization (SO) that include selection as well as execution of projects. However, unlike the OO, there is no equivalent role of the sponsor who retains overall responsibility over this whole lifecycle. Within the SO, responsibility for the day to day management is passed from marketers, to sales team, to the implementation team and one can therefore expect many lively discussions about quite who was responsible for the success or otherwise of the endeavour.

As was the case for the OO, it is the result of this final comparison (of rewards less costs) that is anticipated by the SO within its Decision Gates.

Has the Contract Been Completed Satisfactorily? (Post-Contract Review)

The point of formal acceptance of the project product will involve comparing what is offered, against what the contract required. From a control perspective it is more relevant to the Owner Organization (OO) than the Supplier Organization (SO), not least since the decision is largely within the gift of the OO and not the SO.4[39] In respect of the technical performance of the product, the OO will simply withhold acceptance until a satisfactory product is offered. (Such withholding will trigger an ‘Act’ element within the SO control cycle.)

Acceptance of the product by the Owner Organization (OO) is a major milestone for the Supplier Organization (SO) primarily because it represents the expiry of much uncertainty and risk associated with the product, and hence cost and duration. However, in terms of a control point for the SO project, it is far less significant that the equivalent point within the V-model of the OO project.

The contract3[40] specifies price and not cost, and so, whereas it may provide a realistic comparator for the duration and product capability aspects of the SO performance, it does not provide a comparator for cost performance. In this respect it is not equivalent to the ‘success criteria’ of an OO project. To ‘Check’ the SO cost performance at this point, the actual cost must be compared to another measure of anticipated cost.

The cost estimate of the salesperson at the point of agreeing the contract may be of some relevance here, but in reality this will be superseded as the target performance, and hence control comparator, by the baselines of the PMP. This is so for a number of reasons.

Firstly, the estimates in the PMP are far more precise than the pre-contract estimates and so are far more realistic targets.5[41]

Secondly, the estimates in the PMP would have sufficient resolution to show the anticipated cost at this point, as opposed to just an indicated final cost. For the reasons discussed above the final cost will not be known at this point.

Thirdly there is a connection between cost and revenue. We can fully expect that during a project, the OO will instruct changes that will increase both the consideration to be paid and the cost incurred by the SO. Accordingly the cost baseline used for control purposes must reflect these. In an ideal world all such changes will be reflected immediately in a formal variation to the incoming contract but in practice, often costs are incurred before such formalisation, also, some changes will be contentious. The PMP baseline for cost is relatively easily updated and will therefore be a better instrument for advising the appropriate cost for purposes of comparison and control.6[42]

A consequence of these is that the target cost adopted as the comparator for control of the SO project, post contract, may result in a negative profit. Such a situation may occur if, during the creation of the baselines, an error is revealed in the pre-contract estimates resulting in it being an over-optimistic figure. It is appropriate for the SO to ‘take the hit’ at this point since imposing an unrealistic target upon the delivery team will be counterproductive.

Is It Likely That the Profit Will Be Secured? (Contract Evaluation Reviews)

In the same way that an Owner Organization (OO) will hold regular Project Evaluation Reviews, the Supplier Organization (SO) will hold regular Contract Evaluation Reviews. In both instances KPIs will be used to exert control over the endeavour by comparing actual performance against that anticipated within the baselines of the PMP.

For a SO that is to receive staged payments, it is also important to control the receipt of these payments, in which case a Payment Baseline is required.

Strategic Versus Tactical Control

In Chapter 4 the concepts of both strategic and tactical control were introduced. In the case of both the Owner Organization (OO) and the Supplier Organization (SO), the V-models help us differentiate between these two levels of control.

Strategic control is associated with the question ‘Are we delivering the right project?’ and is answered at the higher level of the V-model, within Decision Gates, for instance. Within the OO this level of control is associated with the role of the sponsor. As suggested above, the situation is not as clear cut for an SO since there is no equivalent role of Sponsor.7[43]

Tactical control is associated with the question ‘Are we delivering the project right?’ and is addressed at the lower of the V-model, primarily within the evaluation reviews. Within both the OO and SO this level of control is associated with the role of the project manager.

Controlled and Output Variables

The fuel efficiency of a car is not improved by restricting the fuel supply to the engine, in the same way that the cost efficiency of a project is not improved by simply restricting the supply of funds.

The variable that is used to measure the output is not the same variable that is altered to effect control.

In the context of the guided weapons discussed above, the ‘output variable’, that was used to measure the result, was the location of the projectile at the end of the flight. However the ‘controlled variable’ that was changed so as to alter the projectile’s position was the angle of the incidence of the projectile’s vanes.

Although the likely success of projects is assessed by references to parameters such as cost and time, these are not the parameters that are amenable to control.

Output Variables

In Chapter 1 we established that a key feature that characterizes projects is that they have complex outcomes.

This is particularly evident within the interplay between benefits and products that the V-models within Figure 16.4 depicts.

Even if we restrict our analysis to the product of the Owner Organization’s (OO) project, we see that it is not straightforward to measure success by reference to just one output variable since the success criteria, typically, relate to cost, time and technical performance. These are related insofar as attempts to expedite progress will, most likely, lead to an increase in costs or reduction in technical performance; attempts to increase performance result in delays and additional costs. It is for this reason it is imperative that, within the success criteria, the Sponsor indicates the relevant priority between these parameters such that appropriate control decisions are possible.

As discussed in part 3, it is vital that this prioritization of the OO migrates across the contractual boundary with the Supplier Organization (SO) such that the SO is motivated and incentivised to pursue these priorities when exercising control over the project.

As already acknowledged, there is considerable scope for conflict here since the SO’s imperative of increasing profit, by the reduction of cost and increase of revenue, is not immediately compatible with the priorities of the OO.

The OO must respond by, when drawing up the agreement with the SO, seeking to connect their imperatives with those of the SO.

The selection of appropriate reimbursement methods discussed in Chapter 10 has enormous relevance here but other ‘Carrots and sticks’ abound.

For instance, most crudely, within Firm Price contracts the payment is only contingent upon the SO providing a product that is technically compliant. Further, performance to schedule can be encouraged by the imposition of liquidated and ascertained damages.

Although these’ sticks’ have their place, it would seem that ‘carrots’ are preferable. Anecdotal evidence suggests that the offers of bonuses contingent upon some specified performance criterion are far more persuasive.

Controlled Variables

Parameters that are amenable to control within the Supplier Organization (SO) relate to their resources, predominantly people. They can decide what work is to be done, how and by whom, but in practice, their options can be very limited. For example, the scope of the work and the manner in which it is to be carried out are often are often very much restricted within the contract.

There is often more latitude for determining when work is to be done, but, as discussed in the previous chapter, if the resources are limited in number, and are obliged to carry out many tasks, the control over when the work is to be done is often limited to just deciding the sequence (priority) of work.

As discussed in Chapters 2 and 15, within a matrix environment, most likely there will be a number of projects competing for such priority and as such decisions about prioritisation become very complex and contentious.

In these circumstances a PM’s authority to control events can be very modest and many of them, especially those in Supplier Organizations (SO) located towards the left of the continuum in Figure 2.4, will expend most of their energies just seeking to persuade or cajole others, especially Functional Managers, to reprioritise work within their departments.

Notes

[1] Usually, the product is the unique element of a project but this is not always the case. For instance a project may be initiated to create a standard product but to do so using a different manufacturing technique, or by using alternative equipment, or in a different location. In each of these cases the challenge is to do something which has not been attempted before and as such the word ‘unique’ is applicable and hence the use of the word ‘project’ justified.

[2] The troubled facility created for the 1976 Olympic Games in Montreal, the chaotic preparation of the stadia for the FIFA World Cup in Brazil in 2014 and the reconstruction of Wembley Stadium in 2007 are notable examples in this respect.

[3] Many readers will be employed by organizations that deliver successive projects and the completion of one project does not lead to termination of employment. These types of organizations are referred to as ‘matrix’ organizations and have special characteristics, some of which they share with organizations engaged in non-project work. They will be addressed in some detail in Chapter 2 but for the purposes of this chapter it is appropriate to consider what may be referred to as a ‘pure project’, like our stadium project, a characteristic of which is its temporary management structures.

[4] In practice, the involvement of individual project team members is even more volatile than the life of the overall project team. Most likely, an individual will be a member of a sub-team which will only exist until the fragment of the project for which the sub-team is responsible, is complete. For this reason the make-up of the overall project team is always changing.

[5] This may stretch the historical knowledge of some of our younger readers but suffice to say that after vinyl records, the favoured medium for storing music was a spool of magnetic tape contained within a plastic case; the cassette tape.

[6] The various levels of project success and the interplay between products and benefits is addressed in detail in Chapter 16.

[7] There are instances where organizations may choose to move in the opposite direction, and for good reason, but this book does seek to address their concerns.

[8] Ultimately, all expenditure is for the engagement of people since all material comes out of the ground (either mined or harvested) and at this point is free of charge.

[9] For the mathematically minded it is the integral of the earlier curve (area under the curve) and its gradient, or steepness is equal to the value of the previous curve, at any individual point in time.

[10] The name derives from ‘S’ being an abbreviation for ‘Summation’, since these curves are most properly referred to as ‘Summation Curves’. This explains why, very often, real ‘S-curves’ do not look much like an ‘S’. The important features are, firstly, that it is always ascending (the cumulative expenditure never reduces) and, secondly, the gradient, on a large scale, is shallow-steep-shallow, even though locally, on a finer scale, there may be some variation in gradient.

[11] The decision made at the gates involves the marginal benefit and marginal cost. Actual expenditure to date is ignored on the basis that it is a ‘sunk cost’ and cannot be recovered in any case. This is a reason why, especially at the later Decision Gates, a project may be continued with, even though the total benefits may be exceeded by the total costs.

[12] Further detailed analysis and comparison of strategic and tactical control is offered in Chapter 16.

[13] There is again an analogy to our own lives. Shakespeare once famously wrote about the ‘Seven Ages of Man’ and yet Hinduism talks about the four stages of man. Each is describing the same life; the same journey from cradle to grave, and yet they choose to decompose it in different ways, each to reflect their own understanding and their own emphasis.

[14] Readers may wish to note that in some countries, most notably the United States, the mandate document that bears the authorizing signatures is a ‘Project Charter’. This is a standalone and separate document that will refer to a Business Case.

[15] Some care is required here because there are some obligations of the SO that may not be explicitly stated in the contract. For instance, in any case, the SO is obliged to provide goods of ‘merchantable quality’ and this will confer ‘implied terms’ on the SO.

[16] The analysis is more straightforward if we assume the contract is of ‘Firm Price’ type (see Chapter 13).

[17] Some OO manage major assets and infrastructure (rail, water and telecommunication networks) and are constantly commissioning projects to create or refurbish assets. For them, projects are an ongoing feature, but they are the exception. For most OO their involvement in projects is sporadic.

[18] Like the lifecycle offered in Chapter 5, the lifecycle offered here is a model. To be useful, models need to be simple, however their principal weakness is always their simplicity. The nature of procurement is such that there are a great many combinations and permutations of payment terms, contract types, and the like that can result in variation in the exact Decision Gates and phases that apply. The model is offered as a generic model to assist in the understanding of what appertains to most SO, most of the time. Real examples may, and will, vary.

[19] Some legal obligations of the SO do live on beyond this point, for instance its obligations for latent defects.

[20] It should be noted, however, that this is not always the case. Acme Pool Services is selected on the basis that, unlike the Owner Organization (OO), it is experienced in the construction of pools. It has skills, equipment, knowledge, expertise and contacts that enable it to manage the building of the pool far better than the OO, such that it may well be able to do the work for a considerably cheaper sum and some of this saving may be passed onto the OO in which case the second scenario is both easier and cheaper for the OO.

[21] There are variants that do not contain such an agreement but are less attractive to the OO.

[22] The exact sharing of risk is determined by the wording and quantifications within each specific contract. The arrangement within a continuum offers an approximate guide only.

[23] Ideally such negotiations should be embraced as early as possible and not wait for the final phase but practicalities often result in them being held to the end.

[24] For example some EU legislation imposes constraints on publicly funded projects.

[25] Discrete probability distributions for time or cost of a project are rarely symmetrical. It is almost always the case that it is more likely to cost more, or last longer, than the ‘most likely’ figure, than less, i.e. the mean is very likely to be greater than the mode. This results in a distorted distribution curve with a longer tail to the right of the mode. It is for this reason that the single estimate derived by the three-point estimating technique is usually greater than the mean and a more representative figure of the overall distribution.

[26] Or other entity such as Work Package.

[27] The use of Product Breakdown Structures and Work Breakdown Structures (WBS) will be addressed comprehensively in Chapter 14.

[28] There is an opportunity to withdraw an offer by the offerer, before the expiry of any validity period, but it is limited and different legal systems have different approaches. It is, for instance, an area of inconsistency between English and Scottish law.

[29] For an OO the ‘why’ is addressed within the Business Case and the ‘Project Background’ section of their PMP is informed by this.

[30] This ‘locking’ of the estimate is sometimes referred to as ‘baselining’.

[31] It is the case for project control as it is for planning. ‘Scope creep’ (doing something that was not intended) impacts upon duration and cost and, without a scope baseline, ‘scope creep’ cannot be recognized and hence project cost and duration cannot be controlled.

[32] For projects with very large physical deliverables, such as machinery, many practitioners choose to draw up a PBS (Product Breakdown Structure) that decomposes the deliverable into discrete parts, as a prelude to creating the WBS.

[33] A Work Breakdown Structure Dictionary is a textual document that supports the WBS by containing additional information about individual Work Packages.

[34] ‘Cost’ is a complex entity and care is required here. Chapter 17 refers.

[35] Such ‘house standards’ will be key elements of the project management method adopted by the SO.

[36] Although presented in the context of management of resource, since time and cost are inextricably linked, they can be thought of as time or cost management techniques, depending upon the context.

[37] To many, this four-part cycle is known as the ‘Deming Cycle’ or the ‘Deming Wheel’ on the understanding that it was originated by W. Edwards Deming. However, in his book Out of the Crisis, Deming (1982) himself attributed the original design to W.A. Shewhart.

Others, such as Ronald D. Moen and Clifford L. Norman (2010) differentiate between ‘Deming’s Wheel’ and the PDCA cycle, attributing the latter to a reworking of Deming’s work by a group of Japanese executives after receiving a presentation by Deming in the 1950s.

[38] This can be considered as an example of the ‘Hawthorne Effect’ (Buchanan and Huczynski, 2004).

[39] As discussed in Chapter 7, through the life of a contract the SO has progressively less influence over the gate decisions than the OO. For example, once the contract is signed the opportunity for the SO to terminate the contract is negligible.

[40] For convenience we will consider a Firm Price contract.

[41] If the estimated cost within the baselines of the PMP is less than that within the pre-contract sales estimate it is inconceivable that SO management would not insist on the former being adopted as the target cost.

[42] Although it is easy to refer to just cost, the real goal of the SO is profit and so there is a pressing need to manage and control revenue, both in terms of expediting payments to which the SO is already entitled, and also maximising the amount of entitlement. The latter will involve the SO’s PM acting as a marketer and salesperson seeking out new opportunities within the context of the existing OO and project. Such activity is akin to the ‘farmer’ aspect of selling as opposed to the more conventional ‘hunter’ aspect, as addressed in Chapter 13.

[43] To some extent this is because this strategic level of control is not as easy to exert within an SO because, once a contract is signed, the SO has no option to withdraw.

[44] It is said that project managers spend upwards of 90 per cent of their time simply communicating with others (Heldman, 2009).

[45] Care is required here since some projects will have their own contractual requirements that may not be adequately serviced by the existing facility.

[46] This also helps to manage the risks associated with the unexpected departure of key project staff.

[47] Some practitioners also include the processes and documents required to manage change as being part of the Configuration Management System (CMS).

[48] For instance, to avoid potential for any contradictions such suites should, ideally, ensure that a requirement (such as a dimension) is only stated once, in one document, which is then referenced by the others.

[49] Or alternatively with a CMS imposed by a SO higher in the supply chain.

[50] Some recipients will receive a ‘Controlled Copy’ in which case they will automatically receive any subsequent updated versions. Recipients of ‘Uncontrolled Copies’ do not atomically receive updated versions.

[51] Further enhancement can be adopted when using a spreadsheet’s logic to colour the cells to indicate status (for instance: Green - Work Package has started/finished before its planned date Amber - Work Package has started/finished but after the planned date; Red - Work Package has not started/finished and it is after the planned date).

[52] The size (and hence number) of the smallest fragment into which the project is decomposed.

[53] Implicit within all these discussions of costs incurred by a SO, and their use in the strategic and tactical control of projects, is the assumption that costs can be attributed to each individual bespoke product. Those SO who currently only produce standard products and are looking to embrace the supply of bespoke products may find this requirement surprisingly onerous. This is because, currently, many will operate a cost collection system that uses only functional departments as cost centres and lack the facility to record costs against individual products. Converting such a system can represent a significant amount of work and may, for instance, include the need for employees to create timesheets. Cultural resistance can be expected as well as significant technical difficulties and additional complexity.

[54] Many SO choose to have a ‘Cost Management Plan’, as a subsidiary management plan within the PMP that contains such definitions and conventions.

[55] The precise point of commencement of the warranty period is defined within the contract in question.

[56] In some instances such access is an element within the original supply contract. It can be a useful negotiating token for the OO.

References

20 

The Agile Alliance, 2001. Manifesto for Agile Software Development. [online] Available at: http://agilemanifesto.org [accessed 17June2014].

21 

Buchanan, D. and Huczynski, A., 2004. Organizational Behaviour: An Introductory Text, 5th edn. Harlow: Prentice Hall.

22 

Correll, J.T., 2010. The Emergence of Smart Bombs. Air Force Magazine: Online Journal of the Air Force Association. [online] Available at: http://www.airforce mag.com/MagazineArchive/Pages/2010/March%202010/0310bombs.aspx [accessed 16April2014].

23 

Deming, W. Edwards, 1982. Out of the Crisis. Massachusetts: Massachusetts Institute of Technology.

24 

Moen, Ronald D. and Norman, Clifford L., 2010. Circling Back, Clearing Up The Myths about the Deming Cycle and Seeing How It Keeps Evolving. [online] Available at: http://apiweb.org/circling-back.pdf [accessed 16June2014].

25 

Project Management Institute, 2013. A Guide to the Project Management Body of Knowledge (PMBOK® Guide), 5th edn. Pennsylvania: Project Management Institute Inc.

Submit your own content for publication

Submit content