SBL

Project Management

A strategic plan (typically long term and corporate-wide) can never be implemented as a
single, monolithic task. A strategy of expanding abroad, for example, would consist of a series
of smaller tasks such as finding premises, recruiting, training, equipping the factory, marketing,
and establishing a distribution network. Each of these smaller tasks can be regarded as a
project, with a start, end, objectives, deadline, budget, and required deliverables. Realising a
strategic plan therefore depends on carrying out a complex jigsaw of projects, and if one piece
goes missing the whole strategic plan will be in jeopardy. Therefore, successful project
management is at the heart of successful strategic planning.

A project is an activity that:

- is temporary having a start and end date
- is unique
- brings about change
- has unknown elements, which therefore create risk

A project is a temporary undertaking performed to produce a unique product, service, or

result. Large or small, a project always has the following three components:
 Specific scope: Desired results or products; closely linked to quality as well.
 Schedule: Established dates when project work starts and ends
 esources allocated specifically to the project although often on a shared basis: Necessary
number of people and funds and other resources (money, facilities, supplies, servies).

Each component affects the other two! For example:

Expanding the type and characteristics of desired outcomes may require more time (a later
end date) or more resources. Moving up the end date may necessitate paring down the results
or increasing project expenditures (for instance, by paying overtime to project staff)

Project management can be a core strategic competence for some industries

(like consulting and construction). Projects are generally considered

successful if they meet the triple constraint; scope, time cost.

WHY DO PROJECTS FAIL?
1. Poor project and program management discipline
2. Lack of executive-level support
3. Wrong team members
4. Poor communication
5. No measures for evaluating the success of the project
6. No risk management
7. Inability to manage change

Page 134
THE PROJECT LIFECYCLE

All projects will start from an initial idea, perhaps embedded in the strategic plan. A
project will then progress to the initiation stage when a project manager will be
appointed. The project manager will choose a project team and they will carry out a
feasibility study. The feasibility study is necessary to establish the following:
- Commercial feasibility – will the likely benefits exceed the cost?
- Technical feasibility – do we think this project has a good chance of working? Operational
feasibility – will it help the organisation reach its objectives?
- Social feasibility – will our employees, customers and other stakeholders tolerate it?

A feasibility report should be produced and this will have to be studied by senior
managers, because if the project goes ahead substantial expenditure might be required.

Note that the feasibility report does not merely have to present management with simple
‘yes’ or ‘no’ options, but can set out a range of options, each with particular benefits, costs
and time frames. Where there is some doubt as to the potential benefits that will arise
from the project, it is particularly valuable to offer a range of choices which allow the
organisation to first try out a modest project and later allow the project to be extended.
This approach is a useful way to reduce risk. If you are not sure about something, start in a
small way and extend later if worthwhile.

Successful organizations create projects that produce desired results in established time
frames with assigned resources.

Every project, whether large or small, passes through the following four stages:
 Starting the project: This stage involves generating, evaluating, and framing the business
need for the project and the general approach to performing it and agreeing to prepare a
detailed project plan. Outputs from this stage may include approval to proceed to the
next stage, documentation of the need for the project and rough estimates of time and
resources to perform it (often included in a project charter), and an initial list of people
who may be interested in, involved with, or affected by the project.

 Organizing and preparing: This stage involves developing a plan that specifies the
desired results; the work to do; the time, the cost, and other resources required; and a
plan for how to address key project risks. Outputs from this stage may include a project
plan documenting the intended project results and the time, resources, and supporting
processes to help create them.
 Carrying out the work: This stage involves establishing the project team and the project
support systems, performing the planned work, and monitoring and controlling
performance to ensure adherence to the current plan. Outputs from this stage may include
project results, project progress reports, and other communications.

 Closing the project: This stage involves assessing the project results, obtaining customer
approvals, transitioning project team members to new assignments, closing financial
accounts, and conducting a postproject evaluation. Outputs from this stage may include
final, accepted and approved project results and recommendations and suggestions for
applying lessons learned from this project to similar efforts in the future.
Project initiation

