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

Management of information

Chapter 17

A very common complaint amongst those involved in the management of projects relates to (what, before emails arrived, was referred to as) ‘paperwork’.

Complaints usually relate to either the sheer magnitude of reports, forms, correspondence and other formal documents that need to be processed, or alternatively, the insufficiency of the various systems that exist within their organizations to manage them.

The reality is that projects generate and devour enormous amounts of information and data and most practitioners spend a significant portion of their time simply servicing the administrative demands of their project; completing, filing and subsequently retrieving (or looking for) key information.1[44] Whilst we all dream of some clever IT solution that will free us from this burden, it seems unlikely that this will ever happen.

In some ways, the adoption of IT over paper-based systems has acted to disguise some issues.

The author has happy memories of, as a young man, starting a new project with an empty cupboard then filling it with 20 or so lever arch files, having written on each ‘Correspondence file # x’, ‘Documents file # y’, etc. This was the project information system. It was there in preparation for the coming deluge of paperwork and its existence, and the care with which it was maintained, was very obvious to all.

Without physical paper, computer-based systems are less obvious. It saves office space but can disguise some very poorly maintained and untidy collections of documents.

But, regardless of the format, the information management system is vitally important to appropriate management of the project.

Why So Much Information?

All commercial organizations are obliged to undertake some information management. Payroll, purchase ledger, health and safety records, training certificates and the like apply to all, but, in moving from the non-project environment to the project, the Supplier Organization (SO) will face a stepchange increase in the amount and range of information that they must manage. Consider the following:

  • As discussed in Chapter 6, SO offer an expertise and capability within a specialist, and often rare, niche. In this respect their intellectual property (and very often their single most valuable asset) is their archive of drawings, calculations, cost data, risk registers. These detail their experience of previous, similar projects, and hence their eligibility for future work.

  • Since each product is bespoke, standard technical documents become inappropriate. Each deliverable requires its own defining documents. This specialist need is addressed by the topic of Configuration Management.

  • Bespoke products usually have unique commercial arrangements. Individual contracts must be established with each client and the inevitable prelude to this is extensive correspondence.

  • Controlling the creation of bespoke products incurs a huge demand for documentation such as the bespoke plans and subsequent reports discussed in Chapter 14.

  • Often, the project deliverables are documents. An architect, for instance, just produces drawings, calculations and specifications. Even if the principal output is a physical deliverable, like machinery, the SO will be obliged to produce documents such as operating and maintenance manuals and quality control records.

  • Supply control. As discussed in Chapter 8, SO often sit within a procurement chain and as such the complexity of supplying bespoke products up the chain is mirrored by the complexity of managing suppliers of bespoke products, lower in the chain.

  • The control of the SO portfolio by interfacing between different projects, for instance in relation to resource management, makes further information demands. An important aspect of this relates to the need for continuous improvement and documenting lessons learned.

 

The expense, in terms of man-hours, associated with servicing this system can be considerable and is often overlooked when estimating the cost of the project.

Planning the Information Management System

As with all aspects of project management, the earlier in the lifecycle an activity occurs, the more influence can be exerted. We have discussed this by reference to the importance of planning and this applies to the management of information.

In Figure 4.2 we explored how the number of people involved in a project increased rapidly during the mid-part of a project. We may expect the amount of the information generated and required to be consistent with the number of possible communication links between the team members. Within a team of n people, this is given by the formal 0.5(n2-n); it increases with the square of the number of people and represents a far steeper and dramatic curve. Also, the most important documents (business cases, contracts, plans) are created at the start of a project. The combination of these two factors point to the importance of considering very early in the project, how information will be managed.

Many inexperienced practitioners start projects without plans for managing information, expecting to evolve systems as they proceed. Unfortunately, the rate of increase indicated above can seem like a tsunami when it arrives, quickly overwhelming any rudimentary systems. Practitioners are therefore faced with having to design and implement a system at the very time the need for it (to control the burgeoning project) becomes critical.

