Programmemanagement - CIPS v2.pdf · 2010-11-23 · Programmemanagement Projectlifecycles Netcash-flowandbenefitrealisation NOV07 Tel +44(0)1780756777Fax +44(0)1780751610Email [email protected]

Programmemanagement

Introductory definitions 2Project life cycles 3Net cash-flows and benefit realisation 3The relationship between the procurement function and cash-flow management 6Managing the project portfolio 10Organising industrial and commercial projects 18Organising internal projects and mixed project programmes 19The programme support office (PSO) 19Project procurement and supply chain organisation 20Partnerships between purchasing agents and technical staff 21Scheduling resources part 1: introduction 24Scheduling resources part 2: summary of the data input process 26Scheduling resources part 3: practical application to multiple projects 27Buying and installing suitable software 30Controlling and correcting work in progress 31Controlling changes to work in progress 34Cost control measures for commercial and industrial projects 35Implementing management change projects to realise the intended benefits 39Concluding summary 41References and further reading 42

Tel +44(0)1780 756777 Fax +44(0)1780 751610 Email [email protected] Web www.cips.org NOV 07

This document summarises the management of projectsand project programmes, with emphasis on theprocurement function.

Introductory definitionsHundreds of terms and phrases have evolved overrecent decades of project and programme managementand comprehensive glossaries exist in guides publishedby The Association for Project Management (2006) andthe Project Management Institute (2004).

This section sets the scene by defining the terms‘project’ and ‘programme’. A shortlist of other essentialdefinitions then follows in alphabetical sequence.

ProjectThe key characteristic of a project is that it is new. It isa step into the unknown that always carries an elementof risk because of its novelty. Every project needscareful pre-definition, costing, planning andmanagement, if it is to produce its intendeddeliverables and satisfy all its stakeholders. Lock (2007)identifies four principle categories or types of projects,as follows.

• Type 1 projects: civil engineering, quarrying,mining and construction projects. These are projectsthat, although planned and designed withinenclosed offices, are built on sites that are usuallyremote from the headquarters of the maincontracting organisation.

• Type 2 projects: manufacturing projects. Theseprojects are generally carried out within enclosedpremises and result in a tangible product, whichmight be anything from a new microchip prototypeto a luxury cruise ship.

• Type 3 projects: internal and management changeprojects. These are projects initiated and paid for byan organisation or group for its own purposes,usually with the intention of creating future financialbenefits. Examples include IT projects, mergers andacquisitions, marketing projects, organisation

reorganisations, new brand or product developmentand organisation relocations. Most stage, screen andmusical projects have similar characteristics, becausethey are funded internally with the expectation offuture benefits. Projects conducted by not-for-profitorganisations often belong to this type, even thoughthey may not result in financial benefit for theproject owner.

• Type 4 projects: projects for pure scientificresearch. These laboratory projects cannot usuallybe defined with any accuracy, carry enormous riskof failure, and may not be amenable to projectplanning and management processes. One thing thatthese projects do have in common with the otherthree categories is that they need the procurementof goods and services.

These project classifications are, of course,generalisations and there are exceptions. However, theyare convenient when discussing project andprogramme management.

ProgrammeA programme is a mix of projects in an organisation.For example, a civil engineering or constructionorganisation might be conducting several projectsconcurrently for different paying customers. Those,together, can be classed as a programme of projects. Atthe same time, that organisation might wish tointroduce some internal changes, such as areorganisation, a new IT system, or the relocation of itsheadquarters offices. These Type 3 projects would thenbecome part of the programme mix. The totalprogramme mix is often called the project portfolio.

With exceptions that are too rare to consider, everyproject has a finite life. But the life of a programme hasa duration that marches with the life of theorganisation itself, although the programme contentwill be dynamic, constantly changing with time, as newprojects are added and others are completed orabandoned.

ProgrammemanagementIntroduction definitions

2 Tel +44(0)1780 756777 Fax +44(0)1780 751610 Email [email protected] Web www.cips.org NOV 07

ProgrammeA programme is a mix of projects in an organisation.For example, a civil engineering or constructionorganisation might be conducting several projectsconcurrently for different paying customers. Those,together, can be classed as a programme of projects. Atthe same time, that organisation might wish tointroduce some internal changes, such as areorganisation, a new IT system, or the relocation of itsheadquarters offices. These Type 3 projects would thenbecome part of the programme mix. The totalprogramme mix is often called the project portfolio.

With exceptions that are too rare to consider, everyproject has a finite life. But the life of a programme hasa duration that marches with the life of theorganisation itself, although the programme contentwill be dynamic, constantly changing with time, as newprojects are added and others are completed orabandoned.

Other essential definitionsContractor - Throughout this document the termcontractor is used to describe the organisation thatmanages and performs the project work. The contractorwill often delegate tasks to external agents and sub-contractors.

Procurement - No CIPS member will need thisdefinition, but it is included here for the benefit of ‘layreaders’. Procurement is the function of obtaining allthe goods and bought-in services that an organisation,or other organisation, needs for its projects and otheroperations. Procurement and supply chain managementincludes the appraisal, rating and selection of vendorsand the formulation and conclusion of contracts. Theprocurement of any good begins with a specification ofthe requirement and does not end until the good isdelivered fit for purpose, to a safe and secure place, atits required point of use, at the right time, in the rightamount, and at the right cost.

Project owner - The project owner is the projectcustomer, the organisation or organisations thatcommissions and pays for the project, and will own theproject after its completion and handover by thecontractor. Because Type 3 projects are commissionedin-house, the project owner is also the projectcontractor. A few companies call their project managers‘project owners’ because they ‘own’ responsibility fortheir projects. Those companies create an internalcontract for each project in which the two main partiesare the organisation and its project manager. Becausethese practices can give rise to confusion between theidentities of the real project owner and the projectmanager, they will not be assumed in this document.

Scheduling - A process that begins by placing allidentifiable tasks or activities in a logical sequence. Theprocess continues by estimating duration times forthose tasks, and by establishing which tasks shouldclaim the highest priority for management attention,and the allocation of scarce resources. Throughout thisdocument, it will be assumed that scheduling isconducted using the critical path method, supported bya computer loaded with competent software, used byplanning engineers, or others who are fully trained andexperienced for the purpose. Later in this document,the value of a project or programme support office willbe stressed in this context.

Stakeholder - A stakeholder is any person ororganisation that will be effected by the project or hasan interest in its execution and outcome. For example,in a project to build a new shopping mall, the propertydeveloper, the banks and other financing institutions,the shareholders, the contractors, the workers, theeventual tenants, the shoppers, the public utilities, thelocal authority, and the local residents are allstakeholders. Large projects have stakeholders atdifferent levels, so that the owner, other investors, andthe main contractor are primary stakeholders, andothers with more indirect interests are secondary ortertiary stakeholders. Hartman (2000) declares that a

ProgrammemanagementIntroduction definitions

NOV 07 Tel +44(0)1780 756777 Fax +44(0)1780 751610 Email [email protected] Web www.cips.org 3

ProgrammemanagementIntroduction definitionsProject life cycles


successful project is one that satisfies all itsstakeholders. Consideration of stakeholders’ interests isalways important and we must applaud Hartman’sadmirable goal. However, it must be accepted that it isnot always possible to satisfy the interests of everysecondary and tertiary stakeholder.

Work breakdown structures (WBS) and coding systemsWork breakdown is the process of dividing a projectinto smaller parts which can more easily be visualised,costed, and managed. The WBS process begins early inthe project life and becomes refined with time as moreinformation about the project becomes available. AWBS is a hierarchical structure in the fashion of afamily tree, with the programme or project at the top,and with the smallest components or tasks occupyingthe bottom level. Devaux (1999) puts the case for theWBS cogently and is good, generally, on planning. Keyto any work breakdown structure is its coding system.A code must be allocated to every part of the WBS. Thecoding should be hierarchical so that the code for anyparticular element identifies the element itself, the levelor layer of the WBS to which it belongs, and itsrelationship with other elements to which it is directlyconnected (either physically or by cost). No relationaldatabase can operate without a logical coding system.Coding systems are described in Lock (2007).

Project life cyclesEvery project has a finite life, which passes though anumber of phases. The boundaries between some ofthese phases may be indistinct, and phase overlappingis common. However, key events or milestones canusually be identified that usher in each new phase orsignal the end of a dying one.

The term ‘life cycle’ is indicative of a natural cycle ofbirth and regeneration, but projects do not really copynature in that way because each is individual, andtravels from birth to final, obliterating death. A projecthas no soul! However, we shall adhere to the commonconvention and continue to call the passage of aproject from beginning to end its ‘life cycle’.

A popular misconception to dispel is that a project lifecycle begins when work starts on the project and endswhen it is finished and handed over to the customer orend-user. That definition really describes only thefulfilment phases of a project. Many textbooks fall intothis trap and most do not even mention theprocurement phase.

The true life cycle begins when the project is initiallyborn as a concept or entrepreneurial idea, and does notend until the project outcome ceases to be of practicaluse. Thus a Type 1 or Type 2 project life cycle will endwhen the original product is decommissioned,demolished, or sold for scrap. The end of a Type 3project life cycle can occur for a variety of reasons, butit is usually attributable to further management changeprojects or the end of the organisation in its currentform. Typical life cycle phases for industrial andmanagement change projects are illustrated in Figure 1.

Figure 1 A typical life cycle for a large industrial project

Project phase

1 Original concept

2 Feasibility study

3 Business plan

4 Risk assessment

5 Public enquiry

6 Authorisation

7 Organisation

8 Planning

9 Design

10 Procurement

11 Construction

12 Test/commission

13 Handover

14 Economic life

15 Disposal

Two-year periods

ProgrammemanagementProject life cyclesNet cash-flow and benefit realisation


Type 4 (pure research) life cycles are different andunpredictable. An effective way to keep control of aresearch project is to conduct regular managementreviews, on the understanding that each review willeither authorise a fresh tranche of funds (allowing theproject to continue to the next review) or pull the plugon the project and redeploy the research team ordisband it. This process is called ‘stage gating’.

Net cash-flow and benefit realisationMost companies undertake projects and programmes torealise benefits that can ultimately be quantified infinancial terms. Thus, to understand the characteristicsthat classify a project as ‘successful’ it is necessary tohave some idea of the relationship between costs,revenues and profits. And that means understandingthe principles of cash-flow management.

Costs are cash outflows. Revenues and other incomes(including authorised borrowings) are cash inflows. Thedifferences between cash inflows and cash outflows arethe net cash-flows. Anyone who manages their personalcurrent bank account without incurring unauthorisedborrowings will understand these principles. However,some project managers concern themselves only withcash outflows, and many erroneously refer to costreports as cash-flow reports. Project engineers often donot even concern themselves with costs at all. Thus,before delving more deeply into the subject ofprogramme management, we need to define what ismeant by cash-flow management and benefitrealisation.

Typical project cash outflow (cost) patternsMost projects display the kind of cost pattern shown inFigure 2. Once a project has been authorised to start,the rate of expenditure is at first slow whilst theorganisation is put in place and initial detailedplanning, scheduling and design begin. Then, when thefirst purchase orders are issued and work begins onthe physical tasks, the expenditure rate rises rapidly.When work begins to tail off, as the project nears

completion, so the rate of expenditure also tails off,and the graph becomes asymptotic towards the finalcost (which, of course, should not be allowed to exceedthe total cost budget).

All project managers are familiar with these graphswhich, because of their characteristic shape, are alwaysknown as S curves. All Type 1, 2 and 3 projects displaysimilar cost patterns, although they seldom produce acurve as smooth as that shown in Figure 2. The costcurve for a Type 4 (pure scientific research) project canbe almost linear _ a line that climbs with time untileither a result is obtained or someone pulls the plug onthe project.

Net cash-flows patterns for single projectsTo calculate the net cash-flows pattern for a project it isnecessary to set out all the cash inflows and cashoutflows in a spreadsheet in the manner of that shownin Figure 3 (see following page). This should be doneusing estimated values before the project starts, andthen repeated using actual values for comparison andcontrol purposes as the project proceeds.

Cash-flows forecasts are always important, but they areparticularly so for Type 3 projects. A predicted cash-flows schedule is an essential ingredient of the pre-authorisation business plan for every proposedmanagement change project.

Pro

ject

cost

s(c

ash

outfl

ows)

Time

Design and drawPlan/organise Buy goods and services

Make or construct Test/ debug

HandoverProject fulfilment phases (which will usually overlap)

Cost budget

Actual costs

Figure 2 Typical project expenditure pattern (the ‘S’ curve)

The elements in the spreadsheet cannot be calculatedbefore the project has been defined in some detail anda work breakdown structure or task list has beencompiled. Then the best possible cost estimate must bemade for each item. A provisional project schedule willallow the estimated costs of each item to be placed orspread over its expected position in the project timeframe.

A large project will require several such spreadsheets,compiled in a hierarchical fashion that agrees with thework breakdown structure. The cash-flow from thepages at lower levels must be rolled up into a summaryspreadsheet for the project.

The example for a single project given in Figure 3shows that the contractor will expect to have a shortfallof funds for most of the project’s life cycle, althoughstage (progress) payments received from the customerwill do much to reduce the amount. It can be seen thatin the second quarter of the year 2010 the contractormust expect to fund work in progress to the amount of£395 000.

Should the contractor decide to make provision forthose shortfall funds by borrowing from a bank orother external source, the amounts to be drawn downfrom the loan agreement will be shown at theirexpected times on the cash-flow schedule in anadditional row under the ‘cash inflows’ heading. Thecorresponding repayments of the loan principal andloan interest must then be inserted in additional rowsin the ‘cash outflows’ section.