All projects begin with an idea. Perhaps the organization’s client identifies a need; or maybe
the management thinks of a new market to explore; or maybe the management thinks of a
way to refine the organization’s procurement process.

Sometimes the initiating process is informal. For a small project, it may consist of just a
discussion and a verbal agreement. In other
instances, especially for larger projects, a project requires a formal review and decision by
organization’s senior management team.

Decision makers consider the following two questions when deciding whether to move
ahead with a project:
 Should we do it? Are the benefits we expect to achieve worth the costs we’ll have to
pay? Are there better ways to approach the issue?
 Can we do it? Is the project technically feasible? Are the required resources available?

Project selection: As organizations have limited resources, they should assess suitability,
acceptability and feasibility of projects before they choose one to proceed with.

Pre-initiating tasks:
- Project objectives and constraints are determined ( i.e. set scope, identify time and cost
constraints)
- Select project manager ( who takes responsibility that desired results are achieved on
time and within budget);
- Identify project sponsor ( who provides and is accountable for the resources invested
in the project; will NOT be involved in the management of the project normally; the
project sponsor ( say the senior management) may appoint a project owner to review
project plans and progress at regular intervals)

Initiating tasks:

Preparation of a business case document ( why the project is needed, what it will
achieve and how it will proceed)

Explains the need for work on the

project to start. Typical contents:

1. Description of current information/issues ( problems to be solved)
2. Cost benefit analysis(including intangible costs and benefits), any assumptions
undertaken
3. Impact on organization other than cost ( changes in org structure for example)
4. Key risks and actions to mitigate them
5. Recommendations

Project costs and benefits ( part of the business case document)

Within the business case document, benefits should be mentioned before the costs!
A benefit-cost analysis is a comparative assessment of all the benefits anticipated from the
project and all the costs to introduce the project, perform it, and support the changes
resulting from it.

Some anticipated benefits can be expressed in monetary equivalents (such as reduced

operating costs or increased revenue). For other benefits, numerical measures can
approximate some, but not all, aspects. If the project is to improve staff morale, for example,
you may consider associated benefits to include reduced turnover, increased productivity,
fewer absences, and fewer formal grievances. Whenever possible, express benefits and costs
in monetary terms to facilitate the assessment of a project’s net value

Identifying the costs ( capital

and operating ) Consider costs
for all phases of the project.

Page 136
Such costs may be nonrecurring (such as labor, capital investment, and certain operations and
services) or recurring (such as changes in personnel, supplies, and materials or maintenance
and repair). In addition, consider the following:
 Potential costs of not doing the project
 Potential costs if the project fails
 Opportunity costs (in other words, the potential benefits if you had spent your funds

successfully performing a different project) Cost-benefit evaluation

One the costs and benefits have been quantified, an investment appraisal can be undertaken
using techniques like
- Accounting rate of return
- Payback period
- Net present value
- Internal rate of return

Project initiation document/project charter

Give authorization for work to be done and

resources to be used. Complements the business

case document
Can be used for internal communication to keep staff informed of what is happening

One of the main outputs of the initiation stage should be the project initiation document,
or PID. The term is poor because it implies that the PID is used only at the start of a project,
when the project is being proposed, and ‘document’ might suggest a couple of pages only. In
fact, the PID is of key importance both initially and throughout the duration of the project

Typical contents: It should address the following questions:

- What should the project achieve? What are its deliverables? These should be specified in
detail so that the project and its scope are well defined from the outset.
- Why is the project is needed (including a cost benefit analysis)? How will the quality or
acceptability of outputs be assessed?
- Who will lead the project?
- Who will be on the project team and what will be the role and responsibility of each
 team member? What are the risks? How have they been assessed and prioritised, and
how will they be managed?
- Who will carry out the work on the project? Which actions will be assigned to in-house
staff and which to sub- contractors?
- By when should the project and its various stages be completed? What are the
constraints on the project?
- What are the assumptions on which the project depends? How much budget has been
allocated to the project?
- What other resources are needed by the project, and have been allocated to it?
- Who sponsors or owns the project? (generally the department or client who is paying)
What are the reporting arrangements?