The more experienced avoid this. Many Supplier Organizations (SO) do so by establishing an enterprise-wide facility, and having procedures for the management of information as part of the project management ‘method’ they choose to adopt.2[45] Such an approach has very many advantages.

Firstly, it provides economies of scale, for instance by relieving each PM of having to invest the time and energy to ‘reinvent the wheel’ for every incoming project.

Secondly, a consistent approach ensures the other members of the project team will be familiar with the approach and already know where to find or store information. This has particular benefits to the management of portfolios such that personnel being switched between roles and projects can quickly access the necessary information.3[46]

Thirdly, it becomes easier to implement ‘lessons learned’ from previous projects especially within the disproportionately important early documents, such as contracts.

Increasingly, the design of project information systems is being taken over by proprietary software. A simple search of the Internet will reveal a myriad of products that purport to address the entire requirement for information management within a project environment, from scheduling to document control. The selection of the most appropriate will lie with each individual SO and no attempt is made here to discuss the various merits of individual products. Instead, we shall focus on understanding the detail of the requirements and how it supports effective project management.

Types of Information to be Managed

Configuration Management

‘Configuration Management’ is an expression that readers will have come across but few will be comfortable with defining.

Configuration Management is best viewed as being all that is said and done to control the physical and performance characteristics of the project deliverable throughout the extended lifecycle; from the point of conception, through specification, design, construction, operation and disposal. The most familiar manifestation of the Configuration Management is likely to be a document control system.

In simple terms, for us to ultimately get what we want from a project, at the outset we need to be able to describe what it is that we want. In relation to the project deliverable, this requires that, prior to its creation, we must be able to describe what it is (will be) in a document such as a drawing or specification. Such a document is the core of Configuration Management, but the need for some enhancements become obvious.

Firstly, as the project evolves and more is known about the product, the document in question that describes it will change from a need statement, to a specification, to a drawing, to an ‘as-built’ record of the asset. Consequently, we see the need for a suite of connected documents with one directly influencing and shaping another; a specification influencing a drawing, for instance. Easy and accurate referencing between these documents is vital so, inevitably, a system of numbering is evolved such that each document has a unique reference number.

Secondly, as established in Chapter 11, changes are an unwelcome but inevitable aspect of projects and there is a need for this to be reflected in documents. Chaos is guaranteed if different team members are working to different editions of the same drawing. This is avoided by each having a ‘version number’ (sometimes known as a revision or issue number) and the authorization and release of revised versions being carefully managed. (In turn, version numbers provide the facility to actually instruct change.)

These two aspects are the basis of the document control system which makes up the majority of the Configuration Management System (CMS).4[47]

Straightforward though these principles may be, it would be a mistake to assume that the practice of configuration management is straightforward, especially if the project is large, the product complex or the team members geographically dispersed.

Consider making something as complex as an aeroplane consisting of many thousands of sub-assemblies that must fit and perform together, and each made by different parties spread across the globe and arranged into a complex procurement chain. Simply designing a suite of documents that describe the product and each sub-assembly is an enormous challenge.5[48]

In such projects the number of documents becomes colossal. This in turn requires additional roles dedicated to administering to the CMS such as Configuration Control Boards, Configuration Item Owners and Configuration Librarians.

We can also see the need for an Owner Organization (OO) to impose one CMS consistently across its whole project. This has implications for the Supplier Organization (SO) since its system must align and interface with that of the OO.6[49] The practicalities of this are often perverse and may, for instance, involve a document or drawing having more than one reference number (one for the CMS of the OO, another for that of the SO).

Inevitably, the CMS will overlap with many other aspects of the SO project. For instance the contract must identify the deliverable either directly (in which case the contract becomes the principal specifying document) or else by reference to another document (in which case the unique reference and version of the document will be needed). If the version of these documents changes then this needs to be accommodated within variations to the contract.