Understanding essential differences between the cash-flow patterns for different types of projects

Type 1 and Type 2 projects will produce cash flowpatterns that differ considerably from those of Type 3projects. Type 4 (pure research) projects often cause asteady, unrelieved outflow of funds. These differencesare shown graphically in Figure 4 (see following page).

ProgrammemanagementNet cash-flow and benefit realisation




Figure 4 Typical cash flow patterns for different types of projects in a contracting company’s programme mix

Design and drawPlan/organise Buy goods and services

Carry out main project tasksTest/ debug

Handover

Time

AuthorizeImplementation and operation

Main project phases

Type 1 and Type 2 projects (with customer’s progress payments)

Cas

hou

tflow

sC

ash

inflo

ws

+

0

_

Revenues

Costs

Approximatenet cash flow

Contractor’sgross profit

The contractor ceases to have direct financial interest

in the project after it has been completed successfully

and handed over to the customer

Type 3 projects (internal projects where the contractor is also the project owner)

Cas

hou

tflow

sC

ash

inflo

ws

Graph of cumulative net cash flows

Benefit realisation: the timing, slope and shape of this curve will depend on the degree of project success

Time

Breakeven point

Cas

hou

tflow

sC

ash

inflo

ws

Time

Type 4 projects (internal projects for pure research)

Costs could continue without benefit until the project is terminated

Very high risk project - thebenefits might be anything from nothing to enormous



One point to note about every curve in Figure 4 is thatthe cash outflow (cost) curves have been inverted fromthe S curves familiar to most project managers. Thisinversion is logical mathematically because costs, ascash outflows, are negative quantities.

Projects classed as Type 1 or Type 2 will usually becarried out by the contractor (or contractors) againstfunds provided by a paying customer, although thecontractor may have to fund work in progress duringthe project design, procurement and execution phases.The project selling price should exceed the total projectfunding and yield an immediate profit for thecontractor on project completion and handover.

In large projects the contractor’s net cash-flow positionis often protected to a great extent by the contractualterms of payment. The customer agrees to makeprogress payments (stage payments) againstindependently certified claims for payment at periodicintervals during the project’s design, procurement andbuild phases, or upon the achievement ofpredetermined progress milestones. The spreadsheetshown in Figure 3 includes stage payments.

Projects classified as Types 3 and 4 have afundamentally different financial pattern from those incategories 1 and 2, because they are usually paid forfrom the organisation’s own capital reserves or fromloans, and the organisation cannot realise the fullfinancial benefits until well after the project has beencompleted and fully implemented. Thus an internalmanagement change project requires the organisationto fund all the work in progress, and the cash inflowswill not begin until the project has been finished andthe operational improvements that it creates show costsavings or other financial benefits. However, when theproject is successful, those benefits will accrue to theorganisation for many years into the future. Whereascommercial Type 1 and 2 projects are conducted toachieve short-term profits, management change projectsshould instead produce future cost benefits in a

prolonged process that is called benefits realisation.See, for example, Bradley (2007).

There is an important cash-flow exception for Type 4projects, which is when one organisation that ownslaboratory facilities undertakes a programme ofresearch for another organisation (which might be aorganisation or a government department) under acost-plus or cost reimbursable contract. Here theresearch laboratory (the contractor) is providing anexpert service, for which it can claim and receivefrequent and regular payments to offset its cashoutflows, usually marked up to provide a steady andreliable profit revenue for the contractor. Then thecustomer carries the burden of cash outflows and bearsalmost all the considerable risk.

The relationship between the procurement functionand cash-flow managementThe extent of the financial influenceFor any project the proportion of total costs attributableto bought-in goods and services is likely to be verysignificant. Purchases typically account for over 50 percent of the total cost, and for some projects can evenbe as high as 80 per cent. It is clear that purchasingwill have a considerable impact on each project’sfinancial performance and, therefore, on theorganisation’s net cash-flow position.

Unfortunately, the procurement role is commonlyundervalued or even disregarded. For example, mostwriters ignore the contribution that procurement canmake to a project’s success or failure. If you findyourself at a loss for something to do one wetafternoon, go to your nearest reference library andgather an armful of all those books that deal withproject and programme management. Then look for thewords ‘procurement’, ‘purchasing’ or ‘supply chain’ intheir contents lists. Nothing there? Then look in thedetailed indexes at the back of those books.Astonishingly, you will find that this most importantsubject is often completed ignored.

Minimising cash outflowsThe following are among the key actions that keep acontractor’s cash outflows (costs) under control:1 Define each project as well as possible before work

is authorised to start2 Avoid unfunded changes to the project (including

purchase order amendments)3 Perform all critical tasks on time (because late tasks

attract higher overheads)4 Do not schedule goods deliveries too early (which

also means not paying for them too early). Althoughjust-in-time purchasing may not be appropriate forprojects, the use of call-off deliveries for bulksupplies can spread payments to suppliers.However, a good delivered two weeks early is notnearly such a big problem as the same gooddelivered two weeks too late

5 Operate sound purchasing practices, includingcompetitive tendering for higher-priced goods andalways remember that materials’ cost control takesplace before or when purchase orders are issued –afterwards what is often called ‘cost control’ is reallyonly historical cost reporting

6 Scrutinise all suppliers’ invoices and don’t pay beforethe goods have been received in good condition, ortoo soon, before the credit period expires.

Maximising cash inflows1 For all but the smallest, short-duration projects,

arrange for the customer to make progresspayments and record those arrangements in theterms of payment in the contract

2 Perform all critical tasks on time (this repetition ofitem 3 above is not an error) because tasks that runlate will delay the times when interim or finalinvoices can be issued to customers

3 Issue invoices to customers on time and avoid errorsthat could provide excuses for non-payment

4 Turn customers’ requests for project changes to yourorganisation’s advantage – remember that theseneed not be priced keenly because there are nocompetitors for work done under contract variations

5 Pursue debtors

The trauma of cash-flow difficulties.When a manager signs off a supplier’s invoice forpayment, he or she assumes that the accountsdepartment will issue a cheque and that the invoicewill be paid. However, if the contractor is experiencinga cash crisis, that might not happen when it should.When a organisation runs short of cash, its creditorsoccupy different positions in a strict pecking order.First, comes the payment of government taxes. Paymentof wages and salaries is usually given high priority.Payments to suppliers and other creditors can comefairly low down in the order.

As soon as payments to one or more suppliers fail, orare made very late, word will spread throughout thecommercial world. Under those conditions, the lives ofpurchasing managers and their expeditors suddenlybecome very difficult and stressful because, on the onehand they are trying to obtain goods with which tofeed the revenue-earning projects and stifle the clamourfrom the project managers, while on the other hand thesuppliers feel less than enthusiastic about providingfuture supplies. In the worst case, suppliers couldwithhold deliveries altogether pending payment of theiroutstanding invoices. So the downward spiral toinsolvency begins and accelerates. Anyone who hasworked under those conditions (as this writer has) willreceive a sharp, practical lesson in the importance ofcash-flow management.

If a cash-strapped contractor’s project portfolio includesone or more expensive and ambitious internalmanagement change projects, the managers of Type 1and Type 2 projects will feel aggrieved that the successof their projects is being put in jeopardy by thisdiversion of cash. Then, the purchasing department andits buyers will justifiably feel very angry that this cashwastage makes it difficult or impossible to obtainsupplies for revenue-earning work. This is just one ofthe reasons for getting the portfolio balance right.

ProgrammemanagementThe relationship between the procurementfunction and cash-flowmanagement


Managing the project portfolioEvery business organisation will usually have at leasttwo fundamentally different activity streams. One ofthese is the revenue-earning projects or serviceactivities, which the organisation sells and upon whichit depends for its survival and growth. Successfulcompanies will maximise this area of their business,and will attract as much work as possible, with theexpectation of profits. The funds derived from thoseprofits, after paying tax, provide incentives to investors,such as shareholders. But some of those profits andother funds will often have to be diverted to Type 3 orType 4 projects that are intended to increase theorganisation’s potential for future profitable work.

Attracting and authorising new commercial projectsfor the portfolioClearly, senior management must always seek tomaintain or increase the amount of profitable work thatcomes into their companies. This is typically achievedthrough reputation and marketing, and (depending onthe type of organisation) through submitting successfultenders for new projects. Subject to avoiding the trap ofovertrading, the organisation will want to accept asmuch revenue-earning work as it can get. If theorganisation is a contracting organisation, it will beseeking to add as many Type 1 or Type 2 projects to itsproject portfolio as it can handle.

Procedures for authorising new commercial projects forexternal (paying) customers are usually well establishedwithin contracting companies. The deciding factors forauthorising or rejecting a new project include thefollowing:• How well the scope and nature of the work is

defined• The financial status and commercial reputation of

the intended customer (will the bills be paid in fulland on time?)

• The degree of assessed risk• Whether or not the proposed project falls within the

contractor’s sphere of competence

• Whether or not the necessary resources areavailable, or can be made available

• The ratio of the expected profit margin to theestimated costs.

If all these signs are good, the contractor will probablydecide to accept and authorise the project. Once acontract is made, the contractor will issue an internaldocument, such as a works order, that informs all keymanagers of the project’s essential details, announcesthe name of the project manager, allocates a projectname and number, and permits expenditure withinbudget to start.

Screening and authorising internal managementchange projectsThe process for considering and authorisingmanagement change projects is quite different fromthat for revenue-earning commercial projects. We havealready demonstrated that these internal projects cannever create immediate profits, but will certainly addsubstantially to current cash outflows. They often carryhigh risk of failure and their intended benefits can bedifficult to quantify.

However, in any organisation or group of significantsize, the senior management will usually receive manyrequests from managers for internal changes that claimto offer irresistible future benefits. Unlike commercialprojects, where the problem is often an uncertainty asto where the next project work is coming from andmaintaining a full order book, the difficulty for thesenior managers of large companies is now reversed.They often have to fend off some suggestions forinternal projects that will certainly cost money butmight not yield the benefits promised by the initiators.

When an internal management change project is addedto the portfolio, it will drain cash in the short term,even if it eventually realises all the intended benefits.Its inclusion in the portfolio can divert scarce resourcesfrom revenue-earning activities.

ProgrammemanagementManaging the project portfolio


Management change projects that fail are alsoexpensive, because of the damage that they cause tostaff morale. Most management change projects requiresome staff to accept and learn new working methods.The more ambitious projects cause organisationalchanges that require some staff to leave and others toaccept new roles in a changed organisation. If all thateffort fails, owing either to a flawed business plan orpoor project management, the culture of theorganisation will be damaged. Any future managementchange project will be treated with suspicion and witheither apathy or outright hostility, and so performanceof revenue-earning operations will suffer.

Thus senior management must strive for a balancedand well-considered portfolio, ensuring that it containsa mix of projects weighted in favour of those that willbring in revenues and protect the cumulative net cash-flow. Only those internal projects that are supported bya sound business plan and align with corporateobjectives should be considered for authorisation.

The senior management of a large organisation orgroup can expect to receive concurrent suggestions forinternal projects from several managers. Not all thosesuggestions will be motivated by sound organisationmotives: for example, it is not uncommon for managersto suggest schemes for reasons of personal careeradvancement or because of peer pressure from theirmanagement colleagues. To enable senior managers toassess and compare the individual merits of theseapplications and decide priorities for acceptance, theoriginators must be asked to submit business plans.Every business plan should be prepared to a standardorganisation format, and each should include at leastthe following:• A clear statement explaining the nature and scope

of the proposed project• A description of how the proposed change will

effect the organisation and its staff

• A schedule of the expected benefits, with every item(including the intangible benefits) expressed infinancial terms and placed in its expected timeframe

• A plan showing the outline timescale of the projectand the period of implementation, with key eventslisted and highlighted

• A cash-flow schedule. Cash-flow schedules thatexceed one or two years should be discounted at arate not less than the organisation’s expectedinternal rate of return on investment (IRR) to findthe expected net present value (NPV) of the project.See Dayananda et al (2002) for a good explanationof investment appraisal methods

• A risk assessment, listing all foreseeable threats• A statistical analysis of the costs and benefits,

preferably using the Monte Carlo probability methodto predict the worst, most likely and best results.

Some larger management change project proposals areso complex that they present more than one possiblecourse of action. For example, moving the headquartersof a large organisation can be a huge, expensive,disruptive, risk-laden undertaking, and there willusually be widely different opinions about where thenew location should be. Thus there might be morethan one possible business plan, each supporting aseparate case, so that a feasibility study must be carriedout to assess the merits of each possible case and areport prepared, with recommendations. This will assistsenior management in deciding not only whether ornot to authorise the new project, but also to choosebetween the different cases. A feasibility study for alarge management change or investment project canitself be a big project, costing many millions of pounds.

Management change projects occasionally have to beaccepted and added to the portfolio, even when theirnet present values and visible cash benefits fall short ofthe organisation’s usual acceptance level. Prominentamong these are projects undertaken for health andsafety. For example, a hotel organisation may have no



choice other than to undertake expensive internalproject works in order to obtain fire certificates for allits premises, without which the organisation could notcontinue to trade.

Avoiding technical and organisational conflictswithin the portfolioManagement change projects, because they are soinvasive of the organisation’s normal organisation, canconflict with each other. It is very possible that twoproposers, unknown to each other will each suggest amanagement change project that although individuallysound in concept, would lead to conflict, mayhem andchaos if the two were allowed to proceed together. Forexample, it would be unwise to redesign aorganisation’s cost accounting systems based on theexisting IT, when a different management changeproject was being conducted independently to replacethe IT systems.

