J. Software Engineering & Applications, 2010, 3, 839-844
doi:10.4236/jsea.2010.39097 Published Online September 2010 (http://www.SciRP.org/journal/jsea)
839
Benefits Management Process Complements Other
Project Management Methodologies
Ioannis Karamitsos1, Charalampos Apostolopoulos2, Moteb Al Bugami3
1Telecom Lab, On Telecoms, Athens, Greece; 2Strategic Business Development Division, IB PRAXIS, London, UK; 3Department of
Management Inform a ti o n Systems, King Abdulaziz University, Jeddah, Saudi Arabia.
ABSTRACT
The benefits managemen t approach complemen ts most of the common project ma nagement methodologies such a s crit-
ical chain project management (CCPM), and PRINCE2. The majority of these methodologies focus on how to comply
with three parameters: time, cost an d quality instead of identifying th e positive outcomes and benefits for an organiza-
tion. In this paper, a different approach for the organization is presented , which focuses on positive outcomes named as
benefits. Moreover, a comparison between Benefits Management and PRINCE2 methodologies is illustra ted.
Keywords: Benefits Management, PRINCE2, Requirements Analysis
1. Introduction
One of the fundamental reasons for project improvement
is to realize benefits through change. Change can be proven
the main key driver to put things back on track, try to
minimize project risks and consequently avoid project
failure. Managing change can result in different outcomes
and desired outcomes can be quantified as benefits.
The benefits management approach can be character-
ised as complementary to common project management
methodologies. It can be proven useful for business pro-
jects and programmes so as to deliver benefits. However,
project management methodologies are frequently criti-
cised for failing to achieve their objectives, being rather
complicated and trivial. More specifically, Standish Group,
Chaos report [1] showed that around 70% of business
projects fail. This failure is mainly related to lacking of
delivering the expected outcomes; being to some degree
poor in requirement analysis of the project aims, objec-
tives and consequently goals and/or benefits.
There are several reasons that a project is subject to
fail, for example:
 Lack of clear directives on how to carry out the ac-
tivities for the initialisation of the project, and how
to develop the business case for the investment.
 During the project implementation too much focus
is given on tracking progress towards the achieve-
ment of each deliverables or outcomes instead of
benefits realisation.
 Projects information/knowledge between stakehol-
ders and IS/IT specialists is achieved within meet-
ings or face-to-face discussions rather than effec-
tive workshops which clearly state the aims, objec-
tives goals and overall strategic activities planning.
However, Apostolopoulos and Karamitsos [2], ex-
plained project failure reasoning in terms of behavioural
perspectives. More precisely, the lacking of efficient com-
munication may be a result of different individual and
environmental approaches of a project. In other words,
the client’s inputs are rooted from an operational envi-
ronment whereas the project manager’s ideas are rooted
from the past experience in a project-based environment.
In effect, because of lacking of understanding, com-
munication barriers exist, project managers do not under-
stand what their clients really expect (lack of user input)
and projects fail. In o rder to overco me these barriers, it is
necessary both parties to enhance their dialectic rela-
tionships, commit to a certain goal planning and if nec-
essary change the requirements and specifications so as
to reach the desired outcome, which is project success.
In general for a project to be successful, is has to be
delivered on time, within budget, and conform to the
client’s requirements; requirements analysis is mainly
related to determine the needs and conditions to be met
for a successful project, taking into account the possible
risks and of course, understand customer’s needs and
expectations.
In literature, there exist many different methodologies
which are related to analyzing the requirements of a pro-
ject, which in effect become a tool for effective project

Benefits Management Process Complements Other Project Management Methodologies 840
management.
Proper requirements analysis drive almost every task
and activity, however, the identifications of when, how
and what has to be done should be a bidirectional activity
among all the parties involved.
In benefits management approach, the benefits (project
outcomes) are analysed prior to starting managing a pro-
ject, whereas, in traditional methodo logies, such as Agile
(cyclic software development process, encourages leader-
ship philosophy), DSDM (Dynamic System Develop-
ment; software development methodology), PRINCE2
(structured approach), focus is given more on the suc-
cessful completions of different tasks, which in effect
will lead to beneficial outcomes; in CCPM methodology
emphasis is given on the resources (physical and human)
so as to execute project tasks.
Most project managers seem to declare victory too
soon, meaning that a project is characterised as finished
when the deliverables are complete. The priorities of the
project should be clear from the beginning without al-
lowing any misunderstandings among stakeholders.
When a project is finish ed it should be declared as fin-
ished. PRINCE2 for example, in the CP (Closing Project)
process it describes that one of the defining features of a
project is that is has an end. Therefore, it should be rec-
ognised by all involved parties that the original object-
tives have been met, the project has run its course and in
case there are unachieved goals and objectives, these
should be identified so as to be addressed in the near fu-
ture. [3]
2. The Benefits Management Framework
The Benefits Management Framework is based on the
outcomes from the corporate strategy and from the op-
erational processes of an organization.
The benefits management framework is defined by the
following key ideas:
 assesses the overall value and organization impact of
the program;
 i denti fies t he depe nde ncies of the be nefit s;
 ensures that the benefits are specific, measurable, ac-
tual, realistic, and linked to strategic outcomes;
 ensures that business areas are committed to the rea-
lization of identified benefits;
 analyzed the potential impact of planned program
changes on benefits outcome;
 assigns responsibilities and accountability for the
benefits required from the program.
The Benefits Management Framework has been de-
veloped by Pettigrew and Whirp [4] and it is composed
of five stages in the iterative process. Links between the
stages are shown in Figure 1. In the next paragraphs
each stage is described details.
2.1. Identify Benefits
The initial step is to identify an d understand why a IS/IT
project needs improvement/s. This is called driver analy-
sis and it is used to identify the drivers that are influ-
enced by the organisation and are needed to change in
some way. After, identifying the potential benefits, then
the investment objectives follows.
The achievement of each objective could deliver a va-
riety of different benefits across the organisation. After
the identification and allocation of the stakeholder’s re-
sponsibility, the next step is the determination of the re-
quired changes.
These changes are required for the delivery of each
benefit and a benefit network is required in order to un-
derstand the relationship between business objectives,
business changes, and IT technology. Finally, the first
stage produces an outline of the bu siness case in order to
decide whether to proceed or stop the invest m e nt .
2.2. Plan Benefits Realisation
The main objective of this stage is to develop a detailed
benefits realisation plan for the investment which will be
submitted to the organisation’s m anagem ent for approval.
Many differences may exist between this plan and the
traditional business case. Firstly, this plan provides a full
description of the benefits and changes, which determine
the ownership and deliv ery of the benefits. Second ly, this
plan includes the dates when the benefits will appear and
the resources to be used to assess properly.
Finally, a fully documented benefits dependency net-
work is presented for the relationship between the benefits
and changes.
2.3. Execution of Benefits Plan
The execution of the Benefits Plan is the most important
Figure 1. Benefits management framework source [5].

Benefits Management Process Complements Other Project Management Methodologies 841
part of the overall project or change programme. Moni-
toring the progress of the deliverables and activities of
the benefits plan is important of the project. This is
achieved through an app ropriate set of progress meetings
attended by business managers’ owners, the business
streams, as they are called.
In practise a business project manager is appointed to
assure that the project is delivered on time in order to
meet the business needs without interruptions and risks.
2.4. Review and Evaluate Results
This stage is based on the evaluation and review of busi-
ness outcomes after the completion of the project. A sur-
vey of approa ches relative to managing IT benefits of 60
organisations [6], reported that only 26% of the compa-
nies always reviewed projects after the completion in
order to determine whether benefits are delivered or not.
The review stage is important in order to understand
where and how further benefits may be achieved, and for
this reason it may be necessary to revisit the benefits
realisation plan (stage 2) again.
2.5. Further Benefits
This stage of further benefits can be identified any time,
but it is explored at the review stage. According to the
survey [6] findings, it is very difficult to predict in ad-
vance the benefits. While 90% of the survey respondents
support this view, only 15% of their organisations apply
a specific team to search for further benefits at the end of
projects. Typically, releasing new benefits will involve
further business changes and IT systems development in
later releases.
2.6. Do’s and Don’ts of Benefits Management
According to Ward and Murray [7] there are some Do’s
and Don’ts as far as Benefits Management is concerned:
 Do start Benefit Management on day one of every
project
 Do involve all potential and known stakeholders
early in determination of benefits
 Do make sure all dis-benefits are exposed and un-
derstood-ensure they are a price worth paying
 Do carry out a pilot or prototype if benefits are un-
certain to determine what benefits are achievable
and how to realize them
 Do ensure that all changes that affect the plan are
interpreted in terms of the benefits and the benefit
plan
 Do publicise benefits that have been achieved
 Do use Benefit Management to stop bad projects
 Do not expect to be able to predict all benefits in
advance-many will only be understood after im-
plementation
 Do not stop managing the benefits when the ‘pro-
ject’ is finished
3. Benefits Management and PRINCE2
Comparison
PRINCE2 is an example of a structured project manage-
ment approach that it is used widely in both the private
and public sectors. It was developed by the Office of
Government Commerce (OCG) and is the recommend
approach by UK government projects [3].
PRINCE2, can be considered a refinement of an earlier
approach PRINCE2 which is based on existing best prac-
tises in project management and other methodologies.
OGC was involved in the early stages of the research that
led to the development of the benefits management proc-
ess described in this paper.
There seems to be a high degree of correlation be-
tween the two approaches allowing them to be used to-
gether in a way that draws on the specific strengths of
each approach. Nevertheless, even though being consis-
tent, differences also are existent.
PRINCE2 is defined in eight distinctive processes for
the effective management and governance of a project.
(See Figure 2 )
Each distinct process is described briefly here and then,
how benefits management and PRINCE2 can be com-
bined to complement each other follows.
1) Starting up a project; th is sends to be the first and a
short process in which the project management team is
appointed and the aims of the project are communicated.
For this processes a Project Mandate is required, in
which the reasons and the products (outcome) is the pro-
ject is defined.
2) Directing a project; this is a process for the project
board, in effect the senior management responsible for
the project to direct its activities and resources. The
process lasts for the full duration of the project and has
five major strands within it:
Authorising initiation; Approval of the business case;
Review of the project at stage boundaries; Ad hoc direc-
tion (progress monitoring) and ensuring the project comes
to a controlled close and that lessons are shared with o th e r
projects.
3) Initiating a project; this process seeks to develop a
business case for the project which, is contained in a
project initiation document (PID). It includes also, the
plan and the cost of the project as well as ensuring that
the investment is well justified, taking into account the
respective risks. It is suggested that a PID contains much
information about a project including:
 Objectives
 Critical success factors and key performance indi-