Each SO engaged in project work will need a CMS that, at minimum, includes the following:

  • The ‘Configuration’ – A list of those documents (including drawings) that collectively define the deliverable and its method of creation, each with a unique sequential reference number and document owner.

  • Issue status – A record of the current version of each document including the date of approval (by owner and any other appropriate bodies), the date of issue, and the recipients.7[50]

  • Appropriate document formats – The documents will conform to a standard format, or else have a cover sheet appended that allows the pertinent data, including that above, to be displayed.

  • Change control information – An audit trail is required indicating how each document has evolved in response to changes.

 

Commercial Information

Incoming Contract

As an absolute minimum, the information management system of the Supplier Organization (SO) must contain a copy of the agreed incoming contract, including all approved variations.

As often stated, this is the ultimate reference document that determines what the SO is to do and its rights to receive payment. It must be available to all relevant SO personnel and control their behaviour accordingly.

Client Correspondence

A similar level of care is required with correspondence. In the event of a dispute between the Owner Organization (OO) and Supplier Organization (SO) as to the obligations of either party, it can become necessary to look for additional information that clarifies a position. In these instances the communication between the SO and OO is vital. Letters, emails, minutes of meeting and notes of telephone calls must be religiously recorded.

Good housekeeping and administration are vital here and many readers will have experienced some harsh instruction earlier in their careers in the appropriate etiquette.

Clear, well written and suitably recorded correspondence will not only dramatically reduce the likelihood of a dispute, but will increase the chance of resolution in your favour since with contractual disputes it is the party with the best records that usually prevails.

Some of this correspondence will have such importance that its format will be defined within the contract, for example, Acceptance Certificates.

Outgoing Contracts and Supplier Correspondence

Most likely, the Supplier Organization (SO) will engage further SO as subcontractors and the requirements discussed above for recording contracts, correspondence and approval certificates are replicated, with the SO taking the client role.

Other Commercial Obligations

The nature of an individual project may impose special considerations on a Supplier Organization (SO) in relation to management of information.

For instance, if the incoming contract is on a ‘Cost Plus’ basis, then evidence of incurred costs must be made available to the Owner Organization (OO) on an ‘open book’ basis. Alternatively, if the incoming contract requires material to be sourced from, say, a sustainable source, evidence of the supply chain must be presented.

Information as Deliverables

Because it is easier to visualize, this text has tended towards discussing project deliverables as being physical items such as machinery, but in very many instances the deliverable is simply a service which does not have such a tangible output.

For instance if an Owner Organization (OO) were to engage a structural engineer as a Supplier Organization (SO), to assess whether an existing building was capable of withstanding an extension, the deliverable is simply a justified opinion.

Further, even when there is a physical deliverable, it is often incumbent upon the SO to submit supporting information. For instance, SO engaged in ‘design and build’ type projects are well used to formally submitting drawings of their proposal which will be subject to the OO approval before construction can commence.

When the output of the SO work (or part thereof) is information, inevitably, the principal contractual deliverable is some form of document (physical or as a computer file) and it is appropriate to determine the format and outline content of this well in advance of the handover (preferably pre-contract). In this respect the importance of information management is further reinforced since now it is not just an adjunct to the main creative process of the project – it is the main creative process.

Examples of types of documents that can constitute deliverables can include the following:

  • Specifications.

  • Technical reports.

  • Drawings.

  • Despatch and delivery documentation, e.g. Bills of Lading.

  • Quality control records.

  • Conformance certificates.

  • Warranty certificates.

  • Operating and maintenance manuals.

  • Software documentation.

 

Project Control

Chapter 16 discussed the mechanisms of project control at both a strategic and tactical level.

As discussed below, the process is heavily reliant on the presentation of appropriate information.

Strategic Management

Strategic control is associated with the question ‘Are we delivering the right project?’ and is formally exercised at the gate decisions along the project lifecycle (Figure 5.3 and 7.1).

Quite simply, the quality of the decisions made at these points will determine the success of the Supplier Organization (SO) and whilst there is inevitably a judgmental element to these key decisions that is based on subjectivity, it is better if the objective element, based upon quantitative data, is to the fore. This requires the preparation of reports and supporting documentation prior to the decisions.