An organisation that is enthusiastically pursuing aproject expected to increase efficiency, and reduce staffrequirements, would be unwise to a conduct arecruiting drive for more permanent staff. This couldhappen if poor management communications keptsome departmental managers in ignorance of the newinternal change project.

Thus it is important that someone in the organisationhas a composite view of programme strategy, and hasenough knowledge of the corporate objectives, to beable to recognise potential conflicts before unwiseinternal projects are allowed. The programme directoris one person who might perform that role.

Total cost considerationSellers of office equipment sometimes makeextravagant claims for the financial benefits that theirparticular goods or systems will bestow on the buyer’sorganisation. A similar argument applies to theproposers of new internal change projects, and they areapt to present their financial justification with an

optimistic bias, either innocently or intentionally. Thosecharged with the considerable responsibility ofauthorising, or rejecting such projects, run the risk onthe one hand of authorising a new project where thefinancial data are fundamentally flawed, or on the otherhand of turning away a request for a project thatwould, in fact, have produced good financial benefits inthe longer term.

One test that senior managers can apply is to askwhether or not the cost estimates embodied in thebusiness plan are indeed the total costs. For example,one IT project in this writer’s experience failedfinancially because its business plan did not allow forthe following circumstances:• The project, far from achieving the forecast

reduction in staff numbers, actually required morestaff in the general organisation departments and,also, more expensive staff to run the new computer

• Had staff been made redundant by the project, therewas no provision for redundancy costs payable tocompensate the released staff

• There was no provision for staff training costs• A clean power supply, raised sub-floor, air

conditioning and automatic fire protection had to beprovided, but neither those things, nor the basicaccommodation itself, had been allowed for in theestimates

• The equipment cost was correctly shown as acapital purchase sum, but the subsequent annualoperating costs of the maintenance contract andsubstantial 24-hour electrical power supply costswere not included.

Thus anyone charged with authorising or rejecting amanagement change project needs to examine not onlythe forecast benefits, but also the total cost implicationsof the project.



Time spacing changes that effect the same internalfunctions or systemsThe relatively long period leading to benefit realisationfor an internal change project, when compared withother kinds of projects, means that the success orfailure of an internal change project cannot bemeasured until some time after the introduction of thechange. For a qualitative assessment of the change’seffect it is usually necessary to compare ‘before’ and‘after’ figures. These figures will usually apply to one ormore entries in the organisation’s accounts.

For that reason alone, it is bad policy to introduce anew internal change project into a system whilstanother change to the same system is in progress. Afterone full accounting period has elapsed the effects ofthe first change can be measured.

In this context it is also important to remember thedisruptive (even demoralising) effect that changes oftenhave on staff. The success of every internal changeultimately depends on staff accepting andimplementing the change willingly. If you attempt tointroduce a new change into a department or systemwhere another change is undergoing implementation,that will be asking for obvious and avoidable trouble.

Organising industrial and commercial projectsThis section introduces the complex but importantsubject of project and programme organisation.Although there is space here only for a summarydiscussion, the more important principles can beexplained and illustrated. For further reading, Lock(2007) and Meredith and Mantel (2003) give fairly fullaccounts of project organisation. Buchanan andHuczynski (2003) go into far more depth. (Theseaccomplished authors must have had their tonguesfirmly in their cheeks when they called their 900-pagetome ‘an introductory text’).

A suitable project organisation will enhancecommunications between all the project participants. Itwill also help each project manager to motivate all thepeople involved towards meeting the project goals. Theconverse is true when an inappropriate organisationwill contribute to project failure.

Although particular organisation structures can berecommended for certain kinds of projects, the rulesare not hard and fast. The final organisation choicemust depend on geography, the organisation culture,and other factors, such as whether project completionon time or long-term organisational stability are thedominant goals. Examine two different companiesconducting similar projects and their organisationsmight be found to be quite different, although bothcompanies might be equally successful. Ask a group ofpeople from different companies to draw charts(organigrams) of the organisations in which they work,and you will find that there are almost as manyorganisation structures as there are companies.However, senior managers who set out to establishproject or programme organisations in their companiesmust understand the basic organisation structures thatare outlined in the following paragraphs.

Matrix organisationsFigure 5 (see following page) shows a matrixorganisation. Suppose that a organisation undertakesan industrial project for the first time, and has to mixthe project work with its routine operations. There isno one in the existing organisation who can view theproject holistically and ensure that it progressessmoothly, from one functional department to the next.The wise approach is to appoint a person to plan andcoordinate the project’s progress across all the diversefunctional departments that will perform the projecttasks.



Note that the chart in Figure 5 places the purchasingfunction among ‘other organisation departments’, whichis a common, if unwise, view.

So far this describes a weak matrix organisation, inwhich the project manager has no line authority. He orshe can only plan and coordinate the project tasks.

A balanced matrix organisation has the same physicalstructure as a weak matrix, but the project manager isgiven some line authority and is expected to sharedecisions on project tasks with the functional(departmental) managers. For example, a chief civilengineer might have to agree with the project manageron which tasks should be performed by the civilengineering department on a particular day. The theoryis fine but it has the drawback that anyone working ina functional department is suddenly faced with twobosses. If the instructions of the departmental managerconflict with those of the project manager, mayhem istriggered and despair follows. It is said that a balancedmatrix violates the principle of unity of command.

Because no real project team exists, the projectmanager will find some difficulty in motivating peopleto identify with the project and to feel that they arepart of a virtual team. Also, project communicationstend to be slower in a matrix because commands anddata have to cross departmental boundaries.

Stronger forms of the matrix are sometimes used, inwhich the project manager can overrule thedepartmental managers. The secondment matrix is thestrongest form, where the project manager can ask fornamed individuals to be seconded to work on his orher project. Strong matrix forms share some of thecharacteristics and advantages of project teams, whichwill be described next.

A big advantage of any matrix organisation is that themain structure of the organisation can continueunchanged as projects come and go. In theory,individual members of staff can look forward to steadycareer advancement within their own specialistfunctions. A matrix is also considered to be good forquality of design because functional expertise isconcentrated within each group under the expertguidance of its specialist manager.

When the organisation begins to undertake moreprojects, it can appoint more project managers tooversee them, with each having his or her own lines ofcommunication, influence, or even command across thefunctional departments. There is a hint of thatdevelopment in the bottom left-hand corner of Figure 5.

Project team organisationsFigure 6 shows an organisation structure that iscompletely the opposite of the weak or balancedmatrix. This is a project team organisation.

ProgrammemanagementOrganising industrial and commercialprojects


Companymanagement

Departmentmanager 1

Projectmanager

(Project A)

Departmentmanager 2

Departmentmanager 3

Departmentmanager 4

Department 1staff

Department 2staff

Department3 staff

Department 4 staff

Other companydepartments

Figure 5 Characteristic form of a matrix organisation

AccountsHRMITMaintenanceMarketingOffice servicesPurchasingQualityStoresOther project

managers asrequired

Projectsdirector

Project group1

Project group 2

Project group 3

Project group 4

Other companydepartments

Figure 6 A project team organisation in a contracting company

AccountsCateringHRMITMarketingOffice servicesPurchasingQualityStores

Project support office manager

Managers of other projects

Groupscomprising

other project teams

Projectmanager

Companymanagement

A project team

With any team organisation there is no conflict ofcommand and no doubt about who is in charge of theproject because the project manager is givenunequivocal line authority. Once again, the purchasingfunction is often excluded from the team and relegatedin the chart to ‘other organisation departments’.

The advantages and disadvantages of teamorganisations are the opposite of those claimed for theweak or balanced matrix. Team spirit and motivationare more easily engendered. Communications are fast,not hampered by inter-departmental boundaries. Peoplework alongside others working on the same project,and they can all identify themselves closely with theproject and its success or failure. But, as a projectbegins to draw to its close, the team members canbecome demotivated when their thoughts begin to driftaway from completing the remaining project taskstowards where (or if) they will be working when thecurrent project ends.

The example chosen for the illustration in Figure 6 isfor an organisation carrying out a number of concurrentType 2 (manufacturing) projects. The arrangement for aconstruction organisation’s headquarters would besimilar. These Type 1 projects could also be remote siteconstruction teams, each of which would probably haveits own site manager who reports back to the relevanthome-based project manager.

The choice between matrix and team organisationsIn general, a matrix organisation will suit anorganisation that has many small projects continuouslyentering and leaving its order book, while a teamfavours larger individual projects, especially whencompletion on time is particularly important.

Hybrid organisationsSome companies operate as a matrix, but set up teamsfor special projects when the occasion demands. Forexample, a team or task force might be set up for aproject (or even part of a project) that is particularly

urgent. That particular application is described below inthe sub-section headed ‘Corrective measures’ within themain section ‘Controlling and correcting work inprogress’.

A very small project could be assembled within theelectrical engineering department for a project to installa big new transformer for a client That project willinvolve mainly electrical design tasks and no otherfunctional department will play any significant part inthat particular project. A pumping project could bebased wholly within a piping and fluids department.

A construction organisation that operates a matrixorganisation at its headquarters will certainly have toestablish a self-contained team at each significant site.Large site organisations recognise the importance ofpurchasing by having a materials controller to overseegoods arrivals, secure storage and to undertake somelocal purchasing.

The organisation of any organisation that customarilycarries out industrial or commercial projects, and thenfinds itself also conducting one or more internalchange projects, will almost certainly become acomplex hybrid organisation.

Organisational changes required when anorganisation begins to undertake multiple projectsfor paying customersWhen an organisation is successful in attracting projectorders, and the trickle of projects has become a flood,a project director is often appointed to report to seniormanagement and oversee the project managers and theproject programme. The projects director, with anoverall view of the project workload, is the person bestplaced to advise senior management on theorganisation’s ability to accept new work, and he orshe can forecast future manpower needs. A projectprogramme support office can assist the project’sdirector in this planning and scheduling role.

ProgrammemanagementOrganising industrial and commercialprojects


These developments were introduced in the teamorganisation shown in Figure 6 and would also applyto a multi-project matrix organisation. The role of aproject or programme support office will be describedlater in this document.

Organising internal projects and mixed projectprogrammesManagement change projects differ in many respectsfrom industrial and commercial projects. They oftenoccur in service companies (banks, insurance, catering,retailers, service providers and so on) that have noother experience of projects. Even in companies that donormally carry out projects as part of their everydayactivities, a management change project will usuallyeffect administrative departments that would notusually take part in project tasks (such as HRM, IT,accounts, marketing and purchasing).

Case example 1: an internal project in a serviceorganisationFigure 7 shows how an internal management changeproject might be arranged in a service organisation (aninsurance organisation in this instance). Thisorganisation has little experience of projects or theirmanagement, but its board has decided to approve alarge internal project (it might be new IT or aorganisation move, for example). Because the board

collectively has no project expertise, it has placed someof its directors in a steering committee. Their prime jobis to represent the main board in all decisions effectingthe direction and scope of the new internal project.Unless the main board directs otherwise, the steeringcommittee must always be bound by the intentionsexpressed in the business plan for that project.

To assist the steering committee, an external consultantwho does have considerable experience ofmanagement change projects has been appointed.Although the external consultant acts in an advisoryrole, it would be a very unwise steering committee thatfailed to heed his or her advice. It is important to avoidany possible conflict of interests, so the externalconsultant must be entirely independent of otherexternal companies that might later be sub-contractedto provide facilities (such as premises, equipment,office systems or IT) for the new project.

A project team organisation is always indicated for amanagement change project, because a team will havethe good internal communications and motivationneeded to plan and coordinate all aspects of the project.This will drive it through to successful completion,including successful implementation and gainingacceptance for the project from the organisation’s staff.Such a team is better described as a task force.

It is wise and customary to staff this task force with themost senior and more competent people that can befound from the organisation’s functional departments(one or two from each department). These peopleshould be released from their normal duties and beseconded to work for the project manager. Thatapproach has the big advantage that each functionaldepartment will be represented in the new projectdevelopment. This will help to prevent mistakes in thedesign and execution of the project, and will be ofgreat benefit to the project manager when the timecomes to implement the project.

ProgrammemanagementOrganising internal projects and mixedproject programmes


Figure 7 A service company with one large management change project

PublicitySalesTelesales

RenewalsClaimsRecordsAdmin.Buying

IT systems andtelecoms

BuildingsFurnitureSecurityCanteen

Recruiting TrainingPensionsWelfare

AccountsLedgersPayroll

Marketingdirector

Office manager

IT manager Facilitiesmanager

HRmanager

Finance director

Mainboard

Steeringcommittee

Independent consultant

The project task force

Projectmanager

Sub-contractors

The existing organisation for routine company operations

Organisation for the management change project

Finding a project manager with the necessary skills tohead the task force can be a difficult problem for anorganisation that has no experience of projects. Thereare several solutions. One is to train an existingmember of staff, which can work well if time allows.Another is to appoint a project manager on atemporary staff contract basis. A third option is to askan external consultant to manage the project.

Case example 2: a programme that mixes projectsfor external customers with one or more internalprojectsIn the previous section, the introduction of amanagement change project into a organisation withno previous project experience was discussed. Thissection examines how the organisation of anorganisation that regularly carries out projects forpaying customers might be adapted to include one ormore management change projects.