cators

Benefits Management Process Complements Other Project Management Methodologies 842
Figure 2. Effective management and governance processes source: OGC, PRINCE2 [3].
 Impacts and assumptions
 Constraints and option evaluations
 Benefits analysis
 Project costs
 Cost/benefit analysis
 Risks
 Delivery plan- including stages or milestones
4) Controlling a stage; one of the key principles in
PRINCE2; controlling projects is to break them into
manageable, smaller stages. In th is process it is described
the monitoring and control activities, which are required
to keep a stage on track.
5) Managing product delivery; specifies the contract
between the project and suppliers. In effect the objective
of this process is to ensure that planned products (out-
come) are delivered as predefined. PRINCE2 calls the
work agreed in the process a “work package” and seeks
to ensure agreement on issu es such as timin g, quality and
cost. For this reason, checkpoint reports are often ex-
changed between team and project manager.
6) Managing stage boundaries; this process is related
to reporting on the performance of the previous stage,
approval from senior management so as to move to the
next stage, updating the project plan and detailed plan-
ning of the next stage. It actually produces the informa-
tion based on which the Project Board will take the key
decisions.
7) Planning; the planning process, is a repeatable
process and continues throughout the whole the project.
Each project plan (stage and team) must consider key
planning aspects. According to PRINCE2 all activities
should be logically be put in a sequence. Further to the
plan, the process has a product checklist and the risk log.
8) Closing a project; the project board decides to close
the project once its products are delivered and objectives
are met. Moreover it is ensured that fo llow-up actions are
undertaken and lessons shared are learned in conjunction
with other project s.
According to Ward and Daniel [5], while PRINCE2 is
analytical enough by providing very detailed guidelines
on how project management methods and practices can
be improved, on the other hand, benefits and their man-
agement seem to be described depthlessly.
To be more specific, while it is advised that the project
initiation document (project initiation stage) describes a
comprehensive benefit analysis; linking for example the
benefits to the changes required, ap pointing benefit own-
ers, settings measures for each benefit, the details on how
to accomplish it, is limited.
Benefits are considered to be very important as far as
the decision to manage a project is considered. This is
because benefits in many cases compensate risks. If the
risks in a project, in effect the possibility of failure is
high then the decision might be complicated and benefits
should be taken into account.
Essentially, the limited treatment of benefits is there-
fore a noticeable area of weakness. As a walkthrough it
can be suggested that the tools and techniques related to
the first two stages of the five-stage process (identify
benefits, plan realisation) are used to develop a full bene-
fits plan. For PRINCE2, the benefits plan can be de-
scribed in the PID. The simplicity of the benefits man-
agement approach is also important and lies in this early
stage of the project.
Ward and Daniel [5] illustrated that the strength of
PRINCE2 lies in its comprehensiveness formality atten-
tion to detail and its robustness. However, the result of
being inevitab ly complex, has as a result, that most busi-
ness managers do not want or have the time to learn the
methodology or even be subjected to it.