As this shows, the PID is the key reference document and it will be extensive and detailed,
containing all the planning information required about the project.
WHAT DETERMINES RISK?

Project risk can be said to depend on three variables:

1. How well defined is the project? A well-defined project will set out in detail exactly
what the project is to accomplish (the deliverables), when each stage should be
completed, and how each stage will be appraised (quality). These qualities can be
summed up in the phrase ‘project scope’. Additionally, it is important to set a cost
budget in advance. We will see later that there can be tensions between cost, time,
quality and scope, but if these have not been defined in the first place, the project will
run into difficulties quickly as each member of the project team is likely to be pursuing
different goals. A poorly defined project will be short on detail but long on grand
ambition. For example, stating that the new IT system will improve inventory
management is almost useless. Is the firm moving to just-in-time? Is it going to develop
sophisticated demand-forecasting algorithms? Is the warehouse to be automated? Will
labour and machine use be part of the system? In addition, if the project is not well
defined, even if most participants happen to have a similar vision initially, the project
will be susceptible to drift. This means that as the project progresses, ideas change and
the project deliverables change. To some extent, project drift is inevitable because as the
project is worked on, more information is discovered and it would be foolish not to
take note and alter the project where necessary. However, altering projects part way
through is usually expensive in terms of time and money if work has to be redone or
abandoned. What must be avoided is ongoing, ‘nice-to-have’ project drift, in which new
features are added little by little without proper evaluation of costs and benefits. By
defining the project in detail at the start, the firm will have thought carefully about
deliverables and the need for subsequent amendments should be minimised.
2. The size of the project. It is pretty obvious that there will be more risk associated
with large projects. More stakeholders will be involved, possibly including customers and
suppliers. There will be more coordination problems and the financial investment will be
greater. Project failure, will cause great disruption and many people will be affected. By
contrast, small projects will be easier to control and if they go wrong, damage is likely to
be confined to a smaller number of stakeholders.
3. The technical sophistication of the project. A project which depends on well understood
solutions is much less likely to go wrong than a project which is attempting to use cutting
edge, experimental technology.

So, if you are put in charge of a large, poorly defined, sophisticated project, you might like
to look round for another job, as if the project fails to deliver (and it probably will) you
could be the number one scapegoat.
Of course, there can be a good business case for embarking on large sophisticated projects,
as these can allow companies to differentiate their products and services. If standard,
hesitant, safe solutions are always used then more ordinary performance will result. It might
be part of a business’s strategy to adopt radical solutions to gain competitive advantage.
However, there can never be any excuse for a project being ill defined at the start.

Risks must be managed and the following approach can be used:

- Define the risks. What could go wrong?
- Assess the risks. This will be a combination of estimating the financial effect if the risk event
occurs, and the probability of the risk occurring. Some risks would have large financial
consequences but could be very unlikely to happen. Others might have trivial financial
consequences.
- Prioritise the risks. What are the really serious events that need to be addressed first?
- Deal with the risks. Generally, there are four approaches:

1. Tolerate the risk, either because the event is unlikely to happen and/or the consequences
will be immaterial.
2. Treat the risk, or do something to ameliorate it. For example, if the consequences of missing
a deadline are serious, have additional resources available that can be used to speed up
the process if necessary.
3. Transfer the risk. Insurance is a form of risk transfer, as is sub-contracting. So if you are
worried about an IT project missing important deliverables, consider sub-contracting
part of it and build in penalty clauses.
4. Terminate the risk. In other words, the event would be so serious that you do not want to
risk it occurring at all. For example, if
there were a security breach during a project that requires sensitive data to be held,
this could be devastating to a company, so the company might decide not to hold that
data, despite it possibly yielding good marketing information.

Page 138
Project planning

Include the following in the project-management plan:

 An overview of the reasons for your project
 A detailed description of intended results
 A list of all constraints the project must address
 A list of all assumptions related to the project
 A list of all required work
 A breakdown of the roles you and your team members will play
 A detailed project schedule
 Needs for personnel, funds, and non-personnel resources (such as equipment, facilities,
and information)
 A description of how you plan to manage any significant risks and uncer- tainties
 Plans for project communications
 Plans for ensuring project quality