Figure 8 illustrates two alternative possibilities, inwhich the contracting organisation carries out itsrevenue-earning projects in either a matrix or a teamorganisation. Assume that each of the two companiesdepicted in Figure 8 has a similar project workload andthat each is currently conducting two unrelatedmanagement change projects.

One point to make clear at once is that everymanagement change project is so different in characterfrom commercial projects that it is unlikely that any ofthe contractor’s existing project managers would easilybe able to take command of one without furthertraining. The typical project managers in a contractingorganisation are principally technically orientated. Ifthey are particularly good at their jobs, they might alsohave a working knowledge of financial accounts and‘people issues’. But the requirement for a managementchange project manager is different. He or she is goingto have to manage the project with the intention ofrealising financial benefits for the organisation in thelonger-term future, and that can mean a protracted,

often difficult period during which ‘people issues’ andmonitoring of the organisation’s financial performancebecome extremely important. A good managementchange project manager will understand the need togain the acceptance of staff in all the departments thatare going to be effected by the change, upon whomthe ultimate success of the project will depend and willwork closely with the organisation’s financial managers.

Thus, the organisational solution should be one thatseparates management change projects from theregular progression of commercial projects and placesthem under a different management structure. This hasbeen done in both the organisation structures shown inFigure 8.

A steering committee reports to the main board. It isauthorised to make strategic decisions, liasing withexternal consultants and deciding the fate of everyrequest for a project change (project change control isfeatured in a later section of this document).

The programme director is an appointment that onlybecomes necessary when there is more than oneinternal management change project. The role is similarto that of the projects director, but confined to theinternal change projects programme. In someorganisations the roles of project director andprogramme director are combined (one person doingboth jobs).

The programme support office (PSO)Whether or not the programme consists entirely ofcommercial projects, of management change projectsonly, or a mix of the two, it makes great sense toestablish a programme support office. Even though thefundamental character differences between externalcommercial projects and internal management changeprojects prompt the establishment of two differentproject management groups, those differences do notpreclude setting up one support office to serve allkinds of projects and their managers. Some companies





use the alternative name ‘project services’ to describetheir programme support office.

A programme support office needs its own supervisoror manager, who might be given the title ‘projectservices manager’. A typical support office will combinethe basic functions of cost estimating, critical pathplanning and task progressing, but a competent officecan do much more. Here is a summary of the tasks thata programme support office could be asked toundertake:• estimating the costs of new work or proposals• registering newly authorised projects and allocating

their serial numbers• guiding project planning meetings (under the

chairmanship of the relevant project managers)• establishing and keeping up to date a computer-

based model of the organisation’s project workload(using a process called ‘multi-project resourcescheduling’ that will be described later)

• issuing recommended task work-to lists todepartmental managers

• managing the project management software andprotecting its system and files from corruption

• running occasional ‘what if’ scheduling for seniormanagement to test the possible impact of newwork

• calculating estimates of future manpower needs thatwill help senior management and the HRMdepartment to plan for changes (up or down) instaffing levels.

• project cost reporting and cost control• change control administration, including maintaining

a change log for each project• contract administration, or at least that part of the

process which requires constant updating of projectbudgets and client billings to keep pace withauthorised changes in project scope or content

• risk management administration, includingmaintaining the risk log (the programme supportoffice can be one ‘home’ for a risk manage)r

• compiling earned value reports for projects

• liaising with external sub-contractors, especially fordesign agencies

• and, as all the best advertisements say, much more

A project or programme support office can beexpensive to set up and staff because although some ofits members will need only basic clerical skills, mostmust be people with professional qualifications andexperience. But the function can be justified andenthusiastically recommended for project organisationsfrom medium size upwards. Figure 8 showed twopossible organisational arrangements.

There are companies that run programmes in whichsome or all of the constituent projects are too small tojustify their own project managers. One option is toappoint project managers who will each be expected tomanage several small projects simultaneously. However,a competent programme support office can oftenundertake the junior project management roles ofissuing work instructions, then measuring andreporting the resulting performance.

In many respects, a programme support office can beconsidered as just another specialist functionaldepartment in the organisation. Grouping all thoserelated talents in one department is more efficient interms of staff numbers and retained knowledge andexperience than spreading its support work over theother functional departments and project teams. Aboveall, just as the computer database can store and processinformation across the programme of projects, so thesupport office can earn respect as a human informationhub.

There are several publications that describe theprogramme support role. These include Marsh’s twobooks (1999) and Miranda (2003).



Project procurement and supply chain organisationNone of the organisation descriptions given so far hasgiven sufficient prominence to the vital role played bythe procurement and supply chain functions. Thatomission must now be redressed. This section describesan organisation structure known as a contract matrix,but the arguments given here for the procurement andsupply chain functions apply equally to all other kindsof project or programme organisation.

Principles of contract matrix organisationstructuresFigure 9 shows a contract matrix project organisationthat is often used by contracting companies in theconstruction and civil engineering industries. Ourexample is loosely based on the organisation that wasused by a large international mining group. Althoughour simple organigram cannot show all the complexcommand and communication links that would operatein practice, it does recognise the procurement roles.

The principal feature of a contract matrix is that theproject owner or client (who has no direct experienceof managing large construction projects) engages acontracting organisation that has considerableexperience in undertaking construction projects. Thereare many possible arrangements but in our examplethe managing contractor carries out detailed projectdesign in its headquarters offices (referred to as thehome office to distinguish it from the siteorganisations). The managing contractor undertakesand manages all the project work on behalf of theowner, including all purchasing and the provision ofthe construction site team. Some managing contractorsemploy direct construction labour, and others, as here,rely more heavily on sub-contractors.

The managing contractor’s home office could beorganised as a matrix or as a number of separateproject teams. Figure 9 shows the project team option(partly because it was simpler to draw!) and assumesthat there would be a separate team for every project

in progress. However, matrix organisations, similar tothat shown in the upper half of Figure 8 are verycommonly used.

It is probable that a large contracting organisationwould also be carrying out one or more internalmanagement change projects. That condition isindicated in the extreme right-hand portion of Figure 9.

ProgrammemanagementThe programme support office (PSO)


Figure 9 Part of a team-based programme organisation structure for a managing contractor

Companymanagement

Project XYZowner (client)

Projects director

Projectengineer

Project design team

Guarantor forthe bank loan

The bank(s)

Project XYZ manager

Steering committee

Programme support office

Projectmanager

Programme director

Other internal change projects

Teams for otherconstruction projectsproject teams

Projecttask force

Other home office departments

Levels on this chart do not indicate status and the communication and command links have been simplified.

European suppliers

Overseas suppliers

Overseas purchasing

departments

Freightforwarding

agent

Overseas purchasing

agents

Home office purchasingmanager

Project XYZsite manager

and team

Local suppliers

Sub-contractors

Site materials

Financing organisation for project XYZ

Independent engineer

Home office purchasingdepartment

The managing contractor’s home office organisation

ProgrammemanagementProject procurement and supply chainorganisation