Benefits Management Process Complements Other Project Management Methodologies 843
Nevertheless, in UK it is the de facto standard for pro-
ject management required by the government; there are
also voices which claim that we are not far from the time
that it will be used as a standard by ISO quality man-
agement for quality control of project/s environment.
It is therefore suggested, that, PRINCE2 process of
controlling stages, managing state boundaries and man-
aging product delivery are used if required to undertake
the third stage of our benefits management process: the
execution of the benefits plan. A key part of PRINCE2
approach is the breaking of projects into phases. The
benefit plan particularly the benefits dependency network,
can prove a means of identifying and comparing possible
phases.
According to the closing process, as described in
PRINCE2 handbook, it is suggested that the success of
the project is reviewed and shared among the stake-
holders so as best practised to be revealed. However,
these best practices do not specifically focus on benefits.
Moreover, identification of further potential benefits is
not accurately described or described at all. In effect it is
suggested that benefits management process is followed
in these activities.
Finally, for organisations that have chosen as project
management methodology PRINCE2, the benefits eva-
luation which come up from the project evaluation, is
better to be included in the project closing process.
In Figure 3, it is illustrated how the benefits manage-
ment process and PRINCE2 are related and which ap-
proach suggested should lead at each stage.
4. Conclusions
Benefits Management should be considered the first pri-
ority of any project. This is because it describes effect-
tively the “steps” of how a project should be managed,
and consequently what will be the outcome, “benefits”.
The main purpose of Benefits Management or any other
similar process is to avoid project failure.
In effect, great attention is given in testing and imple-
menting business solutions. According to the benefits
management approach, the first step is to identify the
benefits, which in turn have to be structured, planned and
realised.
PRINCE2, is an alternative to structured project man-
agement methodologies and approaches. Compared to
Benefits Management one, benefits are treated in a lim-
ited way which suggest an obvious weakness, but it is a
lot stronger in analytically defining the details of the
processes.
Business management methodologies are not a pana-
cea against project failure; nevertheless, they can be seen
and used as a powerful tool in the hands of the stake-
Figure 3. Benefits management and PRINCE2 relation, source [5].