PROJECT PLANNING AND MANAGEMENT TOOLS

Typically, projects consist of a number of separately identifiable steps which can be broken
down, hierarchically, until manageable work packages are produced which can be assigned to
the appropriate people. This is the process of deriving the work breakdown structure for the
project. Each work package, or task, will have four components:
- task name and description
- costs, both marginal and any fixed element
- duration
- who is responsible and, in particular, whether the work will be carried out internally
or externally.

So now the project manager knows who is doing what and how much each element should
cost. Using a relatively simple cost accounting system, material, labour, overheads and third
party costs can be coded to the work packages, hence to the project, and actual costs can be
compared to budget for control purposes.

Still to be taken into account is the time that each work package will take, but whereas
costs are cumulative, times need not be as often several tasks can be undertaken
simultaneously. A more sophisticated approach is needed which sets out the relationship of the
tasks or activities to one another, identifying those tasks which can be concurrent and
those which can only be consecutive. For example, if the project was to set up a new
website for the company, the task of choosing the internet service provider to host the
website can be undertaken at the same time as designing the graphics and layout of the web
pages. However, the layout and graphics couldn’t be finalised before the company has decided
what information the web pages should show. These three tasks could be set out in a network
diagram, or critical path analysis

Network diagram / Critical path analysis

The numbers represent the time that each activity takes (let’s say in days). The project cannot
proceed further until both content and layout have been decided. These are consecutive steps,
one taking eight days and the next five days, so this small part of the project cannot be
accomplished in less than 13 days. It does not matter that it takes only nine days to choose
the ISP: everything has to wait for the content and design activities to be completed. These
are critical activities, and if either were to take another day, completion of the whole
project would be delayed by a day.

Therefore, the project manager has to monitor critical activities very carefully. Choosing the
ISP is a non- critical activity and it could be delayed by up to four days before impacting on
project completion.

Once project slippage is likely, the project manager has a number of choices, all of which should
be discussed and perhaps negotiated with the project sponsor:
- live with the slippage
- reduce project scope
- reduce project quality
- bring in more resources, such as hiring sub-contractors to help out (which will, of course,
increase costs)
- move resources from non-critical to critical activities if skills are interchangeable.

Even small projects can be broken down into many tasks, each with its own definition,
personnel assigned, costs, start time, finish time and defined relationships with other tasks.
Controlling this manually can be very arduous and project management software can be very
useful in tracking each activity and, therefore, the progress of the project as a whole.

Work breakdown structure

The Work Breakdown Structure (WBS) is a grouping of the work involved in a project
oriented towards the deliverables that defines the total scope of the project. The WBS can be
imagined as a roadmap of the project which breaks down the total work required for the
project into separate tasks and helps group them into a logical hierarchy (see example
below)Different levels of detail assure the project managers that all products and work tasks
are identified in order to integrate the project with the current organisation and to
establish a basis for control. Furthermore, the WBS organizes and divides the work into
logical parts based on how the work will be performed. This is important as usually a lot
of people are involved in a project and many different deliverables are set to reach one
main objective to fulfill the project.

In addition tothis, the WBS serves as a framework for tracking cost and work performance
because every element which is defined and described in it can be estimated with reference
to its costs and time needed. Consequently, the WBS enables the project managers to make
a solid estimation of costs, time, and technical performance at all levels in the organisation
through all phases of the project life-cycle.

Page 140
Project execution and control
After the project-management plan has been developed, it’s time to get to
work and start executing the plan. This is often the phase when
management gets more engaged and excited to see things being produced.

Preparing
Preparing to begin the project work involves the following tasks
 Assigning people to all project roles: Confirm the individuals who’ll perform the project
work, and negotiate agreements with them and their managers to assure they’ll be
available to work on the project team.
 Introducing team members to each other and to the project: Help people begin
developing interpersonal relationships with each other.