For instance the ‘Bid/No Bid’ decision is contingent upon factors such as the likely cost of bidding, likely cost of the work, the likely price, the likelihood of winning a competitive bid, the existing and anticipated workload, the commercial strategy of the organization. To facilitate objective decisions, the information system must be capable of providing hard information on each of these.

Further, it is appropriate that these decisions are overt, ideally made within formal meetings and that the decisions are recorded (including signatures). There is anecdotal evidence that the act of recording why decisions are made is a major success factor for those involved in managing projects.

Tactical Management

Tactical control is associated with the question ‘Are we delivering the project right?’ and is formally exercised at the Contract Evaluation Reviews discussed in Chapter 16.

Within this, a comparison is required between what was expected to occur and what has actually happened. The latter requirement is met by measured performance whereas the former is met by the baselines within the PMP. The prime requirement of information management in this respect is demonstrating the comparison between the two.

As discussed in Chapter 14 the three principal baselines relate to scope, time and money. These three parameters are inseparably entwined and in an ideal world it would be possible to demonstrate project progress as a single holistic process. Although attempts have been made to devise such a method, i.e. Earned Value Management, the reality is that most reporting considers just one baseline at a time. Each has its own particular challenges.

Scope As with planning, scope is the most significant of the baselines in the context of project control and, ultimately, project progress is measured by how much of the scope has been completed. Unsurprisingly, the ‘per cent complete’ parameter becomes the core of any progress report.

However, work can only be known to be complete when it has actually been completed and so to have a ‘per cent complete’ figure for a project of anything but 0 per cent or 100 per cent requires dividing the scope into fragments. Obviously the WBS and the division of the work scope into Work Packages is of key relevance here.

Simply counting the number of completed Work Packages gives a good indication of progress, though this can be enhanced by weighting the Work Packages with their value.

Consequently a very useful control report can be created by a table with a row for each Work Package and columns containing ‘Planned’ and ‘Actual’ dates for when the work package was/will be ‘opened’ (a ‘Go’ ticket issued by the PM to the Work Package Owner) and ‘closed’ (output accepted by the PM).8[51]

Time Progress in terms of the amount of work done (effort) and progress in terms of time are different.

Imagine a DIY project to install an external lamp (digging cable trenches, erecting mounting post, etc.). Almost all the work may be completed over a weekend before realizing that the bulb element was broken and then having to wait 10 days for the replacement. In terms of effort, 99.9 per cent of the work is complete (only five minutes’ work remains to unpack and screw-in the new bulb) and yet in terms of time only two of the now anticipated 12-day schedule have passed.

Accordingly, when it comes to tracking progress against time, in addition to the simple calculation of ‘per cent complete’ described above, other methods are required that recognize the durations, logical dependencies and interactions of the various project activities. We are again reliant upon precedence diagrams, and the like.

As with the planning activity described in Chapter 14, the use of computers and scheduling software is ubiquitous here and they provide a very valuable opportunity for producing semi-automatic progress reports that compare the actual with the planned schedule. However, there are drawbacks to their use.

The first problem relates to just how much effort is required to service the software. Many project teams are tempted to create very detailed models of their project schedule with a very high degree of ‘granularity’.9[52] However, the degree of granularity determines the amount of actual completion data to be measured and analysed, leading many to conclude later that they have ‘created a monster’ that makes increasing demands on their time and resources to reflect every evolution and twist in the project.

The second relates to just what level of detail can be interpreted by stakeholders. Many is the project team that, at the end of each reporting period, takes the trouble to create very impressive and elaborate Gantt charts, running to numerous pages, with bars for both planned and actual progress, and which are entirely beyond the understanding of most of the report recipients.

There are actually very many formats, other than the Gantt chart, that can communicate progress against plan in a very simple and effective way and too many project teams show surprising lack of creativity in adopting them. Consider the following.