Benefits Management Process Complements Other Project Management Methodologies 844
holders which can lead to project success.
Proper requirements analysis drive almost every task
and activity, however, the identifications of when, how
and what has to be done should be a bidirectional activity
among all the parties involved. Failure in projects is a
status which every project manager tries to avoid; with
the aid of project methodologies and especially with be-
nefits management one, which complements other pro-
ject management methodologies the possibility of succ-
ess is enhanced.
Finally, the key message for managing project expec-
tations is effective, efficient communication and coop-
eration between the project manager and the client.
REFERENCES
[1] The Standish Group, “Chaos Report,” 2007.
http://www.standishgroup.com/search/search.php
[2] C. Apostolopoulos and I. Karamitsos, “The Success of IT
Projects Using Agile Methodology,” 1st International
Workshop on Requirements Analysis Proceedings, Lon-
don, 6 December 2008, pp. 13-21.
[3] Office of Government Commerce, “Managing Successful
Project with PRINCE2 Reference Manual,” The Station-
ery Office, London, 2005.
[4] A. Pettigrew and R. Whipp, “Managing Change for Cor-
porate Success,” Blackwell, Oxford, 1991.
[5] J. Ward and E. Daniel, “Benefits Management-Delivering
Value from IS & IT Investments,” John Wiley & Sons,
New York, 2006.
[6] J. Ward and P. Griffiths, “Strategic Planning for Informa-
tion Systems,” 2nd Edition, John Wiley & Sons, New
York, 1996.
[7] J. Ward and P. Murray, “Benefits Management: Best Pra-
ctice Guidelines,” Cranfield University, Bedford, 1997.