Help them appreciate the overall purpose of the project and how the different parts will
interact and support each other.

 Giving and explaining tasks to all team members: Describe to all team members what
work they’re responsible for producing and how the team members will coordinate their
efforts.
 Defining how the team will perform its essential functions: Decide how the team will
handle routine communications, make different project decisions, and resolve conflicts.
Develop any procedures that may be required to guide performance of these functions.
 Setting up necessary tracking systems: Decide which system(s) and accounts you’ll use
 to track schedules, work effort, and expenditures, and set them up.
 Announcing the project to the organization: Let the project audiences know that your
project exists, what it will produce, and when it will begin and end.
Performing
Finally, project work begin! The performing subgroup of the executing processes includes
the following tasks
 Doing the tasks: Perform the work that’s in your plan.
 Assuring quality: Continually confirm that work and results conform to requirements and
applicable standards and guidelines.
 Managing the team: Assign tasks, review results, and resolve problems.
 Developing the team: Provide needed training and mentoring to improve team
members’ skills.
 Sharing information: Distribute information to appropriate project audiences.
The monitoring and controlling processes

As the project progresses, it needs to be ensured that plans are being followed and desired
results are being achieved. The monitoring and controlling processes include the following
tasks:
 Comparing performance with plans: Collect information on outcomes, schedule
achievements, and resource expenditures; identify deviations from your plan; and
develop corrective actions.
 Fixing problems that arise: Change tasks, schedules, or resources to bring project
performance back on track with the existing plan, or negotiate agreed-upon changes to
the plan itself.
 Keeping everyone informed: Tell project audiences about the team’s achievements,
project problems, and necessary revisions to the established plan.

Project slippage: when a project is running behind schedule.

Project completion

Finishing the assigned tasks is only a part of bringing

the project to a close. In addition, the following
must be done:
 Get approvals of the final results.
 Close all project accounts
 Help team member’s move on to their next assignments.

Hold a post-project review with the project team to recognize project achievements and to
discuss lessons can be applied to the next project.

This happens at the end of the project and allows the project team to move on to other
projects. It can often be the last stage of the project, with the review culminating in the
sign-off of the project and the formal dissolution of the project team. The focus of the po
st-project review is on the conduct of the
project itself, not the product it has delivered. The aim is to identify
and understand what went well and what went badly in the project and to feed lessons
learned back into the project management standards with the aim of improving subsequent
project management in t he organisation.
Post implementation review: A post implementation
review focuses on the product delivered by the project. It usually
takes place a specified time after the product has been delivered. This allows the actual users
of t he product an opportunity to use and experience the product or service and to
feedback their observations into a formal review. The post-implementation review will
focus on the product’s fitness for purpose. The review will not only discuss strategies for
fixing or a ddressing identified faults, but it will also make recommendations on how to
avoid these faults in the future. In this instance these le ssons learned are fed back into the
product production process. Without a PIR, a business cannot demonstrate that its investment
in the project was worthwhile.

PIRs can sometimes be an on-going element of project management that may be used at project
gateways to examine changes impl emented to date.

Page 142
Project manager
You will see from the contents of the PID that there are a number of classes of stakeholder in
projects, typically:
- The sponsor
- The project team
- Other employees, sub-contractors and regulatory authorities, such as health and safety
inspectors.

Funds from the sponsor flow through the project team and on to other departments and
sub-contractors. In return, project deliverables should flow back towards the sponsor.

The project team will often be multi-disciplinary and it will be led by a project manager. The
project manager is enormously influential as to whether or not the project ends in success,
and he or she must combine technical knowledge, leadership ability, and project
management skills.

Relationships between project manager and stakeholders

The tasks of the project manager can be summarised as:

- Ensuring that the PID is comprehensive. This can be a complex task because it will mean
ensuring that deliverables, budget, resources, project team, deadlines and so on have been
determined. As was emphasised earlier, there is no point embarking on a semi-defined
project, so the project manager should be strong enough to resist management pressure to
be seen to be doing something. If the project is started before the PID is complete, things
will be done but they will probably be the wrong things.
- Communication with the sponsors. Even when projects run smoothly, sponsors will expect
updates on progress. Often, however, even in well planned projects, problems will be
encountered and it is then that communication with the sponsors is particularly
important. This will keep the sponsors informed but will also give the sponsors
 opportunities to make choices, for example to spend more or to cut back on