Figure 17.1 shows how a Gantt chart can be updated with actual progress reports, not by plotting additional bars but by staggering the ‘time now line’ in relation to the original bars. This is often referred to as a ‘Progress Line’.

 
Figure 17.1 Reporting project progress with a ‘Progress Line’

graphics/fig17_1.jpg

New Progress Lines for each successive reporting period can be added to the same diagram and progress relative to the original plan, and to the previous report, is effectively communicated. The author has very positive experience of such an approach for reporting progress.

An alternative technique is the ‘Milestone Slippage Chart’ (see Figure 17.2). Within this technique, the project is represented by milestones, ideally located on the project’s critical path. Each remaining milestone is plotted as a graph with co-ordinates of Actual Time (the current project period) and the Planned Time (the period in which the milestone is expected to be achieved). A trace stepping to the left indicates a milestone being brought forward, a step to the right indicates delay.

 
Figure 17.2 Reporting project progress with a ‘Milestone Slippage Chart’

graphics/fig17_2.jpg

Milestones having a vertical trace that terminates at the diagonal line reveals a project team that both achieves its milestones and can anticipate this. Traces that are vertical until they meet the diagonal line and then slide down the diagonal reveal teams that cannot achieve milestones but cannot anticipate this (everything is on schedule up to the point when completion should be achieved, at which point they are delayed by a period each period). A slightly better scenario has the traces drifting parallel to the diagonal from early on; milestones are not being achieved but at least the team is able to anticipate this sometime in advance.

This striking and easy-to-interpret visual impact offers many advantages, especially when having to quickly understand the situation with a large number of different projects, for instance when reviewing a portfolio.

For projects where time is of the essence, an effective reporting technique involves a clock face and project phases as concentric rings (see Figure 17.3).

Within this the project period is fixed and the spiral trace of actual performance must stay inboard of the spiral indicating planned performance.

 
Figure 17.3 Reporting project progress with a ‘Clock-Face Chart’

graphics/fig17_3.jpg

It is particularly effective for motivating a team towards a fixed completion date.

Cost This is a measure of the consumption of resources and allows comparison to that which was expected.10[53] It is a process fraught with complexity not least because there are very many different types of resources, for instance different types of internal human resources, and to avoid the need to consider them all separately there is a tendency (not always helpful) of converting them all to a common unit; money. Even ignoring exchange and inflation rates, expenditure is often a very unreliable indicator of project performance. Consider the following.

Firstly, expressing internal labour costs as money requires the evolution of a ‘charge rate’. This is reached by the Supplier Organization (SO) after considering the overheads (fixed and variable) that must be overcome. Recovery of fixed overheads is necessarily based upon an estimated quantity of work to be completed in the period and if this proves to be grossly inaccurate, an ‘under’ or ‘over recovery’ of fixed overheads can give an unrealistic representation of the performance of the SO.

Secondly, when does a cost become an ‘actual cost’? For externally purchased goods is it when the money is transferred from one party’s bank to the other? Is it when the invoice is received? Is it when the contract is signed? There are often very many months delay between these dates and simply considering the former will inevitably give a gross underestimate of the true exposure. This lag is accommodated primarily by ‘accruals’; the difference between the payment/ receipt of money and the legal obligation or right to pay/receive it. If we are using ‘actual’ cost as measure of performance then the timing is crucial, and at minimum there must be consistency throughout the organization as to what is exactly meant by ‘actual costs’, ‘committed costs, ‘accruals’ and when they are recognized.11[54]

 
Figure 17.4 Planned versus actual expenditure

graphics/fig17_4.jpg

Thirdly, even if the above can be overcome, there is huge ambiguity as to what expenditure represents. Consider the graph in Figure 17.4. Is this good or bad news?

It could be that the project has just been completed, x months ahead of schedule and y under budget. Alternatively it could be that the project has achieved next to nothing and is now woefully over budget and behind schedule. Without a further parameter, a measure of how much of the total project scope has been achieved, the simple comparison of planned and actual expenditure is largely meaningless. This is the logic that underpins the ‘Earned Value Management’ technique and the parameter of Earned Value; a measure of what has actually been achieved (based upon ‘per cent complete’).