The project financing organisationThere are many possible ways of financing a largeproject or programme, which can range from usingexisting capital reserves, through selling or mortgagingproperty assets (for example in sale and lease-backdeals) to raising more capital through an issue of newshares. In the example shown in Figure 9, the owner ofproject XYZ has made a financing agreement with abank, so that the bank will initially pay all valid claimsfor payment from the managing contractor. The bankrequires insurance to protect the loan capital shouldthe project fail. That insurance has been provided byan external guarantor, to whom the project owner mustpay a premium. For overseas projects carried out byUK companies the Export Credits GuaranteeDepartment (a UK Government department) might actas guarantor (visit http://www.ecgd.gov.uk/).

Both the bank and guarantor will need to be convincedthat the contractor’s payment claims are valid. Becauseneither of those two bodies will have any technicalproject experience, that is usually done by appointingan independent engineer who will examine theprogress made and certify every justifiable contractor’sinvoice.

Purchasing agentsThe contractor’s home office includes a purchasingdepartment, and the manager of that department(operating through one or more buyers on thedepartment’s staff) represents the contractor in allpurchase contracts and is thus a purchasing agent forthe complete programme of projects.

However, when a contractor buys equipment andmaterials from overseas suppliers, it makes sense toappoint a purchasing agent in each country, or at leasteach continent, where such purchases are regularlymade. A local purchasing agent will have first-handknowledge of the commercial and technical regulationsthat apply in the region and can also be helpful inadvising about local transport facilities. For example,

one purchasing agent prevented an expensive mistakeby pointing out to a contractor that the local railtunnels had unusually small radii, so that long-loaddeliveries would have to be sent by road.

In another case, the local agent was able to warn amanaging contractor of a special dockside securityproblem. Local shantytown dwellers, always keeping akeen lookout for building materials for their own‘construction projects’, were apt to visit during the weesmall hours and remove timber from packing cases.Thus expensive project equipment was left on thequays with no protection from the elements.

Overseas purchasing agents can repay their fees manytimes over in time and money saved on projects. Aswell as feeding the home office purchasing agent withvendor rating data, and in helping with suppliershortlists, local agents either employ, or can engage,inspecting and expediting engineers who can visitsuppliers’ premises to make progress and qualitychecks, and to witness crucial equipment tests.

Coordinating the purchases made by different agentsIt is important that procurement over the wholeprogramme is coordinated centrally, so that goodscommon to more than one project are identified. Thenit is often possible to combine those purchases toachieve economies of scale. The coordination processmust be directed by the home office purchasingmanager, so that purchasing power for commonlyordered items is not diluted by spreading it over one ormore agents.

The home based agent must also have systems in placethat, while appraising him or her of all purchases inthe group, prevent confusion over who hasresponsibility for placing particular orders. Suchconfusion can lead to duplicated orders or, possiblyworse, goods not being ordered at all.

Multiple project managersAn interesting point to note about project purchasing isthat the manufacture of every item of high cost bought-in equipment will probably be seen and managed byits supplier as a project within the main project. Thusmany suppliers and sub-contractors will appoint theirown project managers to work on their portions of alarge project. A contract matrix organisation usuallycontains a number of project managers in addition tothe main project manager.

Purchasing agents must ensure that the internalplanning and control methods used by those suppliersand sub-contractors are adequate to ensure timelydelivery of work that is fit for purpose.

Freight forwarding agentInternational movements of freight bring a panoply ofspecialised procedures into play that would confuse theaverage engineer, and even some buyers. Theseprocedures include such mysteries as export invoices(which some nations demand are printed in anastonishing number of copies on their own forms) andinternational letters of credit. Port and customs’ dutiesare also important ‘Failure to pay them, or to observeother local procedures, can result in goods being heldup in customs sheds for long periods.

Every wise contractor operating internationally willappoint a freight forwarder organisation to advise onall transport issues and to oversee the transit of allgoods in the programme. The experience and wisdomof a good freight forwarder complements that of localpurchasing agents. Every reputable freight forwarderhas access to a worldwide organisation with goodcommunications that allows every consignment to betracked throughout all stages of its journey.

The freight forwarder will know how to avoid the useof ports that are experiencing temporary congestionand delays, or he or she will route goods to avoid

national border posts where the local customs officersare unreasonably officious.

Freight forwarders also help to cut transit costs byconsolidating to optimise container loads – ensuringthat half-empty containers are not shipped.

Site purchasing organisationsAll but the smallest construction site will have its ownmaterials controller, and on the larger sites thecontroller will be empowered to make local purchases.

A site materials controller, and his or her team, shouldbe regarded in just the same way as the goods inwardsand stores functions in a home office. The site materialscontroller is responsible for goods inwards checks,secure and safe storage, safe materials handlingprocedures, and for both routine reporting andexception reporting back to the purchasing agents. Onlarger sites the materials controller will also have somelimited local purchasing authority.

Partnerships between purchasing agents andtechnical staffPrudent people know that purchase contractnegotiations are more like to be trouble-free when theyare conducted on a partnership (win-win) basis. Ofcourse competitive purchasing, using invitations totender and sealed bid procedures must be in place forevery order of significant cost. None the less,partnerships are intrinsically more productive and freefrom risk than confrontations.

Choice of the successful bidder in every case must be ajoint decision between the buyer and the projectengineer, the former to oversee the commercial aspectsand the latter to decide on the expected technical orquality performance. So, here is another form ofpurchasing partnership, this time between each buyerand the relevant engineer.

ProgrammemanagementProject procurement and supply chainorganisation


Unfortunately engineers often undervalue the work ofpurchasing organisations, believing that their onlypurpose is to issue purchase orders printed on standardforms. Conversely, buyers might have their own preferredsources of supply based on solely on commercialreasons, but the engineers might believe some of thosesuppliers to be less than technically perfect.

Project managers and engineers must not ignore theprofessional support available from their purchasingdepartments. Even the most brilliant engineer willprobably be unfamiliar with the practices andterminology used in purchasing and supply chaincircles and that unfamiliarity could lead to someexpensive mistakes. The average engineer will certainlyknow what an FAQ is, but failure to recognise FAS asan Incoterm could lead to some serious cost and riskimplications. Every engineer knows the relatively smalldifference between a metric tonne and an imperial tonNot knowing the potentially far greater differencebetween either of these and a shipping ton couldprovide an expensive mistake when shipping a fewtonnes of bulky but feather-light goods.

Engineers must often talk to suppliers during thebidding phase for an order. They need to do that toresolve technical questions and, sometimes, to agreemutually beneficial changes to purchase specifications.However, there is always the risk that an engineer willbreach the accepted rules for sealed order bidding ifsuch discussions give one supplier an unfair advantageover another. Another serious and more common risk isthat an engineer will unwittingly (or even purposely)commit his or her organisation to a verbal contractduring telephone discussions, or to a written contractwhere emails are involved. This pre-empts thepurchasing process and, possibly, sealing a less-than-perfect contract. Roylance (2006) calls this unofficialactivity ‘rogue purchasing’.

Roylance sensibly declares that, just as a purchasingdepartment needs to negotiate with external suppliers,

so it must act as its own internal marketing department,‘selling’ the advantages of its services to the contractor’sengineering staff (and to senior management).

Scheduling resources part 1: introductionResource scheduling is a subject that is poorly servedin the literature, probably because it is so complex. Theideal goal of resource scheduling is to convert theintended project work plans into schedules that useonly the resources that are available (or that can easilybe made available) and to arrange that the dailyrequirement for each kind of resource is as smooth aspossible, with no significant peaks (overloads) ortroughs (implying idle resources).

The technicalities of the process depend to some extentupon which software package is used. Scheduling ofany project can involve complexities. These includedifferent calendars, especially for companies that mixnormal day working with shift working, or conductinternational projects where some sub-contractors andworkers observe different holidays. There are alsoquestions such as to whether or not any task may beinterrupted to allow resources to be divertedtemporarily to other more critical tasks. Many of theseissues are discussed in some detail in Lock (2007), andit is not appropriate to go into greater detail here.However, it is possible to give some general advice.Most of the following advice refers to commercial andindustrial projects. But common resources diverted towork on internal change projects should be included inthe same multi-project scheduling process.

The first question that any project or programmemanager should ask is ‘Do we need to carry out anyresource scheduling at all?’ The only case where thatquestion will generate a negative answer is for aproject or programme of projects where absolutelyevery task is let out to sub-contractors. Resourcescheduling is still necessary, but under thosecircumstances it is the sub-contractors who must do it.

ProgrammemanagementPartnerships between purchasing agentsand technical staff


Another basic question is ‘What do we mean byresources?’ In theory any resource that can bequantified in terms of a name and simple usagequantity can be scheduled (bulk materials, cash,machining and test facilities and people with specialskills, for example). Some resources are difficult todescribe in simple one-dimensional units. For example,assembly space is three-dimensional and the shape ofthe space is sometimes important. However, when mostproject managers talk about resource scheduling theymean scheduling people with specific skills or trades.That is the aspect of resource scheduling which will bediscussed here. Once the process has been mastered, itrequires only common sense to extend it to schedulingthe other kinds of resources (and to multipleconcurrent projects).

Following the dictum that it is better to learn to walkbefore trying to run, this section must first examinesome of the steps for scheduling a single project. Thenthe argument can progress to scheduling resources fora programme.

Priority rulesResource scheduling involves deciding which projecttasks should claim priority for the allocation of scarceresources. Establishing that answer begins by ensuringthat every project is planned by a suitably detailedcritical path network. Network time analysis will revealhow much float each task possesses. Tasks with nofloat are critical and have first claim on resources. Thepriority status of other tasks is inversely proportional totheir remaining float. (Remaining float is the amount oftotal float that remains for a task after its start, orprogress has been delayed for any reason, includingintentional delay during resource scheduling). Mostproject management textbooks describe the critical pathmethod fairly well. Gordon and Lockyer (2005) is onetext that has enjoyed popularity over several editionsand Devaux (1999) abounds with common sense.Some essential resource scheduling principles aredisplayed in Figure 10. Imagine that each section of

Figure 10 shows the same fragment of a bar chart(Gantt chart) for a project, extracted from the bar chartfor the whole project. Further, please remember thatthe original whole bar chart (which might containhundreds of tasks) was obtained by conversion from aproject network diagram after time analysis. Allcompetent project management software readilyproduces such conversions.

Each of the three sections of Figure 10 shows theentire project plastering tasks required for a smallproject. In the top part of Figure 10, the planner hastaken no account of resources but has simply placedeach task at its earliest possible time indicated by thenetwork time analysis. The result is known as resourceaggregation. That approach, although commonlypractised by project managers, almost always leads toan impossible resource usage pattern that contains bothoverloads and idle periods. In the example of Figure10, the project contractor has one only plasterer on thepayroll but the aggregation schedule requires two onthe first day, three for each of the next two days, beforefalling back to the preferred limit of one plasterer.Clearly that work pattern is far from ideal.

ProgrammemanagementScheduling resources part 1: introduction


Four of the five tasks shown have some total float, andthose tasks could be delayed slightly without delayingproject completion. But task 130 is critical and must becarried out as early as possible. That information willallow the planner to schedule some tasks a little laterto smooth out the peaks in the resource usage pattern.

In the middle portion of Figure 10 the planner hasdelayed some tasks until the resource requirementnever exceeds the total available (which is oneplasterer). That has produced a resource-limitedschedule. Now the resource usage requirement neverexceeds one plasterer, but that has delayed task 120 fortwo weeks beyond its total float, which indicates thatthe entire project will also run two weeks late.

If the planned delay to a project caused by a resource-limited schedule is unacceptable, a time-limitedschedule can be calculated, as shown in the bottompart of Figure 10. Now the project will need twoplasterers, but their usage pattern is far better than thatshown in the original resource aggregation. In the time-limited case, no task has been delayed beyond itsremaining float.

At one time small projects could be scheduled in thisway using adjustable wall-mounted charts, using somemechanical solution such as plug-in plastic strips ormagnetic bars on a steel board. Now there is plenty ofsoftware available that can schedule not only oneproject, but all the projects comprising a programme.All good software will allow the planner to directwhether a resource schedule is to be a simpleaggregation, resource-limited or time-limited.

There are other options, such as the use of thresholdresources which can be deployed to soak up overloads.Overtime or bought-in temporary staff could providethreshold resources. These complexities will not bediscussed here but they are explained in Lock (2007).

Scheduling resources part 2: summary of the datainput processThe following lists show data that might typically berequired before the computer can carry out resourcescheduling and provide useful reports (such as work-tolists). These are for general illustration and will notapply identically to every brand of project managementsoftware.

Global data for the project contractor• Organisation name• Security access levels (often numbered from 1 to 9,

the top level allowing access to make systemchanges and the lowest level read-only of low-confidentiality information)

• Departmental codes (each code identifies afunctional department and its manager, so that datacan be filtered later to allow each manager to getreports containing only the tasks for which he orshe is directly responsible)

• Default calendar (the calendar driving allscheduling, based on the normal working weekwith all public and organisation-wide holidaysidentified as non-working days)

• One or more special calendars (each to cover suchexceptions as shift-working, departments allowed towork overtime, and overseas parts of theorganisation which observe different working hoursand holidays)

• A code and name for each type of resource to bescheduled

• A number specifying the amount of each resourcenormal available for project work between givenperiod start and finish dates (there is a note on thisin the following main section)

• A cost rate for each resource, related to each timeunit used in scheduling (for example, dollars perday per unit person), again valid between the sameperiod start and finish dates

• Different resources availability levels for differentperiods (this allows for future forecast changes inresource levels)

ProgrammemanagementScheduling resources part 1: introduction


• Different resource cost rates for different periods(which allows for cost inflation and wage awards inthe future)

Data required for each project• Project code ID and project name• Name and department code for the project manager• Project start date• Required project finish date

Data required for each taskThe following list is based upon rate-constant resourceusage. See Lock (2007) for other options.

• Task ID code from the critical path network diagram• Task name (usually abbreviated to fit in subsequent

narrow report columns)• Project code, which identifies each task with its

project. Ideally this code should be a prefix to thetask ID code. Some software can prefix these codesautomatically. Some talented planners will use theWBS code.

• Estimated task duration (based on using thepreferred amount of resources each day)

• The resource code and quantity for each type ofresource (if any) required for the task

• A total estimated task cost (useful tasks such asmaterials purchases)

• Whether or not the task is a milestone or key task(project start and finish tasks will always bemilestones)

• Target or fixed-schedule start or finish date for thetask, (best avoided if possible, because theseinjected fixed dates interfere with optimumscheduling)

• Whether or not a task that used resources issplittable or non-splittable (non-splittable is theusual default condition: splittable tasks may beinterrupted to divert their resources temporarily toother, more urgent tasks). Task splitting is notrecommended because it is disruptive for theresources effected and can damage motivation

• Either the ID code of the preceding task(s) or of thesucceeding task(s), so that the computer can traceall the paths through the network diagram.

Data required for each multi-project schedulecalculation• Time-now (which is the datum from which all

progress information and new schedules will becalculated

• Report customisation, which essentially meansspecifying the column headings of each report

• Filter instructions for each report, which dictateswhat each report shall include or exclude. This ismost useful for compiling departmental work-tolists, for producing exception lists (described in theprogress control section of this document) and formilestone reports for higher management.

• Sorting instructions for each report (for example,sorting all tasks in a work-to list in ascending orderof their scheduled start dates).

Scheduling resources part 3: practical application tomultiple projects

Avoiding over-complicationThe previous paragraphs contained a considerableamount of detail, and even that was not complete. Inany organisation conducting a programme of projects,there will undoubtedly be thousand of tasks toschedule, and all significant tasks must be included inthe software model. However, there are some commonsense rules that can make the lives of newcomers tomulti-project resource scheduling more enjoyable andrewarding. Failure to observe the common sense rulesgiven in the following paragraphs can clog up theprocess and choke it to death.

Dealing with ad hoc and unforeseeable tasks thatcannot be planned in advanceThere will always be a myriad of small, unexpected,jobs that crop up in most departments. These caninclude everything from re-work and corrections to

ProgrammemanagementScheduling resources part 2:summary of the data input process


tasks (in design this is called after-issue work),answering queries from many sources, and so on.These odd jobs will divert staff who would normally beexpected to be working on project tasks.

Coupled with these diversions are the absences ofindividuals because of training courses, sickness,annual holidays, compassionate leave and so on. All ofthese absences reduce the numbers of staff availablefor new project work in each resource category.

Rather than try to deal with these complexities in theirawful detail, it is simply necessary only to allow for a‘sludge factor’ when ‘telling’ the computer the availableamount of each resource. Suppose that you have 50mechanical design engineers on the payroll. It wouldbe an unwise planning engineer who declared 50 ofthis resource type to be available to the multi-projectmodel. This writer has used a sludge factor of 15 percent to cover the sludge. Thus, if you have adepartment of 50 design engineers, tell the computerthat you have 43. Trial and error might eventuallysuggest a different sludge factor, but 15 per cent is agood number to begin with, and that should be appliedto every resource type.

Choosing which resources to scheduleAll good software (and even bad software) will allowwell over 100 different resource categories to bespecified. But it will probably be necessary to scheduleonly a few key resource types.

One multi-project model for an organisation of 600employees conducting many heavy engineering designand manufacturing tasks was operated accurately andsuccessfully with only six of the many resourcecategories being scheduled. Those categories were:• Mechanical design engineers• Drawing office• Checkers• Light machining• Heavy machining

• Assembly

Thus many of the thousands of tasks in the multi-project model were shown as needing no resources.The rationale behind this apparent carelessness was asfollows:1 If the work of the mechanical design engineers was

scheduled in a smooth flow, the associated work byother engineers in designing the controls andlubrication would automatically follow the smoothflow.

2 It was not necessary to schedule everymanufacturing task, but only to ensure that workentered the factory machine shops as a steady flowof engineering drawings. The day-to-day schedulingin the factory was taken over by the separateproduction control system, but the multi-projectmodel did give the production control managerrequired start and finish dates for each sub-assembly.

A similarly simplified approach should be sought forany multi-project model, regardless of the industrysector in which the organisation operates.

Scheduling down to the last five minutes?An enlightened planning engineer, or project manager,who is attempting to keep the multi-project schedulingas simple as possible, will undoubtedly meet withopposition from other managers and supervisors, whofeel that every minute of every person’s time should beaccounted for and scheduled.

One difficulty arises when a person of a particular skillworks on several tasks at the same time. Buying clerksfall into this category. However, if the design engineerswho are writing purchase specifications are scheduled,then the buying clerks will receive their tasks at asmooth rate and their daily tasks probably need not bescheduled. Of course, the procurement tasks willappear on the network and will contribute to thecritical path, but they need not be shown as needinghuman resources.

ProgrammemanagementScheduling resources part 3:practical application to multiple projects


If it is absolutely unavoidable, and the time of peoplesuch as buying clerks does have to be scheduled, thereat least two possible methods:1 Use decimal amounts for the amount of resource

needed for a task2 If the software will not accept decimal quantities,

multiply both the numbers available and thenumbers needed by 10. If cost rates have beenspecified, these will then have to be divided by 10to produce the correct figures in cost reports.

Some software (including Microsoft Project) is veryversatile and will allow hours to be mixed with the daysor other units used for task durations. However, thatapproach can lead to some very complicated outputreports, needing very wide columns to accommodatetimes given in days and hours. It is best to keep allduration units the same throughout the whole schedule.

A good argument for fending off those who try to over-complicate the scheduling process is to remind themthat every schedule is based only upon estimated times,and those times will never be accurate. All that theschedule will do is to create some order where chaoswould otherwise have reigned. However, when themulti-project model is large, the errors tend to canceleach other which leads to working schedules that areentirely practicable.

Setting priorities for the different projects in themulti-project modelHere is a recapitulation of how a sensibly constructedmulti-project model will deal with priorities. Every taskin the model, no matter to which project it belongs,will have its own amount of float (zero for criticalactivities and negative for activities running late). Inevery case, that float pertains to the required finishdate as specified for the end task in the project’snetwork diagram. Thus, all the float throughout thesystem, and therefore the measure of priority for everytask is driven by the target finish dates for all theindividual projects in the model. This means that all

project priorities are automatically observed.

Some higher managers will be difficult to convince andthere will always be those who feel that they must askfor more priority to be put on a particular project. Butthose senior people must be discouraged becauseartificial dabbling with individual task or projectpriorities will undermine the programme schedule andlead to poor resource allocations. This writer has seenvery significant cost reductions and dramaticallyimproved project deliveries as a result of introducingmulti-project scheduling. If those kinds of results canbe shown to the senior managers, then perhaps theywill learn to lie back and let the computer take thescheduling strain.

Work-to listsBy far the most useful reports obtained from multi-project resource scheduling are the departmental work-to lists. The example shown includes fictitious data butis based on customised reports that have provedinvaluable in practice. Each departmental manager ispresented with a list of all tasks scheduled to takeplace in his or her department. Ideally the tasks shouldstart and finish on their scheduled dates, because theseare the dates that the computer has calculated for thesmoothest allocation of resources. The earliest possiblestart date from time analysis is also given for each taskin case resources become available unexpectedly,allowing a task to begin before its scheduled date. Thelatest finish for each task is the day when all the task’stotal float would be used up. Figure 11 shows the idealformat for a work-to list.

Preserving the integrity of the multi-project modelIt is very easy to introduce errors into the multi-projectmodel, or to corrupt it by entering one or more invalidpieces of control data (for example, by specifying anincorrect resource availability level or confusing dollarsand pounds sterling when specifying a cost). Inexpertinterference could change basic parameters, such as thecalendars used.



The effect of such errors will become more serious asthe number of mistakes accumulates and theircombined effect grows with time. Remember that aprogramme, unlike a project, has infinite life because asprojects are finished new projects are added. Thus themulti-project model is unlike the schedule for a singleproject because it, too, has infinite life. It takesenormous skill and effort to re-establish a multi-projectmodel that has been corrupted.

The scope for making mistakes is so great that themulti-project model must be placed in the hands ofexperts who are very familiar with all aspects of criticalpath networks and who have special training andexperience in the use of the relevant software package.They will know what checks to apply and how toavoid the introduction of errors. A good place for thoseexperts is in the programme support office. Thatarrangement is shown in Figure 12.

Although multi-project scheduling requires expertoperators, it need not be expensive or require morethan a few planning engineers. Very large programmes

can be controlled by a surprisingly few expert planners,but there must be at least one other member of stafftrained to take over this role as a back-up reserve.

The ideal planner will be a person of high intelligence,the kind of person who enjoys solving puzzles. Suchpeople learn to develop and exploit advanced short-cutmethods (such as standard modular networks) that willsave a great deal of money, and have an error-freeschedule ready for every new project within a fewhours rather than weeks.

A method for allowing project managers to havehands-on access to the multi-project modelAlthough this section has assumed (and by implicationrecommended) the need for a managed and protectedmulti-project model, there is another approach fororganisations that want their project managers to beseparately and individually free to prepare run theirown planning and control. In that arrangement, eachmanager can produce schedules using less expensivesoftware such as Microsoft Project, but a server cancarry a database that will gather in all these plans andcreate a programme model. Geoff Reiss (1995 and2006) is an expert who has pioneered that approachand he runs a organisation which has developedsoftware to support this method.

Buying and installing suitable softwareThere is an abundance of software from which tochoose for the scheduling and management of singleprojects. Some of those systems have a good capabilityalso for dealing with multiple concurrent projects or a



Work-to lists and cost reports, filtered for individual managers

Feedback on progress - new projects - change requests

What-if? modelling

Cost reports - cash flow forecasts - exception reports -milestone reports - manpower forecasts

Seniormanagement

Figure 12 A programme support office as guardian of the multi-project model

Thecomputer

Multi-projectmodel

The

prog

ram

me

supp

orto

ffice

Departmental and project managers

programme. In recent times a number of systems havealso become available that can assist with portfoliomanagement. However, some suppliers makeextravagant claims for their products and the softwarewill disappoint and prove to be an expensive mistake ifthe wrong choice of system has been made.

When software that fails to live up to expectations ischeap, it might be argued that not much money waswasted on its purchase and all we need to do is tryagain with a different product. However, in programmemanagement many people will be effected by thesoftware and will be expected to use it at one level oranother. That implementation process is expensive.Worse, if it fails, the new attempt will be beset with theproblems caused by the general apathy and distrust ofthose who, having seen one failure, will confidentlyexpect another. A perfect example of a self-fulfillingprophecy.

Suppose that you intend setting up a system for multi-project resource scheduling of all the projects in aprogramme that contains over 100 projects (one of thiswriter’s clients had over 150 concurrent projects). Aftersome research, you might decide that the final operatingmodel will contain perhaps more than 40-000 tasks(spread over the 100+ projects). So, the software must beable to calculate common programme resources over aglobal network containing that number of projects andtasks. Now ask each potential software supplier howmany tasks the software can handle and you willprobably receive the reassuring answer, ‘The maximumpermissible number of tasks is limited only by theavailable computer memory’. But, now ask the differentquestion, ‘How many characters can a task ID containand can they be alphanumeric?’ If you get the answer‘Up to 9999, and they must be numeric’ you havelearned the true capacity of the system.

Many software systems call the whole programmemodel ‘the project’, so that each real project isdescribed in the software as a sub-project. That causes

no difficulties unless the number of ‘sub-projects’ thesystem can handle is below the maximum number ofreal projects that you can foresee in your futureprogrammes.

There are essential differences in the expectations thatparticular project or programme managers have fortheir project management software. There are thosewho employ their systems principally for simple tasksequencing and for collecting and analysingperformance data and presenting it in a form that isuseful and attractive to senior managers. Most of thosesenior managers will appreciate well-presented andvisually effective reports, employing such methods asbar charts, pie charts and RAG progress reporting. (Forthose unfamiliar with this term, RAG reporting refers topictures of red, amber or green traffic lights alongsidevarious pieces of data to identify each reported resultas bad, indifferent or good.) These kinds of reports canbe very useful in helping managers to make decisions.

When the software is used also to schedule costs andresources and produce departmental work-to lists of allthe tasks in a programme, it is actually makingimportant management decisions itself. These decisionsfollow the processing of volumes of data that are fartoo great for the human brain to contemplate, and canyield schedules that, if correctly observed, will directlypromote efficient working and save time and money.

The purchase of software should be conducted usingthe same principles and degree of investigative carethat one would apply for any expensive purchase. Afew names stand out from many others as being morereliable (yet still affordable) than others in this field.These include, for example, 4c Systems, Open Plan andPrimavera. Lock (2007) provides a specificationchecklist and general advice on the acquisition ofproject management software for multi-projectscheduling. The journal Project Manager Todayoccasionally publishes comparative tables for a widerange of software that can act as a starting point (but

ProgrammemanagementBuying and installing suitable software


only a starting point) for identifying potential softwaresuppliers.

When the system is first installed, its implementationmust be taken very seriously. Key staff, probably fromthe programme support office, must be allowed timefor the essential specialist training that only thesoftware supplier can provide. The system will faildismally if senior managers (and, for that matter,project managers) frustrate the efforts of the newlytrained experts by allowing individual departmentalmanagers and other project workers to go their ownways and ignore the essential system communicationrequirements.

Controlling and correcting work in progress

The control loop approachEvery electronic engineer knows the theory of a controlloop in which a signal is fed to a system, and thesystem contains monitoring circuits that can detectdistortion and feed back correction signals that removemost of the errors. A similar principle can be applied inproject management to keep tasks on track and correcterrors. The concept is illustrated in Figure 13 and,because of the electronic analogy, this commonapproach to task management has been calledcybernetic control.

The theory in the project management application issimple but important and can be applied to taskswithin any kind of project up to its initial completion.However, this theory is often too mechanistic forapplication to tasks in management change projectsduring their implementation periods Here the attitudesand motivations of people are the dominant factors insuccess or failure in the benefits realisation process.

The value of the work-to lists described in the previoussection becomes apparent when considering controlloop task progressing. On any day, every manager andsupervisor knows which tasks should be starting, in

progress, or ending within their departments or groups.When a new task is due to start, the managerresponsible decides which person is best able to carryout the work, issues instructions to define the task, andkeeps an eye on the job for its quality and progress. Ifany deviation from plan is detected, the managerdiscusses the difficulties with the worker and correctiveaction is agreed and applied. In management parlance,these deviations from original plans or budgets arecalled exceptions or variances.

The principle of management by exceptionManagement by exception is the process of concentratingmanagement attention on tasks that need action becausethey are either going wrong or are in imminent dangerof doing so. Communication channels and reportshighlight these exceptions in a process that is, notsurprisingly, called exception reporting. Senior managersare screened from floods of routine data that need noaction, but instead have thrust before them bleakwarnings of things that need to be put right. Managersdo not ordinarily receive reports of tasks that are goingaccording to plan, except when the time comes to tellthem that a project has been successfully completed.

A materials shortage list is exception reportingpersonified. Every competent purchasing managerknows the importance of clearing shortages as soon aspossible so that idle time and task delays are kept tothe absolute minimum. Shortage lists, unlike bills ofmaterial, parts lists and order status reports, do not

ProgrammemanagementControlling and correcting work inprogress


Assign thetask from the work-to list

Carry out thetask

Issue corrective

instructions

Monitor progress

against plan

Identify variances in performance

Decide corrective

action

Figure 13 A control loop with corrective feedback

contain every item delivery of materials or componentneeded for the project They simply scream for help ingetting shortages cleared as soon as possible, so thatproject delays (that waste money as well as time) arekept to an absolute minimum.

Time analysis data from critical path networks isinvaluable. Tasks that are running late but which arestill within their float times are exceptions. These canoften be omitted from exception reports, provided thatthe managers and supervisors responsible are using alltheir persuasive and organisational powers to bringthose tasks back into line (perhaps by allowing someovertime working). But critical tasks (tasks with zero oreven negative float) require all stops to be pulled outtoget them finished on time. Spending an extra £1,000 ona task to bring it back on time can often save far morethan that amount in overall project costs. Rememberthat every project delay costs money, through the riskof idle labour time, and through the increased time forwhich the project will have to carry the organisation’soverhead costs.

Corrective measuresFor exceptionally urgent cases there is a process calledimmediate action orders. That process can cover allaspects of a task from design, through purchasing, andexecution to final testing. It can be expensive but itproduces dramatic results. The process is described inLock (2007).

One extreme measure to contemplate when a wholeproject appears to be running late, and out of control,is to create a task force that can drive the remainingtasks through to successful completion. There is nobetter motivator than a dedicated task force for drivingurgent tasks through to success.

To create a task force, senior members of all thedepartments involved in the relevant project tasks areremoved from their daily jobs (and from their desks)and are assigned to a temporarily appointed task force

manager. These task force members should be pickedat a level of seniority which allows them to committheir ‘home’ departments unequivocally to decisionsmade at task force meetings. A special office must beset aside which the task force can call its ‘war room’,where charts and drawings can be pinned to walls orleft laid out on tables, and where the task force canmeet whenever it needs to. The war room must beprotected from the routine communications and affairsof everyday work, so that the task force members arenot distracted by non-urgent interruptions.

Another important approach is to practise concurrencyas often as possible. This means planning so that eachtask can start as soon as possible, not necessarilyhaving to wait until its so-called preceding task iscompletely finished. This process is well known in thepartnership that should exist between design engineersand buyers Here the engineers will give the buyersadvance notice of all long-lead items, as soon as thespecifications are firm enough to allow orders or lettersof intent to be issued. When as many tasks as possiblein a plan are overlapped, the method is called fasttracking. It can shorten the total duration of a criticalpath network dramatically, although it will introduce anelement of risk in the event that some early instructionshave to be changed later as more facts become known.

Controlling changes to work in progressNo matter how well one attempts to define a project, itis a very rare project indeed that runs fromauthorisation to completion without any changes.

First, we must be clear about what is meant by ‘achange’. If a designer tears up a drawing in a fit of rageand frustration and starts again because of afundamental error, that is not a change because thedrawings have not been issued, no other part of theproject is effected (except perhaps through the delaycaused) and neither the project specification nor theproject scope have been effected.



A good definition of a change in this context is anyaction that would cause changed specifications,drawings or other documents to be reissued, wherethat would effect work in progress in other parts of theorganisation, or the project scope.

Every organisation has to be aware of one danger thatis specific to small, seemingly insignificant, changes.Whilst the foreseeable effect of a small change mightseem to be trivial, the cumulative effect of several suchchanges can be more serious, even to the extent ofexpanding the scope of the project beyond thatoriginally authorised (this unfortunate process issometimes called ‘scope creep’).

Changes in projects for external customersChanges can be categorised in several ways, the mostimportant of which is whether or not the change hasbeen requested by a paying customer. Customer-fundedchanges usually add revenue to the project, and theprofit margin for work done under a contract variationcan be higher than the margin for the whole project(because there are no competitors who have to beunder-priced). Customer requests for changes usuallyhave to be accepted, and will only be rejected (politely)if the contractor’s engineers consider that they wouldintroduce new risks for reliability or safety or in someother way jeopardise the project.

Changes can cause work in progress to be scrapped. Forthat reason, a change made later in the project life cyclewill usually be very much more expensive and causemore disruption than the same change made beforedesign starts, because the money invested in work inprogress (sunk costs) always grows with time. Manycompanies impose a ‘design freeze’ or declare a state of‘stable design’ when they feel that the investment inwork in progress on a project has passed a critical point.

Changes originating internally have to be subjected tomore rigorous scrutiny than those funded bycustomers. Clearly, if a serious design error has been

found, or if changes are required to clear difficulties inmanufacture or construction tasks, then the contractorhas little option other than to make the change andaccept the additional cost.

One new difficulty for modern project managers is thatrapidly advancing technology can render designs ‘old-fashioned’ before the project has been completed. Butchanges that are classed as ‘desirable’ or ‘nice to have’must be resisted because every change brings hiddenrisks or additional costs and project delays.

Every organisation that conducts projects should,therefore, have procedures in place for consideringeach change request. Many companies assemble achange committee (or change board), comprising adesign authority, an inspecting or quality authority, andrepresentatives of other departments likely to beeffected by changes.

The control of changes can cause a considerableamount of administrative work to ensure that:• Every change request is entered in a serially

numbered log• Every change request receives scrutiny for its effects

on safety, reliability, progress and costs• The change originator is informed of the change

committee’s decision• The decision of the change committee is

implemented• Design drawings, specifications, and other

documents, are suitably modified so that when theproject is finished they record the true as-builtcondition

• Purchase order amendments are negotiated andissued for all active purchase contracts effected bythe change

• Customers are correctly billed for all changesoriginated by them

• Authorised budgets are amended whereappropriate.



Keeping track of the effect that changes have on theoverall price of a project, and ensuring that they arebilled to the customer, is part of a process calledcontract administration. That task and all other aspectsof change administration are roles that a programmesupport office is ideally placed to carry out.

Change proposals for internal projectsProcedures for considering and implementing changeproposals for internal management change projects arevery similar to those just described for commercial andindustrial projects. However, all changes to internalmanagement change projects will be paid for by thecontractor, because there is usually no external sourceof funds. With the relatively rare exception of changesintended to reduce project scope, these changes willalways increase investment costs. Thus, such changeshave to be considered against the original businessplan for each project, and change authorisation mustbe at senior level.

As with change proposals for external projects, theprogramme support office is the ideal place fromwhich to administer these changes, but theauthorisation level should be not lower than thesteering committee.

Cost control measures for commercial andindustrial projectsMuch has been written on the subject of cost control.However, most published material deals not with costcontrol but with cost analysis and reporting. Theactivities of cost and management accountants,although admirable and necessary, are not calledhistorical costing for nothing.

Project and programme managers are not historians.Their primary interest must be directed towardscontrolling present and future costs. Therefore, thissection (after dwelling briefly on cost collection andreporting methods) will summarise some of the actionsthat can actually keep project costs in check. We have

to start from the precept that every project has a codedwork breakdown structure, and that the best possiblecost estimates have led to authorised budgets thatoverlay the WBS hierarchy. Those same cost estimatesshould also be arranged in an alternative fashion toprovide departmental budgets.

Labour cost collection methodsMethods for collecting labour times are too well knownto need detailed description here but, summarised, theydepend either on timesheets or time-recorded jobcards. In the context of project and programmemanagement, the following shortlist should be noted:• All recorded times must be checked by a supervisor

and must be available for audit• In cost-reimbursable contracts the times may have to

be both audited and certified• Checks must be in place to deter staff from ‘losing’

idle time by booking it to the most readily availableproject job number

• Many modern project software packages havetimesheet facilities (but a famous softwareorganisation once quoted £200 per annum pertimesheet user in addition to the software purchaseprice, so buyer beware)

• The software should be programmed to recogniseand reject attempted time bookings to closedaccount numbers.

Cost collection methods for purchased goods andservicesAgain, the traditional cost collection methods forproject purchases are well known and do not needdescription here. However, there are importantdifferences for the project manager because the earlierhe or she receives cost information, the sooner he orshe can compare purchasing costs against budgets andspot any exceptional trend. Summarised, the differentcost collection methods for purchases are as follows:1. Traditional job-costing methods based on costing

stores issues against job numbers

ProgrammemanagementControlling changes to work in progress


2. Total costs of payments to suppliers and carriersagainst their invoices, collected by project numbers

3. The total costs of all purchase orders placed foreach project.

The first of these methods is useful for providinghistorical records for use in comparative cost estimatingfor future projects. The second option has theadvantage that it will include the costs of freight, portdues and customs taxes but the figures will not beavailable until well after the event.

The third method, when used regularly at frequent andregular intervals, gives the project manager the earliestpossible true cost data, at the time when the costs arecommitted. Thus adverse trends for the project can bespotted as early as possible. But this method dependson trust, close cooperation, and good communicationbetween project and purchasing managers, becauseonly the purchasing department can compile and issuethese reports.

Controlling labour costsAlthough this important subject could be discussed atvery great length, its vital elements can be summarisedin just one short sentence. Control progress and youwill control labour costs. Managing progress will alsogo far in controlling indirect costs (overheads). Themaxim ‘Time is Money’ is even more relevant in 21stcentury programme management than it was in 1748,when it was first used by Benjamin Franklin in hisAdvice to a Young Tradesman.

Control of purchased materials and equipment costsAgain the principle of cost control can be summarisedin one sentence. Control costs before or when purchasecontracts are made and avoid subsequent orderamendments. Every competent purchasing managerwill understand and follow the procedures needed tocement this rule. Once an over-budget contract is made,it is too bad. The damage has been done.

Delays caused by materials shortages are alwaysexpensive. In addition to delaying project tasks, theywaste money by causing idle time, delaying the receiptof stage payments from the project owner, and byadding indirect costs to the project simply because aproject that runs late will attract fixed costs for longerthan planned. Efficient and pre-emptive expediting bythe procurement function can do much to reduce therisk of materials shortages. The logistics function playsa major part in ensuring that the materials are placed atthe point of use when, or before, they are needed. Allthis is part not only of progress control, but also of costcontrol.

Control of sub-contractors’ costsSub-contractors in a programme can range fromscaffolders to IT companies and discussion of theircosts could double the length of this paper. However,there are a few general principles, which are notdissimilar to those for controlling the costs of materials.

Each sub-contract should be seen as a purchasecontract and managed as a mini-project within therelevant main project. That means:• Every sub-contract must be made by an authorised

signatory• The schedule of work to be performed and the rates

to be paid must be clearly included• Changes to sub-contracts should be avoided as far

as possible• Sub-contractors’ work and project management

methods must be monitored regularly for progressand quality

• Every sub-contract should be controlled by contractadministration procedures similar to those used forthe contracts made between the project customerand the contractor for each whole project (scaleddown as appropriate)

• No claim for payment should be accepted withoutverifying that it is a true reflection of the workactually performed.

ProgrammemanagementCost control measures for commercialand industrial projects




There is a special danger on construction projects thatad hoc requests made on site to sub-contractors willlead collectively to a considerable increase in theexpected costs. ‘Do you think while you are paintingthat wall, you could also go along here and do thoserailings for me?’ or ‘Hmmm, I think we need a couplemore courses of bricks on that wall and some razorwire along the top – could you do that for us please?’

On a large project there might be hundreds of suchrequests. The control method is to ask the sub-contractor for a daywork sheet for every such change.Those dayworks must be authorised by the sitemanager and the sub-contractor’s on-site manager.Then, when the project is ended and the days andmonths of final reckoning come, every additional claimfor payment can be verified against its relevantdayworks sheet.

Maintaining valid cost budgetsThe preferred method for establishing a project budget(and by extension the programme budget) is to beginby estimating the cost of each part of the workbreakdown. Those estimates will ‘roll-up’ to give the nettotal project budget. They can also be rearranged toprovide departmental budgets.

All good project cost estimators will also add some‘below-the-line’ items. These are items that will add tothe prime costs of the project in the event that certainnew conditions will occur. The principal below-the-lineentries will include allowances for:1. Contingencies: an allowance for unforeseen work,

such as rework and the correction of mistakes.Internal changes not funded by the customer willuse some or all of this allowance.

2. Cost escalation: an allowance that becomesnecessary in projects of long duration in timeswhere the rate of national cost inflation issignificant. Some contracts will allow re-negotiationof the total project price to compensate thecontractor wholly or partly for increases in the costsof labour and materials.

3. Provisional sums: these are cost estimates for workthat is not included in the contract price and whichmight not need to be charged to the customer. Theywarn the customer of additions to the price thatmight be needed, but which cannot be firmlydefined when the contract is made. For example, ifthe customer agrees to free-issue materials for theproject that have been salvaged from demolition, thecontractor might want to have the cushion of aprovisional sum to cover the cost of providing newmaterials if the old materials are found to be unfitfor purpose.

The internal departmental and task budgets issued atthe beginning of every project must be based on theraw estimated prime cost, with no additions for any ofthe below-the-line items. Then the process of contractadministration begins by amending the issued budgetsand project price from time to time as authorisedchanges occur. The rules should be as follows:1. The costs of scrap and re-work and any similar task

overspends will not effect the issued budgets butmust be viewed and managed for what they are:unauthorised overspending (variances).

2. The estimated costs of authorised internal changesthat will not be funded by the customer shouldresult in additions to the issued budgets asappropriate. The sums thus added must be deleted(drawn down) from the contingencies’ allowance.

3. The estimated costs of changes requested by thecustomer will be added to issued budgets and theassociated price increase must be added to the totalproject price.

4. Increases through cost escalation may be added tobudgets provided that the customer has approved acorresponding addition to the project price. Theseincreases can be funded by drawing down theappropriate amounts from the escalation allowance.

That is a simplified summary of a complex process,which can also include such mysteries as changes incurrency exchange rates (avoidable to some extent if allsuppliers and sub-contractors can be made to quote

their prices and rates in the home currency). Contractand budget administration can need considerableclerical effort and it also needs good bookkeepingskills. Cost engineers in the programme support officecan oversee this function.

Cost reporting and earned value analysisProject and programme managers will usually find thatthey have to devote some of their valuable time incompiling progress and cost reports. Many of thesereports will be for internal digestion but, for someprojects, detailed cost reports must be prepared for theproject owners. Prudent managers will delegate most ofthis irksome task to the programme support office.

Cost reporting is of little value if it is not done withdirect relevance to the associated value added to theproject or, put another way, to the progress that hasbeen made. If a report simply states that 50 per cent ofthe project budget has been spent, one can imagine theresounding ‘So what’ from senior management. Butreporting that 60 per cent of the project has beenfinished for a cost of only 50 per cent of the totalbudget will produce a far happier reaction.

So, how can spending be compared with value added?There is a well-known process called earned-valueanalysis. Much has been written about the method andit is described (for example) by Fleming andKoppelman (2006). The method relies on collectingcost and progress data for every part of the WBS andthen rolling up the results for the entire project. Themethod has its uses (this writer employed it in hisjunior days) but the results must be viewed withdiscretion. The most useful products of earned-valueanalysis are the cost performance index (CPI), and theless frequently used schedule performance index (SPI).Each of these indices should be unity or above toindicate satisfactory performance.

The method allows the project manager to divide thebudgeted costs of all the work remaining to be done

by the CPI to obtain an estimate of the probableremaining costs.

Earned-value analysis has the disadvantage that, whencarried out down to the last detail, it is extremelylabour intensive because it demands accurate andfrequent reporting of actual costs and estimatedprogress for every part of the WBS. It can also produceanomalous answers, such as when costs are reportedfor a job against which no progress has been reported– which will predict a job (and therefore project) costof infinity. When the data are analysed by hand this isno big problem, because the analyst will use commonsense. But when the computer is used (as it must befor large projects) the report can be fit only for therubbish bin.

However, if cost, budget, and progress data can beentered in a report with the format shown in Figure 14,the principles of earned-value reporting can beobtained for substantially less effort. This methodavoids the difficulty of getting into the detail of everysmall task. As with so many other project managementcontrol functions, the detailed work can be placed inthe programme support office.



Project cost report summary Page of pages

Project title: Project number: Report date:

A

Item

BCostcode

COriginalbudget

DAuthorized

budgetchanges

EAuthorized

currentbudgetC+D

FTotal costs

at this report date

ACWP

GValue

earned atreport date

BCWP

JForecast

costsremaining(E - G) / H

KForecast

final projectcostF + J

LForecast

variance at completion

E - K

HCost index

CPI

Figure 14 A cost report format that incorporates some earned value analysis principles

Abbreviations: ACWP = actual cost of work performed BCWP = budget cost of work performed CPI = cost performance index

Implementing management change projects torealise the intended benefitsInternal management change projects bring their ownpeculiar progress and cost management problems. Forthe first phases, when the new systems or otherchanges are being designed, the control of labour,materials and sub-contract costs follow the sameprinciples that apply to any commercial or industrialproject. But, unlike those projects, the project manager’srole extends well beyond the design, procurement andbuilding stages that would normally end in handover tothe customer. Now the organisation is not only thecontractor but is also the customer. In fact the realwork is only begins when the project enters its crucialimplementation phase. And the success of that dependsnot only on those working in the project team, but oneveryone in the organisation who will be expected tolearn and use the new procedures, accept different jobroles, change their place of work, or even be asked toleave the organisation quietly under a redundancycompensation scheme.

When a management change project moves into itsimplementation phase, senior management, otherstakeholders, and the project manager will be lookingnot so much at cost control, but at realising the benefitsthat the project was originally expected to producewhen its business plan was formulated. Much has beenwritten in recent years on benefits realisation (see forexample Bradley, 2006).

The project design must include measures that willallow the expected benefits to be recognised whenthey occur. Fowler and Lock (2006) stress that eachintended benefit should be set in the business plan as aquantity that will be recognisable in the accounts or assome other measurable improvement in otherorganisation performance factors, together with thedate when that benefit will be realised. Financial ratioscan be valuable indicators for this purpose, (see forexample Friedlob and Schleifer, 2002).

Communicating the project objectivesSenior management can be faced with a dilemma abouthow to communicate the intentions and objectives of achange project to the organisation’s staff at large.

There can be a danger in releasing information about achange project too early, or by allowing snippets ofadvance information to leak to the staff at large,particularly when senior management and theiradvisers have no clear idea about the project details oreven whether or not the project will actually happen.In a real case, an organisation was considering theremoval of its London headquarters to a provincialtown. No decision had been reached about the possiblenew location, the timing of the move, or indeedwhether or not the organisation would move at all.Under those conditions it would have been wise tokeep the project under wraps until at least some of thedecisions had been made. However, the staff soonlearned that various senior managers were travelling todifferent parts of the country, and taking one or twoadministrative staff with them. Exeter, Swindon,Warwick and Newbury were all visited in turn, andafter each visit rumours circulated that the organisationwould be moving to Exeter, or Swindon, or Warwick orNewbury, depending on which location had beenvisited last. All this become very unsettling, andproductivity dropped whilst small groups of peoplecould be seen from time to time wearing anxiousexpressions and wondering about their job security. Inthe event, Newbury was chosen for the business planand the site for a new building was even found, but theboard vetoed any move because of the high capital costinvolved. So all the gloom, alarm and despondencycaused among the staff could have been prevented.

A task force organisation will allow the project team tobe located away from the main offices, at least until afinal business plan has been made. However, there willcome a time when communicating either a seniormanagement decision or the organisation’s intentionsmust be communicated honestly and openly to all the

ProgrammemanagementCost control measures for commercial andindustrial projects


ProgrammemanagementImplementing management changeprojects to realise the intended benefits


staff. Staff will be more cooperative duringimplementation if they have been informed previouslyabout any intended change. They will be even morecooperative when they have actually been consultedabout a change and asked for their views. Sometimesstaff representatives can even be invited to serve on thetask force.

How and when these communications are set in placewill depend on the nature of the project, the kinds ofstaff jobs involved, and the general organisation culture.Naturally the main body of staff will not be competentto comment on all the aspects of a technically ledchange, such as the introduction of new IT, but someconsultation can prevent expensive mistakes. Thesedifficulties present a big problem to which there is nouniversal solution. External consultants, who have hadexperience of similar projects in other organisations aresometimes well placed to give advice.

Senior management support for programmemanagementThe role of senior management in supporting theindividual project manager has always been importantbut it is a critical factor for the success of corporateprogramme management. Kerzner (2000) puts thissuccinctly by describing senior managers as ‘thearchitects of project management cultures’. He citesnumerous case studies that emphasise the nature of thisrole. This can be summed up as giving wholeheartedand unflagging support to project managers, whilstresisting the temptation to interfere in their daily tasks.

Senior managers must promote the essentialpartnership between the procurement and engineeringfunctions, and must always be willing and available toresolve conflicts in any part of the organisation.

Support from senior management includes imposingdiscipline to ensure standardisation of projectmanagement practices and procedures throughout theorganisation. That support is crucial also for the

efficient functioning of the programme support office,whose role was outlined earlier in this document.

In programme management, it is the senior managerswho call the shots in deciding which projects should beauthorised and those which should be rejected orreturned to their potential sponsors for better definition.For commercial projects this means negotiation withexternal customers; for internal projects this meansimproving or clarifying their business plans.

Senior management support must never be confusedwith senior management interference. Support indeveloping a project management culture does notmean interfering in the day-today activities andmethods of individual managers. Kerzner (2000) citesone case where a steering committee of seniormanagers was formed with the good intention ofproviding support to project management generally. Itfailed in its purpose because different individualmembers of that steering committee frequentlyinterfered in the day-to-day activities of projectmanagers and gave those managers conflictingguidance and instructions.

Senior management support excludes tinkeringunnecessarily with the relative priorities betweenconcurrent projects. Senior managers must haveconfidence in schedules that have been expertlycalculated in multi-project resource scheduling, wherethe driving priorities are directly and correctly sourcedfrom the individual project target completion datesagreed with the project customers.

However, only senior management can decide and actto pull the plug on a project that is travelling towardsinevitable failure. They must also pull that plug in timeto prevent the sunk costs spiralling to levels that willimpact on other projects in the programme. Hartman(2000) is one writer who emphasises this need toidentify doomed projects in time and arrest their fall tofinancial disaster by wielding the axe.

Concluding summaryThis paper, after giving a few essential definitions, hasoutlined some of the main characteristics of project andprogramme management. Now, to conclude, here is arecapitulation of the main points (with one or twoadditional hints and tips inserted here and there).

• The life cycles, cash-flows, and profit expectationsare fundamentally different for projects conductedfor external customers and internal managementchange projects. A programme usually contains amix of both these kinds of projects.

• The contractors of commercial and industrialprojects expect profit when each project is handedover but management change projects are usuallyconducted for longer term and longer lasting benefitrealisation.

• Every project, of whatever type, should be definedas fully and accurately as possible before it isauthorised. Plans should use the critical pathmethod, and detailed task lists should be arrangedin hierarchical work breakdown format.

• All elements of the work breakdown should becoded, to facilitate subsequent processing, filteringand sorting by the computer database.

• Here are some additional hints and tips for thedesigners of coding systems.• The best coding systems are standardised, so that

they work across all projects in a programme andcan be used in every department in theorganisation.

• Codes should agree with or relate to theorganisation’s code of accounts.

• There is always a temptation to expect too muchof a code. The temptation to add fields for thingsthat would be ‘nice to have’ must be resisted.Always remember the people who will beexpected to use these codes. One ‘brilliant’ systemof job coding for a mining project faileddisastrously because none of the people workingin the exposed and dangerous conditions at themine could be persuaded to moderate their

language and write 18-character codes on theirtimesheets and other work documents.

• Always remember and obey the acronym KISS,Keep It Simple Silly.

• Project engineers and other technical staff need tobe cost conscious, but project and programmemanagers also need to be cash conscious.

• All who work in organisations and projects, and allwho write about their activities need to appreciatethe vital (but often neglected) role played by theprocurement and supply chain functions.

• Senior management must achieve programmeportfolios in which the funding needed formanagement change projects does not outstriprevenues from normal operations and commercialprojects. Only those change projects with soundbusiness plans, should be authorised and care mustbe taken not to authorise two or more concurrentchange projects where those projects would not bemutually compatible.

• Organisational requirements for external andinternal projects can be different. As a very briefgeneralisation:• An organisation that regularly conducts a number

of concurrent small projects might best beorganised as a matrix

• A single large project, or an organisation thatconducts a few such projects are cases where eachpreferred project organisation would be adedicated pure project team

• A project task force organisation is best suited todriving a particularly urgent project and everymanagement change project through to success.

• A project or programme support office (PSO) canprovide a vital information hub and be the logicalhome for cost estimating, planning and scheduling,progressing, cost reporting, change administration,contract administration, and all those other functionsthat are necessary but which might otherwiseabsorb too much project managers’ time. Further thePSO can, given senior management support,safeguard the implementation and practice of cross-

ProgrammemanagementImplementing management changeprojects to realise the intended benefits


project standard procedures that is so important inprogramme management.

• The procurement and supply chain organisation caninclude home-based and overseas purchasing agentsand an external freight forwarding organisation. Allthese functions have to be coordinated within eachproject and across the programme to achieveeconomies of scale in purchasing and freight costs,and to ensure that projects get their vital supplies ofequipment and materials on time, within budget,and fit for purpose.

• Partnerships in purchasing are not only to beencouraged externally between buyers andsuppliers, but also internally between theengineering and purchasing functions. Purchasingmanagers, rather than complaining about lack ofcooperation from the engineers, must market theirdepartments’ contribution to project successinternally. Senior management must encourage thatdrive for internal partnership.

• When an organisation employs all or a significantproportion of its project or programme labour,resource scheduling across the entire programmebecomes essential to minimise both overloads andidle time. Those responsible for resource schedulingshould be equipped with competent software,chosen and purchased with the same degree of careas any other high-cost purchase operation.

• Those who carry out planning and resourcescheduling should be picked for their aptitude forproblem solving. They must always resist demandsfrom others that will complicate the schedulingprocess unnecessarily, whilst on the other handmust always be seeking ways to simplify andaccelerate the planning and scheduling process.

• All resource schedule calculations should be drivenby real project needs, factored by the delivery datescontracted with the project customers. Seniormanagers must be discouraged from any temptationto interfere artificially with these real priorities. Thisis an exceptional case where the computer actuallymakes management decisions, rather than the more

usual case where the computer merely processesand presents data for management consideration.

• Progress control should be exercised throughmanagement by exception principles.

• Change requests for every kind of project must besubjected to critical examination beforeauthorisation. Procedures must be in place for thisprocess, and they can be administered from theprogramme support office. Changes funded bycustomers are usually acceptable (sometimes evendesirable for the additional profits that they canbring). Changes funded internally, which means allchanges to internal management change projects,must be examined with particular rigour; changesthat are merely desirable rather than essentialshould normally be disallowed.

• Historical cost reporting and cost control have to berecognised as related by essentially differentfunctions. The fundamental ingredient forcontrolling labour and overhead costs is efficientworking and good progress control. The costs ofpurchased goods and services (which can be ashigh as 80 per cent of total project costs) are bestcontrolled through established competitivepurchasing procedures, with every item defined aswell as possible in advance. Remember that once anorder has been placed that exceeds budget, the costdamage has been done.

• Earned value measurement in its full form can belabour intensive but can yield misleading results.However, intelligent cost reporting can be madewith less effort, yet still provide a good degree ofearned value reporting (a preferred cost reportformat was shown in Figure 14).

• The success of all projects depends on the people intheir organisations. This is particularly true formanagement change projects, where realising theintended benefits usually depends on manyorganisation staff who work in departments notnormally connected directly with projects.

ProgrammemanagementConcluding summary


References and further readingAssociation for Project Management (2006) APM Bodyof Knowledge, 5th edn, High Wycombe, APM

Bartlett, J., (2000), Managing Programmes of BusinessChange, 3rd edn, Hook (Hampshire), Project ManagerToday

Bradley, G. (2006), Benefit Realisation Management: APractical Guide to Achieving Benefits Through Change,Aldershot, Gower

Buchanan, D.A. and Huczynski, A. (2003),Organisational Behaviour: An Introductory Text, 5thed., Hemel Hempstead, FT Prentice-Hall

Buttrick, R. (2005), The Project Workout. 3rd edn,London, FT Prentice Hall

Dayananda, D. et al (2002), Capital Budgeting: FinancialAppraisal of Investment Projects, Cambridge,Cambridge University Press

Devaux, S.A. (1999), Total Project Control: a Manager’sGuide to Integrated Planning, Measuring and Tracking,New York, Wiley

EU Public Procurement Directives:www.publictender.co.uk

Fleming, Q.W. and Koppelman, J.M. (2006), EarnedValue Project Management, 3rd edn, Newtown Square,PA., Project Management Institute

Fowler, A. and Lock, D. (2006), Accelerating Businessand IT Change: Transforming Project Delivery,Aldershot, Gower

Friedlob, G.T. and Schleifer, L.L. (2002), Essentials ofFinancial Business Analysis, New York, Wiley

Gordon, J. and Lockyer, K. (2005), Project Managementand Project Planning, 7th ed., London, Financial TimesPrentice Hall

Hartman, F.T. (2000), Don’t Park Your Brain Outside,Newtown Square, PA., Project Management Institute

International Chamber of Commerce (2000), Incoterms2000, ICC publication No, 560, Paris, ICC Publishing SA

Kerzner, H. (2000) Applied Project Management: BestPractices on Implementation, New York, Wiley

Lock, D. (2007) Project Management, 9th edn,Aldershot, Gower

Loftus, J., (ed) (1999), Project Management of MultipleProjects and Contracts, London, Thomas Telford

Marsh, D. (2000), The Project and Programme SupportOffice Handbook: Foundation Volume 1, Hook(Hampshire). Project Manager Today

Marsh, D. (2000), The Project and Programme SupportOffice Handbook: Advanced Volume 2, Hook(Hampshire). Project Manager Today

Meredith, J. R., and Mantel, S. J. Jnr. (2003), ProjectManagement: a Managerial Approach, 5th edn, NewYork, Wiley

Miranda. E. (2003) Running the Successful Hi-TechProject Office, Norwood, MA, Artech House

ProgrammemanagementReferences and further reading


Office of Government Commerce (2005), ManagingSuccessful Projects with PRINCE2, London, OGC

Project Management Institute (2004), A Guide to theProject Management Body of Knowledge, 5th edn,Newtown Square, PA., Project Management InstituteProject Manager Today, published monthly byLarchdrift Projects Ltd, Hook (Hampshire)

Reiss, G. (1995), Project Management Demystified:Today’s Tools and Techniques, 2nd edn, London, Spon

Reiss, G, et al (2006), The Gower Handbook ofProgramme Management, Aldershot, Gower

Roylance, Derek, (2006), Purchasing Performance:Measuring, Marketing and Selling the PurchasingFunction, Aldershot, Gower

ProgrammemanagementReferences and further reading


Documents

Programmemanagement - CIPS v2.pdf · 2010-11-23 · Programmemanagement Projectlifecycles Netcash-flowandbenefitrealisation NOV07 Tel +44(0)1780756777Fax +44(0)1780751610Email [email protected]