deliverables.
- Team leading. The project team is likely to consist of people from a number of
departments with different skills and priorities.
The project manager should be capable of creating a cohesive, well-motivated team where
participants work well together.
- Communication with sub-contractors and regulatory authorities.
- Technical appreciation of project issues. For example, someone running a construction
project will need to understand relevant technical issues when these are raised in
meetings.
- Organisational ability, including the ability to delegate tasks.
- Technical competence in project management. For example, an understanding of critical
path analysis (to monitor and control progress through time), and cost reports to
monitor and control expenditure.
- An ability to balance project cost, time, scope, and quality. All projects have targets
relating to cost, time, scope, and quality; these should be defined in the PID. However,
certain priorities or pressures are likely to apply to each variable, depending on the nature
of the project. For example, a project involving safety- critical systems will rightly put great
emphasis on quality because the consequence of technical failure will be very serious.
However, managers need to be aware of the impact of the following compromises:
  Increased emphasis on quality places the project in danger of taking longer and costing
more.
 Increased emphasis on meeting the cost budget may compromise quality, the project may
take longer, or the scope could be narrowed.
 Increased emphasis on meeting time deadlines may also compromise quality, cost over-
runs are more likely (perhaps because overtime has to be paid), or scope could be
narrowed.
 If the emphasis is to ensure that the project scope is not reduced, then cost and time
might increase, and quality might decrease. Naturally, if scope is increased, whether
through project drift or through more pre-meditated changes to the project, costs, time
and quality will all be severely jeopardised.

None of these compromises is bound to happen, but project managers should be aware that such
tensions exist and that a balance has to be maintained by management action, if necessary
negotiating with the project sponsors to gain approval for changes.

Project sponsor
The project sponsor or project facilitator will normally be a senior member of the
management team.
They are often chosen as the person with the most to gain from the success of the project

and the most to lose from the failure of it. Their job is to direct the project, and allow the

project manager to manage the project.

The roles taken on by project sponsors in organisations include:

- gatekeeper – choosing the right projects for the business means ensuring that only projects
that support the business strategy a re started and that they are of sufficiently high
priority and have clear terms of reference
- sponsor and monitor – steering the project by requesting regular meetings with the project
leader and giving advice and guidan ce
- supporter and coach – provides practical support for the project leader, especially if
they are taking on a project that is larger or more significant than they have handled
before
- decision-maker – if decisions are required that are outside the scope of the project then
the project sponsor will make the decis ion on behalf of the organization
- champion or advocate – involves informal communication with other senior managers
to ensure that they continue to have an objective view of the importance of their
 project in relation to other projects within the business
- problem solver – when the team faces problems that it is unable to solve or does not have
the skills or experience to solve
- Resource negotiator – a project’s success will depend on the availability of the right
resources at the right time. In cross-fun ctional projects the sponsor may provide
assistance in negotiating resources around the company
Project risk management
Project risks have been described earlier. The project manager is
responsible for monitoring risks. A record should be kept of the
significant project risks that have been identified, and the
measures that have been taken to reduce or control them.

Risk register
A risk register can be used as a record of identified risks and control
action.
A risk register lists all significant identified risks and the results
the evaluation of the risks by the project team. Information on the
current status of the risk is also recorded. The risk register should
be continuously updated and reviewed throughout the course of a
project.
A risk register should contain the following information:
 Category of risk
 Individual who identified the risk
 Date the risk was identified
 Date the register was most recently updated for this risk
 Description of the risk
 Probability that an adverse event will occur
 Expected impact if an adverse event does occur
 Measures taken to deal with the risk
 Current status of the risk/control measures.

Requests for changes

With large projects that take a long time to complete, it is common
for the project sponsor to ask for changes to the project
specifications. Changes might arise because:
 the project sponsor realises that the original project
