Copyright @ 2012. Gower.
All rights reserved. May not be reproduced in any form without permission from the publisher, except fair uses permitted under U.S. or applicable copyright law.
26 Managing Multiple Projects, Programmes and Portfolios
This chapter looks above and beyond the individual project and considers how a company’s resources
might be employed across a wide mix of projects that together constitute a programme of projects. Thus
we are here taking a step up from project management into the wider world of programme management.
Project Management or Programme Management?
The project management principles and practices described throughout this book focus almost
exclusively on the execution of a single project. We know that a project might be very small or
incredibly big. We also know that a project can be a venture carried out for an external client or
customer, or that it could be an internal management change or IT project that has no external customer
but is self-contained within the business. One certain thing that all these projects have in common is that
each will need effective project management to bring it to a successful conclusion. There is, however, a
fundamental difference between external and internal projects:
• Commercial projects carried out for external customers are usually expected to generate revenue that
includes profit. Further, that profit should be realized during or immediately after project completion
and handover. ‘Profit’ is money earned directly that can be distributed to the shareholders and other
investors in the company or added to capital reserves (after allowing for taxation).
• Internal management change and IT projects are funded from investors and capital reserves, not from
external customers. These projects do not generate profits directly but they are usually intended to
increase profitability. ‘Profitability’ here means the organization’s ability to make profits from its
future commercial operations. Thus these internal projects can be regarded as enabling projects,
because if they are successful they should enable an organization to operate more efficiently and thus
realize greater benefits in the future.
The mix between commercial and internal projects is indicated, somewhat simplistically, in Figure 26.1.
This particular illustration represents a contracting company that routinely carries out commercial
projects for paying customers. Whilst the company strives to gain business for as many commercial
projects as it can, the senior management is often faced with the need to refuse applications from
well-meaning managers who foresee real or imaginary benefits from their own ideas for new internal
business change and IT projects.
EBSCO : eBook Academic Collection (EBSCOhost) - printed on 3/1/2018 9:41 PM via STEVENS INST OF TECHNOLOGY
AN: 504684 ; Lock, Dennis.; Project Management
Account: stevens.main.ehost
413
Copyright @ 2012. Gower.
All rights reserved. May not be reproduced in any form without permission from the publisher, except fair uses permitted under U.S. or applicable copyright law.
Figure 26.1 Programme of projects in a large contracting company
Another quite different arrangement would be for a company in a service industry. Thousands of
companies operate in the services industries which include, among others, banking, financial and legal
services, hotels and catering, cleaning, healthcare and insurance. Such companies rarely, if ever, conduct
projects for profit but they might have several business change and IT projects running simultaneously.
If Figure 26.1 were to be redrawn for one of those companies, the commercial projects in the left-hand
side of the figure would be replaced by routine operations, but the right-hand side would still show a
number of internal projects, some of which might be extremely expensive – anything from introducing a
new brand or corporate logo, to acquisitions and mergers with other companies.
Managing a Portfolio of Business Change and IT Projects
Business change and IT projects can involve enormous expense and cause considerable disruption
throughout an organization. The consequences of failure can be devastating; hindering or even stopping
the organization’s daily business and operations, damaging tangible and intangible assets, wrecking
market reputation and causing distress or even despair among the staff (the most important asset of all).
It is thus particularly important that senior management are given a business plan to study for every new
project proposal, and that only projects which have acceptably low risk and that promise to contribute to
the corporate objectives are allowed to proceed.
The number of business change and IT projects that fail greatly exceeds those that achieve success
and there are always some in the public eye that seem to cost several times their original budgets
without delivering the promised benefits. Any manager faced with a proposal to authorize a new
internally funded project must always bear this risk in mind. In a company of any significant size, it is
probable that senior management will be faced at any given time with more than one proposal for a new
internal project, and in a group of companies the problem will undoubtedly be greater.
The first action needed is to establish a procedure to ensure that any person who submits an idea for a
new management change or internal IT project prepares a business plan. Further, every business plan
should be presented to a common format, so that senior management are more easily able to compare
one with another on a like-for-like basis. This principle is not dissimilar to the bid summary proposal
used for purchases, but now the stakes are far higher. An initial screening process can also be put in
place that should identify on sight projects that could be of no practical benefit to the organization.
There are managers who propose grandiose schemes that might boost their own egos but would be of
absolutely no benefit to the company. I remember one such example of a proposal where a company’s
training manager lobbied senior management to invest in an expensive new corporate training centre, to
EBSCO : eBook Academic Collection (EBSCOhost) - printed on 3/1/2018 9:41 PM via STEVENS INST OF TECHNOLOGY
AN: 504684 ; Lock, Dennis.; Project Management
Account: stevens.main.ehost
414
Copyright @ 2012. Gower.
All rights reserved. May not be reproduced in any form without permission from the publisher, except fair uses permitted under U.S. or applicable copyright law.
be housed in new purpose-built premises, complete with its own machine shop. That was made as a
serious proposal, to be pursued as an ‘act of faith’ at a time when the company was on a steep
downward path to bankruptcy with a bank overdraft of such proportions that it was having to withhold
payments to the suppliers of essential goods and services.
There is a finite limit to the resources available even to the largest group of companies. Even if all
the new business plan proposals were rock-solid, cast-iron, guarantees of success, it is most probable
that many would have to be rejected through lack of resources. Resources in this sense means not only
cash reserves, but also the highly-skilled people needed to manage and drive through these projects to
successful implementation.
Portfolio management is an active process needing decisive and incisive actions to ensure that:
• priorities for new proposals are based on the amount and timing of the expected benefits (expressed as
cash values), the inherent risks, the amount of resources needed and the availability of those resources;
• no investment is committed on any project unless it has been expressly authorized by senior
management, who must always bear in mind that they will be committing investors’ and shareholders’
funds that might otherwise have been available for distribution as dividends;
• only the most expert people available are assigned, so that the risk of mistakes through incompetence
or inexperience is minimized;
• every active project is regularly monitored with the understanding that the plug can be pulled to stop
further funds being sunk into any venture that shows early signs of failure.
An organization that directs its effort wrongly in these respects could be investing (or rather, wasting)
tens of millions, or even hundreds of millions, of pounds in inappropriate projects. Even billions of
pounds have been wasted in a few public sector IT projects (for example in the UK’s National Health
Service and, even more spectacularly, in some defence projects). In an ideal world, a company’s
shareholders should be able to see how each and every project adds value to their investments.
Multi-project Resource Scheduling
THE CASE FOR MULTI-PROJECT SCHEDULING
Many companies choose to do without network-based multi-project scheduling or even without resource
scheduling at all. In some instances this may not be serious. For instance, construction companies that
rely mainly on subcontractors for their site work will be able to leave most manpower resource
scheduling to the external firms. Only head office design and supervision staff will have to be
scheduled, and relatively primitive scheduling methods can often be used satisfactorily for that limited
purpose.
It is in those organizations which employ their own permanent direct labour force for a number of
simultaneous projects where multi-project scheduling is more likely to be essential. A multi-project
schedule has benefits for an organization beyond the planning and control of existing work. The
schedule, if properly prepared, is a model of a company’s total workload. As such, it becomes a
powerful aid to manpower and corporate planning. It is possible to run ‘What-if?’ trial schedules, testing
possible new projects in the multi-project model to see what effect these might have on the company’s
future workload and capacity requirements.
The remainder of this chapter assumes that portfolio management priority difficulties have been
sorted out, so that the only problem remaining is knowing how to marry the individual project plans and
resource needs to the resources available in the company. I have to make one or two assumptions before
I can conclude this chapter. These are:
1. that the principles of resource scheduling explained in Chapters 15 and 16 have been absorbed and
understood, particularly with regard to scheduling people with specialist skills;
2. that every project in the resource-scheduling mix has been subjected to at least work breakdown
EBSCO : eBook Academic Collection (EBSCOhost) - printed on 3/1/2018 9:41 PM via STEVENS INST OF TECHNOLOGY
AN: 504684 ; Lock, Dennis.; Project Management
Account: stevens.main.ehost
415
Copyright @ 2012. Gower.
All rights reserved. May not be reproduced in any form without permission from the publisher, except fair uses permitted under U.S. or applicable copyright law.
structure (WBS) and OBS breakdowns, without which work instructions cannot be targeted to the
relevant managers and supervisors;
3. that a critical path network diagram has been drawn with sufficient detail and care for every project;
4. that the project management software has been chosen to ensure that it will be able to cope with the
volume and complexity of data in the multi-project model.
All of this can still present an apparently difficult problem. The system has to digest a vast amount of
data, priority conflicts must be resolved and all logical task interdependencies need to be observed. In
addition, the result has to be dynamic and responsive to changes, such as design modifications, technical
problems, work cancellations, the introduction of new projects or fluctuations in total resource
capacities.
In the past such planning had to be carried out mentally, using adjustable bar charts, which severely
restricted the capability and flexibility of the system. However, as in the case of single-project
scheduling, computer systems are available to everyone for this process.
PROJECTS AND SUB-PROJECTS
In multi-project scheduling there is an important difference of scale from single-project scheduling. The
organization’s total workload can be regarded as ‘the project’. Each of the former individual projects
becomes, effectively, a ‘sub-project’ within the new total project.
Terminology varies from one software system to another. For example, some systems refer to the
total workload as the ‘group of projects’, with each separate network called a ‘project’ in the normal
way. In other multi-project systems (and often in this chapter) the term ‘sub-project’ is used to mean
each separate whole project within the total multi-project model.
NETWORK TASK IDENTIFIERS
There is a probability that the same task identifying code numbers will crop up on different sub-project
networks. This will be true particularly if the tasks for each sub-project are numbered in a simple
numeric series.
With some software this can be disastrous. When presented with two or more sub-projects containing
duplicated numbers, the computer sees the whole conglomeration of data as one huge error-laden
network. The confusion and number of errors generated can be imagined, with all sorts of complex
constraints and paths being created across all the sub-projects by mistake. There are several possible
solutions to this problem, which depend largely on the capabilities of the software chosen.
One solution is to ensure that duplicate numbers can never arise between different subnetworks. A
good way to prevent duplication is to prefix all the task ID codes within each sub-project with a unique
string of characters. The length of this string will obviously depend on the number of sub-projects to be
managed, but it is unlikely to be more than two or three characters. Some software can add such prefixes
automatically across all the tasks in a sub-project network. Project numbers, or parts of them, can
provide useful and logical prefixes. It is, however, easy to build up very long task ID codes. These are
best avoided if possible because long numbers increase work and the risk of human errors. Some of the
cheaper systems can only accept ID codes containing perhaps four or six characters in total, which does
not allow much space for a prefix.
Fortunately, most software packages do not demand that every number in the overall multi-project
model is unique. It is only necessary to make certain that every identifier is unique within its own
sub-project critical path network. The vital point then becomes that each sub-project must be given its
own identifying sub-project code.
MANAGING THE MULTI-PROJECT MODEL
The multi-project model can be expected to have a continuous but constantly changing existence. It will
comprise a variable number of sub-projects, each with its own different finite life. At regular or irregular
EBSCO : eBook Academic Collection (EBSCOhost) - printed on 3/1/2018 9:41 PM via STEVENS INST OF TECHNOLOGY
AN: 504684 ; Lock, Dennis.; Project Management
Account: stevens.main.ehost
416
Copyright @ 2012. Gower.
All rights reserved. May not be reproduced in any form without permission from the publisher, except fair uses permitted under U.S. or applicable copyright law.
intervals, new projects must be added, completed projects removed, and progress information or other
changes injected for current projects. Managing such a model can be a formidable (but worthwhile) task.
Even though individual project networks might be of manageable size, perhaps containing only one or
two hundred tasks, the total multi-project model for a medium-sized company can easily contain many
thousands of tasks.
Strict attention to data preparation, system security and updating disciplines must be observed if the
whole model is to be maintained in a useful state. This usually means that access levels to the system
must be carefully controlled, through entry passwords. Certainly the data should be accessible for all
authorized people to view, but only those with the necessary training and skills should be allowed to
enter data or commands that could materially affect the project files and the resulting schedules. Access
that can change the system parameters must be even more jealously guarded. Figure 26.2 shows the
arrangement that I favour for maintaining the integrity of the multi-project model, while still allowing
adequate access for the system users.
The coordination function need not be expensive. It can often be performed by one skilled,
appropriately trained person. Training and hands-on experience must, however, be given to at least one
deputy. In larger organizations the ideal home for administering the multi-project model is the project
support office.
Figure 26.2 Managing a multi-project model
DATA PREPARATION FOR THE MULTI-PROJECT MODEL
Preparation for multi-project scheduling is very similar to that required for single-project scheduling.
Anyone who has mastered the problems associated with single-project resource scheduling will find the
step up into multi-project modelling very easy.
EBSCO : eBook Academic Collection (EBSCOhost) - printed on 3/1/2018 9:41 PM via STEVENS INST OF TECHNOLOGY
AN: 504684 ; Lock, Dennis.; Project Management
Account: stevens.main.ehost
417
A separate network must be drawn for every significant, definable sub-project in the organization.
Estimates for durations, costs and resources are made in the normal way and prepared for input to the
computer. All of this follows the methods explained in previous chapters.
Calendars and holiday files will normally be the same as those used for carrying out single-project
scheduling in the organization.
Copyright @ 2012. Gower.
All rights reserved. May not be reproduced in any form without permission from the publisher, except fair uses permitted under U.S. or applicable copyright law.
Resource definition file
When the resource definition file is established, it will have to be structured for the whole model rather
than for any individual sub-project. This means that the total availability level of each resource will be
the total amount of that resource which is available for allocation to all sub-projects. That, fortunately, is
an easier process than attempting to specify the resource availability for individual sub-projects.
The use of resources on non-project work must be taken into account when the total, multi-project,
schedule is calculated. Such requirements might include the manufacture of customer spares items for
stock, or the setting aside of staff to provide a general enquiry, consultancy or other commitment under a
service contract with a major customer. There are two ways in which this problem can be approached:
1. The total level for each resource in the organization that is declared as being available for projects can
be reduced by an amount equivalent to the miscellaneous work and staff absences, which means using
the ‘sludge factor’ described in Chapter 16.
2. The non-project work can be introduced into the scheduling calculations as if it were one continuous
‘project’. This would require a ‘network’ (which might need only one task) having a duration
spanning not less than the life of the whole multi-project schedule, and carrying the forecast
non-project usage level for each category of resource in the model.
The second of these approaches is over-complicated and less satisfactory, but is likely to be more
accurate if the organization wishes to use the results of multi-project scheduling in corporate manpower
planning (for recruitments or downsizing).
ALLOCATION OF PRIORITIES BETWEEN SUB-PROJECTS
Planners are always able to choose from a number of priority rules for allocating resources to tasks
within each sub-project, just as in single-project scheduling. In the multi-project case, however, there is
a further level of priorities to be decided, namely the allocation of resources between different
sub-projects.
The ideal solution is very simple and it works well. First, it is necessary to specify target start and
completion dates for every sub-project. These dates should clearly be the contractual dates committed
and agreed with the various customers and they should already exist in the filed data. The computer will
carry out time analysis for all sub-projects independently and calculate float from these imposed target
dates. After that, priority claims for scarce resources during multi-project processing can be decided
automatically according to the amount of float possessed by each task.
Senior management, sales managers and individual project managers will undoubtedly have views on
priority differences between all the sub-projects in the model. There are occasions, for example, when
one customer might be regarded as being more important than another. There is then a risk of
interference with the scheduling process, with a desire to force the progress of one or two projects at the
expense of others. If the project planner cannot overcome these undesirable external influences, the
favoured sub-project will have to be given some form of higher priority by artificial means. This can be
achieved by placing an artificially early target completion date on the relevant sub-project.
Some software will allow specific priority levels to be imposed for different sub-projects. The
planner will need to ask the relevant software company how the particular system deals with this aspect.
However, all such artificial allocation of priorities must be resisted wherever possible. When a
EBSCO : eBook Academic Collection (EBSCOhost) - printed on 3/1/2018 9:41 PM via STEVENS INST OF TECHNOLOGY
AN: 504684 ; Lock, Dennis.; Project Management
Account: stevens.main.ehost
418
successful multi-project scheduling operation has been established, it should earn the benefit of
management trust and be left to deal with priorities in its own logical and equitable fashion. Allocation
of resources according only to remaining float is an elegant solution that is easy to apply.
Copyright @ 2012. Gower.
All rights reserved. May not be reproduced in any form without permission from the publisher, except fair uses permitted under U.S. or applicable copyright law.
INTERFACE TASKS (ACTIVITIES) IN MULTI-PROJECT SCHEDULING
There may be a few instances where it is necessary for one or more sub-project networks to share the
same task or have a linking constraint. In such cases the common tasks must bear the same identifier,
and be designated as interface tasks. Interfaces are typically highlighted on network diagrams by
enclosing the task box with a double-ruled border.
The incidence of interfaces in multi-project scheduling should be rare. It is not good practice, for
example, to use them in an attempt to force priorities between different sub-projects (where reliance on
remaining float relative to scheduled target dates is the more sensible option). There are, however,
exceptions. One example is in the allocation of final factory assembly space for large items of plant or
machinery, where one sub-project cannot be assembled until another has cleared the area. Assembly
space for large engineering projects is very difficult, if not impossible, to specify and allocate as a
resource using project management programs because it involves area shapes and can even mean
considering headspace and overhangs. In such cases the sequence in which projects arrive in the
assembly bay will have to be decided by the planners in conjunction with factory management. Then,
these decisions can be forced into the computer schedules by the use of interface tasks or by the
insertion of constraints between sub-projects.
It is safer to create special interface tasks (with zero duration) rather than designate existing tasks
representing real work as interfaces. Two or more common interfaces must be given the same ID
number. Some software will accept interface links but will ignore or corrupt such data as the task
description, duration and resource requirements (because these data are effectively being entered more
than once when two or more subnetworks bearing the interfaces are entered and processed together).
UPDATING INTERVALS FOR MULTI-PROJECT SCHEDULES
The increased amount of stored data, and the far higher probability of frequent changes, mean that
regular updating of the multi-project model will probably be mandatory. Updating in this sense means
the declaration of a new time-now and complete reprocessing of all time analysis, resource schedules
and cost calculations throughout the model. The frequency of updating will depend on the amount of
data and rate of change in the system, but will probably have to be every two or four weeks or calendar
monthly.
ORGANIZATION BREAKDOWN STRUCTURE AND INFORMATION FILTERING
With the increased amount of data stored in the multi-project model, even more careful thought has to
be given to the organization breakdown structure (OBS) as it is arranged within the computer. This is
essential for ensuring that data can be properly filtered to give each departmental manager reports that
contain only information that is personally relevant, interesting and useful to him or her.
Output reports can be filtered for each sub-project (remembering that by ‘sub-project’ I really mean
each full project within the programme of projects). By such filtering, sub-project managers will not be
inconvenienced by receiving data for sub-projects being handled by other project managers in the
organization. This filtering and sorting should also be taken down to the level of departmental or
functional managers within all the sub-projects.
All project managers’ reports should be similar to those that they might expect to receive from a
computer system handling only their own project. Now, however, each manager can have added
confidence that the resources needed to meet the schedule are more likely to be available on time,
because the organization’s total needs have been taken into account.
Tasks which are the joint responsibility of two of more managers
EBSCO : eBook Academic Collection (EBSCOhost) - printed on 3/1/2018 9:41 PM via STEVENS INST OF TECHNOLOGY
AN: 504684 ; Lock, Dennis.; Project Management
Account: stevens.main.ehost
419
Copyright @ 2012. Gower.
All rights reserved. May not be reproduced in any form without permission from the publisher, except fair uses permitted under U.S. or applicable copyright law.
Allocation of departmental codes, working group codes, resource codes and task-level codes can all be
used to facilitate editing and filtering. A difficulty that sometimes arises concerns tasks which cross
boundaries and require resources simultaneously from more than one department. One example is from
an engineering company where prototype manufactured assemblies are subjected to testing that has to be
performed by one department and witnessed by another. How can the system be made to produce a
report containing the same prototype test tasks for each of the two managers concerned without
including non-relevant tasks?
One answer in this particular case is to filter the reports according to the resource codes. Tasks using
two or more resource types would simply appear in the corresponding number of reports. Where tasks
involve two separate departments but use no significant resources, there is a simple trick. Artificial
resources can be created, to allow sorting on their codes. These artificial resources can be given a cost
rate of zero and be stated as being available in numbers that cannot possible constrain resource
scheduling. Software from 4c Systems makes this subterfuge easier, because it allows specified
resources to be deselected for the scheduling process.
PROCESSING TIME
Whereas the schedule for a small project can usually be calculated in a matter of microseconds,
multi-project schedules can take considerably longer. More significant is the time taken to print out
reports. If this process is likely to take more than one or two hours, consideration should be given to
leaving the equipment to perform the operation overnight or at weekends.
WHAT-IF? TESTING
Once a multi-project model has been established it is likely to be viewed as fertile ground in which to
plant trial projects for ‘what-if?’ testing.
When a new project opportunity arises, the planner can create a simple summary network to
represent the new project and inject it into the multi-project model, carry out complete processing, and
report back to senior management on the results. There is no need to draw a detailed network for each
trial sub-project, but there must be sufficient summary tasks on which to load the estimated resources
and to produce an approximate timescale if the organization’s total capacity is to be tested realistically.
Such testing can be invaluable for influencing strategic management decisions.
System security safeguards must be designed when ‘what-if?’ calculations are anticipated. All
‘what-if?’ trials must be carried out on a copy of the main model, not on the working file, so that
working schedules and the database cannot be corrupted. Some software will allow ‘what-if?’ testing to
be performed with adequate safety. Others will use the main model so that, when the ‘what-if?’ test
ends, the planner has to delete the trial sub-project, reprocess the multi-project model and hope that the
database, the schedules and the work-to lists will all be restored to their pre-test state.
A LESS CENTRALIZED MULTI-PROJECT OPTION
Most of the discussion in this chapter assumes that the organization’s project management scheduling
will be carried out centrally by people with special skills and training. In some companies, however, the
preferred method is to rely on individual managers using their own computers, each running relatively
simple and user-friendly software. At one time this approach denied the organization any possibility of
multi-project resource scheduling and reporting.
One approach allows a multi-project database to be set up on a server, but with individual project
managers encouraged to carry out their own scheduling using their accustomed software (usually a
version of Microsoft Project) on network-linked desktops. Innate Management Systems developed
software dedicated to this approach, claiming interface capability with a database at the server and with
other company systems such as accounting, payroll and procurement. Artemis Views is another of the
project management software systems available that can coordinate data from individual managers who
use Microsoft Project.
EBSCO : eBook Academic Collection (EBSCOhost) - printed on 3/1/2018 9:41 PM via STEVENS INST OF TECHNOLOGY
AN: 504684 ; Lock, Dennis.; Project Management
Account: stevens.main.ehost
420
These are interesting developments but, with several users of different planning skill levels entering
project files and progress data, it still needs (perhaps more than ever) one or more experts to oversee the
core functions to prevent corruption of the central model.
Copyright @ 2012. Gower.
All rights reserved. May not be reproduced in any form without permission from the publisher, except fair uses permitted under U.S. or applicable copyright law.
Project Resource Scheduling in the Corporate Context
In any organization, planning has to be carried out at several levels. These range from overall, strategic
corporate long-range plans to the day-to-day allocation of tasks to individual people and machines.
Project scheduling generally lies between these extremes, and can serve several purposes in the general
planning context.
Project schedules (combined with sales forecasts of possible work to come) provide the data from
which manpower, financial and other long-range corporate plans can be formulated. These data are not
needed in great depth of detail. They should instead be summarized in quantities that will suit the broad
corporate plans that they feed. This is the ‘upward looking’ purpose of project schedules, for which they
should predict departmental manpower and facilities needed, the types of skills required, cash flows and
the like. If the organization is a joint venture or other company set up to handle a single large project,
there is one level of planning less for the company to do, because the overall project schedule doubles as
the corporate plan.
The principal ‘downward looking’ purpose of project schedules is to list the jobs that all departments
will have to carry out. These are sometimes known as ‘work-to’ lists. The purpose of these lists is to
feed work to all the departments in correct sequence, timed to fit in with project needs. Effective
resource scheduling, leading to the issue of work-to lists that are sorted and filtered for the attention of
individual managers, should ensure that work is fed to departments at rates that will not cause overloads.
It should then be the job of the departmental managers to arrange the lowest layer of scheduling (the
last of the ‘seven steps of project scheduling’), which is the day-today allocation of jobs to individual
people according to their availability or particular aptitudes.
References and Further Reading
Bartlett, J., (2000), Managing Programmes of Business Change, 3rd edn, Hook (Hampshire), Project Manager Today.
Bradley, G., (2010), Benefit Realisation Management: A Practical Guide to Achieving Benefits Through Change, 2nd edn,
Farnham, Gower.
Kor, R. and Wijnen, G., (2000), 50 Checklists for Project and Programme Managers, Aldershot, Gower.
Loftus, J., (ed), (1999), Project Management of Multiple Projects and Contracts, London, Thomas Telford.
Reiss, G., (1996), Programme Management Demystified: Managing Multiple Projects Successfully, London, Spon.
EBSCO : eBook Academic Collection (EBSCOhost) - printed on 3/1/2018 9:41 PM via STEVENS INST OF TECHNOLOGY
AN: 504684 ; Lock, Dennis.; Project Management
Account: stevens.main.ehost
421
Copyright @ 2012. Gower.
All rights reserved. May not be reproduced in any form without permission from the publisher, except fair uses permitted under U.S. or applicable copyright law.
27 Implementing Business Change Projects
This chapter is extracted from the final chapters of Fowler and Lock (2006). It is based on the ‘4D
technology’ of Isochron Ltd, an Edinburgh company of which Alan Fowler is chairman. I am indebted
to Alan and to Isochron for permission to make and use this adaptation.
Introduction
Construction and other industrial projects change physical things. A very important characteristic of
business change projects is that their success in delivering the intended outcomes depends far more on
people accepting change. At the very least that change involves people using new technology and
processes. Often the change in people’s lives is far greater. New and unfamiliar posts may be created
and people promoted, moved or demoted to fill them. New procedures and routines have to be learned
and followed. Sometimes the deep structure of the organization has to change and with it the culture, so
that beliefs, attitudes and behaviours have to alter. Myths and stories may have to be rooted out. Habits
and beliefs of a working lifetime that have brought status, security and mental comfort might have to be
discarded. This chapter is about how to make these people-centred changes happen.
RECOGNITION EVENTS AND VALUE FLASHPOINTS
Among the many buzzwords associated with management projects (and with many other projects) is
‘benefits realization’. Using different jargon, this means ‘achieving the project deliverables’. But for the
individuals affected by change in their organization these concepts can go over their heads because they
do not necessarily describe the change that will be brought about in their personal lives. An important
feature of the Isochron method for implementing change projects successfully is the use of ‘recognition
events’ and ‘value flashpoints’. So it is necessary to define both these terms before continuing with this
chapter.
A recognition event, as used by Isochron, is a planned event in a project that will signal to a project
sponsor and other stakeholders when one particular expectation of the project has been met. It is thus a
kind of milestone but it does not have to be associated with any quantitative achievement. So a
recognition event might signal the end of a particular project phase or the beginning of another, but it
does not have to be associated with any financial benefit resulting from the project.
A value flashpoint is also a predicted recognition event or milestone, but it will occur when a
particular project cash benefit becomes apparent. For example, ‘The Quarterly Report for 30 June 2016
will show the reduction in servicing costs caused by replacing the old equipment.’
FUNDAMENTAL NATURE OF ORGANIZATIONAL CHANGES
One of the fastest and easiest ways to start to make changes in the business is to change the organization
– that is to say change who does what. The result should be evident in the new organigram. The function
of each post is implied in the job title and further defined in the job description. A good organigram will
show the principal lines of authority and responsibility in its tree structure.
Consider the impact of creating a new post and appointing or recruiting a person to fill it. It’s a bit
like installing a new machine tool in a production line. All of a sudden, procedures are being carried out
that were not done before. The whole sequence of production will change and the results will alter
accordingly. Staying with the production analogy, removing one machine tool from a plant will throw
load on to other parts of the manufacturing facility. Similarly, making a post redundant will not, by
EBSCO : eBook Academic Collection (EBSCOhost) - printed on 3/1/2018 9:41 PM via STEVENS INST OF TECHNOLOGY
AN: 504684 ; Lock, Dennis.; Project Management
Account: stevens.main.ehost
422