These complexities need to be managed before reports can be effective in supporting project control.

Reporting Frequency and Cost

The timing of the Decision Gates is determined by the lifecycle, but the frequency of the Contract Evaluation Reviews, and how often the PM is obliged to compile a progress report, is a matter to be decided and the outcome has a significant impact on costs.

If, for instance, a PM is obliged to compile, submit and discuss a report every month (20 working days) and it takes two days’ effort to compile this, we can see, immediately, that they will be spending 10 per cent of their total time just reporting on progress. (In practice many reports take much longer and often the frequency is higher.)

It explains why the activity (along with other project management tasks such as planning and procurement) should be within the WBS to ensure that they are recognized in subsequent schedules and budgets.

Enterprise-Wide Information Management

As we have discussed, the Supplier Organization (SO) is an enterprise that is far more than any individual project and much information management is driven by concerns beyond its immediate needs. A distinction can be made between managing the current portfolio, and future activity.

Portfolio-wide Information

Supplier Organizations (SO) most often manage a number of projects simultaneously and the management of this portfolio requires information.

The most significant aspect is the management of common resource pools discussed in Chapter 15. The type of information required in this respect will be identical to that for managing the individual projects but there is a need to ensure all projects output the information in the same format so as to facilitate aggregation.

A further portfolio requirement relates to risk. In addition to understanding the total risk exposure of the portfolio, some risks are better managed at a portfolio, rather than a project, level. For instance, a specialist machine that reduces a technical risk may be too expensive for any individual project, but it may benefit many projects. In such instances it is appropriate for the portfolio to purchase the machine. The information system is required to identify and justify such opportunities.

Future Supplier Organization Commercial Activity

Supplier Organizations (SO) are permanent organizations and look to win future contracts. This gives rise to a need for the following information:

  • Selling and marketing collateral – When marketing and selling, the SO needs to demonstrate competence by reference to previous, similar work. A formal Reference List complete with calculations, designs, trials and test reports, fault investigations, etc. can be of enormous worth, in offering such reassurance. Similarly, for bespoke equipment, it can be a relatively rare event to have access to a complete or partially complete product at some notable stage of its creation and PM are often asked by the selling and marketing personnel to factor into their project schedules time for extensive photography, and sometimes even for visits by prospective new clients.

  • Planning and estimating – The need for SO to quickly and cheaply estimate costs and duration for future work was established in Chapter 13. This is achieved primarily by a carefully compiled archive of historic data from previous projects.

  • Continuous improvement – SO must always strive to improve their performance on successive projects. Documentation of techniques, risk mitigation, vendor assessment reports, innovative technical solutions and the like all contribute to continuous improvement. Similarly, assessments of internal resources allows for training and organization improvements.

  • Client records – As discussed in Chapter 18, the commercial opportunities for the SO do not end with the supply of the project deliverable. Supply of spares and servicing can provide a lucrative revenue stream. Accordingly, complete technical information for the product in the ‘as-built’ condition as well as names and contact details of the relevant personnel of the Owner Organization (OO) are needed.

 

Openness and Honesty

When considering the management of information there is a tendency to focus only on the hard aspects such as the apparatus and systems used and the reporting format and frequency adopted.

Ultimately, information management facilitates communication and the ability to communicate is essentially a soft skill.

Indeed the role of PM is first and foremost about communication and their inherent skills in this regard will largely determine their competence. Proficiency in presenting, listening, negotiating, writing, debating, arguing are all examples of such essential skills.

The soft element is also important at the organizational level. If an organization fails to evolve a culture that ensures openness and honesty then no formal information management system will save it from an eventual demise.

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.

Reference

26 

Heldman, K., 2009. PMP® Project Management Professional Exam Study Guide, 5th edn. Indianapolis: Sybex.

Submit your own content for publication

Submit content