specifications were incorrect, and wants to change them so that
they specify requirements correctly
 there might be changes in the business environment that alter
the strategic situation, and the project sponsor’s requirements
are changed by these developments
 the project sponsor keeps thinking of extra requirements that
would be ‘useful’ or ‘desirable’. This is a form of ‘scope creep’.
The project manager must react to requests for changes in an
appropriate way.
 The first step should be to consider the changes that have been
requested, and decide whether they are feasible.
 If the requested changes are feasible, an estimate should be
made of the effect on time to completion of the project and the
project’s cost. The project sponsor should be informed about the
expected effects of cost and completion time.

 The project sponsor should be asked to agree to the delay to

completion and the additional cost. The project sponsor might
be reluctant to agree.
 The request for the change should be documented. ‘Unofficial’ or
‘uncontrolled’ changes to specifications should be avoided,
because the individual or group responsible for changing the
specifications should be formally identified. This individual or
group should then be responsible for the consequences of the
changed specification (for example, for any delay or extra cost,
or reduction in process/system quality).
 The new project specification should be analysed, and
amendments should be made to the project design, scheduling,
budget, resource requirements, and so on.

Project completion
There should be formal procedures for the conclusion of a project.
On completion of a project, the ‘end result’ is handed over to the
project sponsor or project client for implementation. The ‘end
result’ might be a new process or a new IS/IT system.
 The procedures in project completion should include the following:
 Acceptance testing by the project ‘client’. Before a new
process is implemented or a new IS/IT system is introduced,
thorough tests should be carried out to ensure that the
outputs from the project meet:
- the project specifications and
- the requirements of the project client.
At this stage, the project client might identify problems with
using the new process or system, and changes might be
requested at this late stage to improve the process quality or
system performance.
 On successful completion of acceptance testing, the process or
system is handed over to the project client for implementation.
The project manager might prepare a project completion report
for the project sponsor.
 The project team is disbanded.
 There should be a post-completion audit of the new process or
system, sometime after its implementation.
A completion report is often produced to summarise the results
of the project and includes sign-off from the client, sponsor and
project manager. The report might be circulated in an initial draft
format in order to invite feedback before a final report is
circulated.

Post-completion audit (post-implementation review)

The purpose of a post-completion audit of a new process or system
is to assess the success (or failure) of the project in meeting its
intended objectives.

The audit or review should be carried out by a person or a team

that is considered ‘independent’. Members of the project team and
the project client should not be the auditors.

The review should assess the project in terms of:

 whether the objectives of the project have been achieved, and
the re-designed process or new system has achieved the
expected benefits, and
 in terms of quality, time and cost.
Review of the benefits achieved from the project
Projects are usually undertaken to introduce changes into an
organisation, and the purpose of a project is therefore to
implement business strategy. If the project has failed to achieve
the benefits that were expected, the implications for the entity’s
business strategy should be assessed. A failure in one project to
achieve the expected benefits could mean that the business
strategy must be reviewed, and new initiatives must be
considered.

The assessments from the post-completion audit of projects

should be included within the next general strategic review and
position analysis.

Review of cost, time and quality

A post-completion audit should also review the cost of the project,
the time it took to complete and the quality of the output from the
project – the new process or system.

For example, a post-completion audit of a new IS/IT system should

assess:
 whether the project client is satisfied with the new process or
system
 whether the system is easy to use or the new process is trouble-
free
 the problems that have occurred with the implementation of
the process or system, why they happened and whether they
have been resolved
 the ability of the process or system to handle the actual volume
of transactions, and whether it will be able to handle the
expected growth in transaction volume.

The post-completion audit might find that lessons can be learned

for the future, so that mistakes that were made with the project
are not made again with future projects.
Metrics for post-completion review
The assessment of a project in a post-completion review should
ideally be based on quantified measures of performance or
achievement (‘metrics’). Actual measured performance should be
compared against targets or objectives that were established in the
feasibility study for the project.

For example, the feasibility study should include specific measures

for the expected benefits from the project, and the expected costs
of developing the project and operating the new system or process.
The actual benefits and costs should be assessed in the post-audit,
and compared with the expected benefits and costs.

Quantified measurements of performance should help

management to assess whether the financial objectives of the
project have been achieved, as well as the strategic objectives.

Benefits management
Businesses enter into projects to achieve benefits. However, many
projects fail to achieve their objectives. Studies show that over
70% of business improvement projects fail to deliver their
expected benefits, and even when they are achieved in part, often
they are far from fully realised.
There are many reasons for this but often it is due to one of the
following:
 Business cases focused on target savings instead of expressing
business benefits in a manner that can be understood and
implemented.
 Too much emphasis on deliverables, or outcomes (e.g.
capabilities) which on their own do not deliver specific benefits.
 No mechanisms or in particular structures to manage their
realisation.
Benefits Management aims to make sure that desired business
change or policy outcomes have been clearly defined and
measurable with the ultimate aim of ensuring that the benefits are
actually achieved.
It is the definition, planning, structuring and actual realisation of
the benefits of a business change or business improvement project.
Benefits Management is a process that starts prior to project
 initiation and continues until the planned benefits are delivered to
the organisation and/or its stakeholders.

Common problem
Benefits are often realised after the end of a project yet the
projects are often considered to be finished when their
deliverables are complete. This might mean that there is no one
responsible during the realisation phase and thought given to
management of this important outcome.

Process
Benefits must be identified clearly in the project and be linked to
business objectives. Individual managers must be given
“ownership” of the benefits and be made responsible for planning
and managing their achievement.
A central aim of the process is to bring structure, accountability,
clarity and discipline to the definition and delivery of the benefits
inherent in a project.
Benefits management is a key aspect of programme management
and must start in the earliest stages of the project. Effective
realisation planning enables organisations to understand and
maximise the potential benefits that might be achieved by the
project. The plan must identify and address the changes that will
be required, including any resistance that may be encountered.
These changes themselves may need to be managed carefully as
part of a change management programme.
Potential benefits should not be identified as a simple list. It is
important to identify interrelationships and to understand where
the achievement of one benefit is dependent on the realisation of
another.

Once they have been identified, analysed and structured, the next
task is to create a realisation plan. This should enable the
organisation to identify the management actions required to
support and execute that plan.

Benefits Focused Business Cases

A business case should set out the basis of an investment or change.
Business cases must demonstrate the return or value that the
 organisation will achieve by the proposition in the business case.
Business cases must demonstrate how the value or return will be
delivered, by identifying specific benefits that will be accrued from
the project. This is often very different from making summary
statements about planned or targeted financial savings that will be
achieved.

Delivering Strategic Goals and Objectives

Most organisations have current strategic goals and objectives.
These should be embedded throughout benefits identification and
planning. The business case must be evaluated thoroughly to
ensure that it is focused on achievement of strategic goals.
The realisation plan will provide a control mechanism to provide
continual feedback against strategic goals.
Many of the anticipated benefits will not start to materialise until
after the project has been delivered. It is therefore essential that
the ownership of the benefits realisation plan is maintained
beyond project delivery through to complete realisation.
The process should also include a post implementation review,
thereby allowing time for analysis and a proper evaluation against
the original business case.
It should be evident from the above that benefit management is
not the same as project management. Project management is often
focussed on achieving the project deliverables. Benefit
management is more concerned with why the deliverables were
instigated in the first place (i.e. to achieve benefits). A project that
meets its deliverable targets but does not result in benefits is a
failure. Benefits management tries to ensure that this does not
happen.

Project gateways
A project should follow a defined process, from initiation to
conclusion.
Project gateways are a project monitoring mechanism and may be
used with benefit management. Gateways are decision points
incorporated strategically within the project lifecycle. Their
purpose is to ensure that key processes have been followed and to
enable the decision makers to decide whether the project should
continue or not.
At each gateway, project progress is appraised. If the project is
proceeding as planned it will continue. If there are problems of
some kind the project will be referred to someone (the
gatekeeper) who will decide on corrective action (which might
involve abandoning the project).