VALUE-BASED SOFTWARE PROJECT MANAGEMENT
A Business Perspective on Software Projects
Anderson Itaborahy, Káthia Marçal de Oliveira and Rildo Ribeiro dos Santos
PGCTI, Universidade Católica de Brasília, SGAN 916, Módulo B, Brasilia (DF) - Brasil
Keywords: Project Management, Value-Based Software Engineering, IT Business Value.
Abstract: When an organisation decides to invest in a software project it expects to get some value in return. Thus,
decisions in software project management should be based on this expected value by trying to understand
and influence its driver factors. However, despite the significant progress software engineering and project
management has experienced in recent years, both disciplines work in a ‘value neutral’ context, by which is
meant focusing on technical correctness and adherence to plans. This paper intends to contribute to a view
of software project management based on business value by identifying value determinant factors in a
software project and proposing some tools for recording and monitoring them. The proposed approach will
be tested in a real project, in order to evaluate its applicability and usefulness in decision-making.
1 INTRODUCTION
In the last few decades software project management
has undergone rapid development, mainly as a
response to the increasing complexity of such
projects and their business impacts.
However, a number of studies underscore the
fact that projects continue being managed in a value-
neutral context. In other words, technical accuracy
and compliance to the plans are prioritised and
quality is treated as an end in itself, while an
explicit concern for impacts on business is
overlooked (Favaro, 1996; Boehm e Sullivan, 1999;
Boehm, 2006; Biffl et al, 2006).
Based on that criticism, Biffl et al (2006)
propose a ‘Value-Based Software Engineering’.
Such proposal seeks to integrate the idea of value
into software engineering practice, with a focus on
value for stakeholders. As such, the critical factors
for success would lie within the domain of project
value rather than in technical issues.
The management of a project, then, should be
based on the value that the organisation investing in
it expects to get. But how might this be done? How
can a project be managend based on its business
returns? More specifically, how might the drivers of
project value be identified and monitored, so that
they may be acted upon?
Accordingly, this article will present an approach
to software project management based on business
value. To achieve this objective, the determinant
factors of project value and the questions of how
these might be recorded and monitored will be
investigated.The approach was tested in a real
business context in order to verify its applicability
and usefulness in the decision-making process.
2 BUSINESS VALUE IN
SOFTWARE PROJECTS
According to Maximiano (2000), project
management essentially means the process of
decision-making in relation to the use of resources.
These decisions are based on data gathered through
processes of monitoring and control. With some
minor differences, these processes are described by
PMBOK (2004) and CMMI (2001), among others.
Table 1 summarises the information contained in
these models.
Table 1: Project Data.
Information Description
Delivery Delivery acceptance
Scope Scope stability
Chronogram Project evolution
Cost Project evolution
Quality Compliance to standards
Team Competence for the task
Resources Sufficiency and Availability
Commitments Reliability of commitments
Documentation Sufficiency and compliance to
standards
Involvement Stakeholders’ involvement
Risks Threats to planned results
218
Itaborahy A., Marçal de Oliveira K. and Ribeiro dos Santos R. (2008).
VALUE-BASED SOFTWARE PROJECT MANAGEMENT - A Business Perspective on Software Projects.
In Proceedings of the Tenth International Conference on Enterprise Information Systems - DISI, pages 218-225
DOI: 10.5220/0001694502180225
Copyright
c
 SciTePress

These data constitute what might be called a
project’s internal scenario, which excludes
consideration of both business environment and
strategy. As such, they are an insufficient basis for
decisions aimed at achieving a project’s business
value.
In order to identify the relevant data, then, it is
necessary to understand how a project might
produce value.
Marshall, McKay and Prananto (2004),
expanding a previous work by Soh and Markus
(1995), argues for a Process Theory approach for
value generation by information technology.
From this perspective, IT investment represents a
necessary but not a sufficient factor for the
generation of value. The latter, in the form of
business performance gains, is the outcome of a
chain of processes, each one necessary, but
insufficient by itself to guarantee the final result, as
follows:
− Through the alignment process, strategic
objectives will determine what IT investment
is required. That involves identifying
opportunities and threats, understanding
strategy and the opportunities for using IT to
implement it.
− The determined investments will then generate
IT assets through a conversion process. This
contains the design of IT strategies and the
choice of those organisational structures able
to realize them appropriately.
− Depending on how it is used, IT assets will
impact the organisation. The process of use
involves both redesign (in terms of
organisational processes and structures) and
redefinition of roles in order to adjust them to
the IT-induced changes.
− Finally, the impacts resulting from the use of
the assets created by IT investment may lead
to performance gains, depending on the
process of competition, in which the
organisation is situated. The said process
entails the nature of competition within the
industry, competitors’ behaviour, and general
economic conditions.
These authors argue that, for the production of
value, each of these processes must unfold
appropriately. If any one fails, no value is generated.
By the same token, no one process can guarantee
success by itself.
Thorp (1999) also tackles this question, with a
focus on what he calls ‘The Information Paradox’.
This is indicated by the absence of any clear
correlation between IT investment and gains in
organisational performance. According to this author
the paradox results from a mistaken approach in
which an IT project is seen as isolated from its
organisational context.
Like Marshall, McKay and Prananto (2004),
Thorp (1999) claims that IT is incapable of
generating value by itself. Rather, it must be suitably
integrated with other organisational elements
thereby forming what the author calls a ‘Results
Chain’.
The focus of Thorp’s approach (1999) is that a
project should be managed in tandem with all
changes in business processes that it provokes,
rather than in isolation. Other initiatives
complementary to the IT project will be required if
the expected benefits are to materialise. These may
take the form of training programmes, alterations in
organisational structure, marketing initiatives and so
on.
As a tool for assessing project development,
Thorp (1999) proposes a set of key questions that
can be interpreted as follows:
− Is the right thing being done? The aim of this
question is to ensure that project and an
organisation’s business goals are aligned.
− Is the project in the right way? Here the
objective is the integration of project with
organisational processes and structures
−
Is the project being well-done? This question
concerns the presence of adequate staff
capacity, competence, resources and
infrastructure to advance a specific project.
− Can benefits be achieved? The focus here is
on the external context and conditions in
which project aims may be realised.
In both Process Theory and the Results Chain,
organisational strategy is a key issue in project
success. For value to be produced, alignment with
strategy is of central importance. It is therefore
essential to understand the processes of developing
strategy and those elements which define it.
According to Ansoff and McDonnel (1993),
organisational strategy is a function of the Strategic
Business Area, the SBA, which means a segment of
the business environment in which action or
intention to act occurs.
Porter (1979) claims that ‘the essence of strategy
is dealing with competition’, which in turn is defined
by the relations among a set of forces such as
substitute products, customers and suppliers, and
competitors, both new and old.
VALUE-BASED SOFTWARE PROJECT MANAGEMENT - A Business Perspective on Software Projects
219

Such an arrangement of forces determines the
attractiveness of the SBA, which represents the
potentials of profitability, growth, and turbulence in
the environment.
Based on the attractiveness of the SBA, a
company will define its interest in acting there or not
and, if deciding to act, defines its strategy so as to
respond to competition and build an advantageous
position.
Many companies have regular strategic planning
events, usually annually, in which they (among other
things) define the IT projects needed to achieve
stated objectives. However, the more difficult
working environments become, the more likely a
project will undergo contextual changes.
To deal with that turbulence (ever more present
in current business contexts), Ansoff and McDonnel
(1993) suggest continual analysis of strategic
questions, in which an evaluation team must monitor
the situation in order to identify both opportunities
and hazards. This activity supports the decisions of
those responsible for the administration of the
organisation.
3 VALUE-BASED PROJECT
MANAGEMENT
The previous section presented a process view of
how IT leads to the generation of value. This
perspective encompasses diverse aspects of the
value-generating mechanism and highlights a
fundamental point: simply investing in IT is not
enough to achieve business value. Rather, IT
investment – as in the case of a software project –
will generate value through transforming
organisational processes based on previously-
defined strategic objectives.
On the basis of this premise, we propose a
reinterpretation of the model for value creation
developed by Marshall, McKay and Prananto
(2004), backed up with Thorp’s (1999) proposal of a
Results Chain. This new reading is shown in Figure
1.
The first process in the chain is that of
alignment, in which a company’s strategic goals
define those software projects to be carried out.
The second process is that of conversion, in
which software projects generate IT assets. Mooney,
Gurbaxani and Kraemer (1996) claim that the results
of IT investment can be verified by the
modifications introduced into organisational
processes. As such, our revised model will view the
IT assets generated by IT projects as new or
modified business processes.
The third process relates to the use of the
processes created or modified by the IT project.
Projects may be of different types and produce
differing effects in an organisation. This is what
Venkatraman (1994) calls ‘business transformation’.
Modified processes, when utilised, will produce
such transformations.
Moreover, a software project is, in Thorp’s
(1999) view, part of a larger system, and is
dependent on complementary initiatives that will
prepare organisational elements and processes for
their new capabilities. It is thus appropriate to refer
to the process of use as a process of integration,
thereby reinforcing the claim that value is produced
through the integration of IT and business processes.
The fourth process relates to competition, and
concerns those factors external to the business
environment that influence the possibility of an
organisation benefiting from its projects. Such
Project Management
Strategic
objectives
Software
Project
Business
Process
Business
Transformation
Benefit
Alignment
Conversion
Integration Competition
Figure 1: Software Project value generation process chain.
ICEIS 2008 - International Conference on Enterprise Information Systems
220

environments correspond to what Ansoff and
McDonnel (1993) term Strategic Business Area, or
SBA.
As defined by Soh and Markus (1995), the end
result of the chain of value will be gains in business
performance. In this revised model, ‘gain’ means the
benefits an organisation hopes to achieve from a
project, whatever its nature.
Project management will be continually
collecting information related to each process and
making decisions that will affect their evolution.
In addition to the elements in the chain of
processes, the value of a project is affected by the
time required to reach the benefits, by the costs
incurred, and by the risk that it may not be realised.
Therefore, even when the processes of
alignment, conversion, integration and competition
are delivered adequately, if results take to long to
arrive, if costs become excessive, of if the chances
of failure are high, then the organisation may opt to
abandon the project.
Each of the elements in Figure 1, although
insufficient in themselves, is a determining factor of
project value. Likewise, time, costs and risks will
impact value. The set of factors determining the
project value is then as described in Table 2.
Table 2: Determinant factors of value in a Software
Project.
Factor Description
Strategic Objective
Objective motivating the
project
Business Process
Process to be modified by the
project
Business
Transformation
How project results will affect
business
Benefits Expected performance gains
Conversion Process
Corresponding to the execution
of a software project in itself,
in the domain of traditional
Software Engineering.
Integration Process
Organisational initiatives
complementary to the project.
Competition Process
Market contexts in which a
project will produce results.
Time
The timescale in which an
organisation hopes project
results will enhance business
performance.
Costs
Refers to the ‘price’ an
organisation is prepared to pay
for benefits.
Risks
Refers to factors that might
hinder or diminish expected
benefits
Alignment was not included in this list, as it
would already have occurred when a project is
begun and, thus, will not be directly monitored,
although, it is fundamental to know the strategic
objectives behind a project, if it remains valid and if
alignment is maintained.
Taken as a whole, these factors indicate the
potential of a project to generate the value that
justified its undertaking by an organisation.
In traditional software project management
decision-making would be based on monitoring and
control processes that produce the information
shown in Table 1. The data there mainly concerns
the conversion process, and does not consider the
other factors identified in Table 2.
The software project management approach
proposed here extends the data input by recording
and monitoring these other value determinant
factors.
Figure 2 illustrates the proposed approach by
representing traditional data in white and newer
inputs in the darker tone.
While standard project information remains
indispensable, the new additions include the
organisation’s expectations of value creation by a
project, the state of organisational elements, and the
market context within which results will have to be
produced.
This conjoined information may form the basis
for assessing potential project value. This assists the
decision-making which will, in turn, impact a project
by defining resource allocation and further
development.
To structure the approach, certain artefacts were
defined to integrate the determinant factors of
project value and implement the additional data.
These artefacts are presented and explained below:
− The Value Model corresponds to the
organisation’s description of what it expects in
terms of project value, and characterises its
basic determinant factors: the strategic
objective, the business process to be modified,
the intended business transformation and an
indicator of success, which provides the
subjective component of the benefit.
− The Complementary Initiatives describes the
integration process by monitoring initiatives
related to preparing organisational elements
for the changes brought by the project.
− The Market Scenario refers to the competitive
context of the SBA in which a company
intends to get business benefits.
− The Project Scenario describes the conversion
process, and brings on the standard data
VALUE-BASED SOFTWARE PROJECT MANAGEMENT - A Business Perspective on Software Projects
221

concerning traditional software engineering (as
described in Table 1).
The above artefacts encompass the range of
determinant factors of project value presented in
Table 2 and will support the assessment of potential
project value.
This assessment must be undertaken by a
specialised team, with good knowledge of the
company’s business strategy, its particular ‘culture’
and its projects.
An interesting alternative would be to delegate
this task to a Project Management Office - or PMO –
given that these structures have assumed growing
importance in the alignment between business and
IT.
Considering value as a subjective and contextual
concept (Soh and Markus, 1995; ITGI, 2006), it’s
not possible to represent it in a completely
quantitative way. In order to minimise the level of
subjectivity in the assessment process, a specific
artefact was designed. This takes the form of a
structured set of affirmations. The design of this
artefact is based on the processes in the value
creation chain described in Figure 2 and on Thorp’s
(1999) key-questions as described in Section 2.
Potential value assessment will be carried out in
relation to the dimensions of alignment, conversion,
integration, competition, time, cost and risks. Table
3 shows the items associated with each of these
dimensions.
For each item (presented as a statement)
assessors must indicate its level of agreement on a
six level scale ranging from disagreement to
agreement.
For the dimensions of alignment, conversion,
integration and competition groups of five
statements are presented; the fifth in each group
(highlighted in Table 3) summarises a dimension’s
general assessment.
When proceeding to evaluation, assessors will
use the information previously recorded in the
artefacts in order to measure the extent to which it
agrees with each statement. It should be remembered
that the first four statements will form the basis of
the fifth one.
In the cases of time, cost and risks, only one
statement is required.
Each statement will score an agreement level
from 0 (disagreement) to 5 (agreement). The score
for the main statement in each group represents the
overall assessment for the specific dimension.
The final evaluation of the seven dimensions can
be translated into a diagram, as in Figure 3. It is also
possible to record on the diagram different
evaluations, performed in different moments of
project life-cycle, thus showing the evolution of
potential project value.
Table 3: Assessment artefact for potential project value.
Dimension Statement
Alignment
The strategic business objective remains
valid
Using a software solution is opportune
Project benefits for the company are clear
The project is of central importance for
reaching the objective
The project conforms with business
objectives
Conversion
Actors with necessary capabilities are
available
Necessary resources are available
Project plans are consistent
Project execution is going to plan
The project will deliver expected results
Figure 2: Software Project management based on business value.
Project
Scenario
Complementary
Initiatives
Market
Scenario
Value Model
Value
Assessment
Decision-
making
Software Pro
j
ect
ICEIS 2008 - International Conference on Enterprise Information Systems
222

Table 3: Assessment artefact for potential project value
(cont.).
Dimension Statement
Integration
Additional initiatives are developing
appropriately
Organisational elements are being
coordinated
The business is capable of adapting to
necessary changes
The project is adhering to organisational
architecture
Project and organisational elements are
integrated
Competition
The market scenario is favourable to the
project
Estimates of benefits are consistent
Project sponsorship is consistent
Results are protected from uncontrollable
external factors
It will be possible to harvest the beneficial
results from the project
Time
Schedule will be met
Costs
Project execution will not exceed
predefined limits
Risks
The risk of not obtaining benefits is low
Alignment
Conversion
Integration
CompetitionTime
Cost
Risk
Figure 3: Sample project value assessment diagram.
4 PRACTICAL APPLICATION
The approach described in this paper was put into
practice in an actual project for a large enterprise.
Although software development is not the
company’s principal activity, software is used
heavily in its business, what demands many projects,
involving its own staff, as well as external providers.
In order to apply the approach within tight time
limits, an already completed project was chosen. The
data necessary for completing the artefacts was
obtained from project records and in interviews with
the actors involved, especially business managers.
The organisation’s PMO staff led the
application of the approach, as they have knowledge
of the project, strategies and the company’s
document database.
The chosen project aimed to design a new
product, novel both within the company and for the
market, and it had generated high expectations of
possible benefits. Successful implementation of the
product would depend strongly on a robust and
consistent information system that could put the
product business rules into practice.
The project was not challenging in terms of
technology, as there were available staff with
experience of this type of application. The greatest
difficulty was establishing business rules, as there
were still a number of concerns for both a section of
the market and for regulatory agencies.
Assessment was carried out at three specific
points. The first occurred soon after the project had
been approved, the second midway through, and the
third shortly before completion.
In a ‘live’ context such assessments would be
planned during the initial planning of the project,
according to its specific characteristics or company
policy. For example, assessments might be set on a
monthly basis, shortly after relevant deliveries, or
before the injection of major investment.
The diagram in Figure 4 presents the results of
evaluations of potential project value in the case
study in three different moments. The most external
black line indicates the first moment, the dotted line
the second and the grey inner line the third.
Alignment
Conversion
Integration
CompetitionTime
Cost
Risk
Figure 4: Potential project value evolution.
The first assessment indicated high potential
project value, with a high degree of alignment and
good perspectives in all dimensions.
VALUE-BASED SOFTWARE PROJECT MANAGEMENT - A Business Perspective on Software Projects
223

At the second moment deterioration in value was
already noticeable. The project was encountering
problems in stabilising the business model, although
the dimension of conversion remained under control.
In the final assessment, potential value had
vanished, and had even corrupted conversion.
During its actual working life, the project had
appeared technically consistent. Consequently, the
organisation maintained investment and continued
development, trying to keep adherence to established
plans. Had a management approach based on value
been utilised, the losses in the project’s potential
value could have been identified earlier. This in turn
would have led to decisions concerning the
rearrangement and optimisation of available
resources.
5 RELATED WORK
Two important approaches are in the same line of
this article. The first one is the aforementioned
Value-Based Software Engineering (Biffl et al,
2006) that proposes the inclusion of value
considerations among the basic principles of
software engineering.
This paper aims to contribute to the VBSE effort
by investigating the value generation mechanism in
software projects and proposing a method to record
and analyse it, which is part of the VBSE agenda as
proposed by Boehm (2006b).
The second one is the ValIT Initiative (ITGI,
2006). ValIT is intended to respond to the need for
organisations to optimize the realization of value
from IT investments. A significant part of ValIT
principles is based on Thorp (1999), which is also an
important reference for this paper. One of the main
objectives of ValIT is to continuously evaluate the
business value potential of an IT investment in order
to optimize the organisation’s portfolio. To achieve
this go, ValIT defines a set of processes and related
practices.
The instruments proposed herein implement a
way to support the ValIT practices, especially those
related to evaluating, recording and managing value
in software-enabled business investments.
6 CONCLUSIONS
This article has aimed to present a management
approach to software projects based on business
value. A literature review identified the key
determinant factors of project value from a business
perspective.
The value determinant factors were grouped
together and mapped onto a set of artefacts that
could be used to record and monitor their status in a
project. The data obtained would be the input
necessary for the evaluation of project value, a
process that might be undertaken at various
moments according to prior planning.
The evaluation of potential project value would
be a key input for decision-making, since it
complements the technical information produced
from traditional processes of monitoring and control.
The set of artefacts and monitoring mechanisms
described here could underpin a project management
approach based on business value.
In order to assess the applicability of the
approach and its usefulness in real situations, a trial
run was conducted using an actual project as its
basis.
Although the practical application did not enjoy
sufficient quantitative data to conclude its
superiority as a way of assessing project value, it did
indicate that the approach is viable and may be a
useful tool in decision-making.
Future studies could widen the scope of practical
application and extend the experimental results. For
example, they might employ the approach in relation
to a range of actual projects during their life-cycle.
This would provide the quantitative data needed for
more definitive conclusions.
The initial step in this study – the establishment
of parameters for recording and monitoring project
value – also suggests other possibilities. For
example, defining the software process to be used in
a project could be based on determinants of value.
It also seems possible that there is a correlation
between the factors identified, as they do not vary in
a fully independent way. For example, variations in
the conversion process might affect timescale, just
as competition affects levels of risk. The
investigation of such relationships represents another
fruitful area for future study.
Another issue for further studies is the relative
weight of each value factor. Probably they differ for
different business areas. In this case, some
customization will be necessary, but the basic model
remains valid.
By offering an applicable approach to software
project management based on business value, this
work has contributed to the business and academic
communities by providing the following:
− a discussion of how a software project
generates value for business, yet enabling a
more wide-ranging view of this issue;
ICEIS 2008 - International Conference on Enterprise Information Systems
224

− the identification of a matrix of factors that
influences a software project value and can be
used for its continuous monitoring;
− artefacts that can be used by organisations to
record and monitor the development of
potential value in their projects.
On the basis of the research conducted for this
study, it may be seen that, although software
engineering has advanced rapidly in terms of tools
and solutions, many of the most critical remaining
questions are clearly located on the frontier between
IT and business, especially in the creation of a
shared vision of value.
REFERENCES
Ansoff, I., & McDonnel, E. (1993). Implantando a
administração estratégica. São Paulo, SP: Atlas.
Biffl, S. et al (Eds) (2006). Value-based software
engineering. Berlin: Springer Verlag.
Boehm, B. (2006). Some future trends and implications
for systems and software engineering processes.
Systems Engineering, Vol. 09, Is. 1, 1-19.
Boehm, B. (2006b) Value-Based Software Engineering:
Overview and Agenda. In: S. Biffl et al (Eds.) Value-
Based Software Engineering. (pp. 109-132). Berlim:
Springer-Verlag.
Boehm, B.; & Sullivan, K. (1999). Software Economics: a
Roadmap. Information and Software Technology, 41,
937-946.
CMMI (2001). Capability Maturity Model Integration,
version 1.1 – CMMI for Systems Engineering,
Software Engineering and Integrated Product and
Process Development (CMMI SE/SW/IPPD v1.1).
Pittsburg, PA: Software Engineering Institute -
Carnegie Melon University.
Favaro, J. (1996). When the pursuit of quality destroys
value. IEEE Software, Vol. 13, Is. 3, 93-95.
ITGI (2006). Enterprise value governance of IT
investments: The Val IT framework. Rolling Meadows,
IL: IT Governance Institute.
Maximiano, A. (2002). Administração de projetos: como
transformar idéias em resultados. (2ª. Edição). São
Paulo, SP: Atlas.
Marshall, P., McKay, J., & Prananto, A. (2004). A process
model of business value creation from IT investments.
Proceedings of the 15th Australasian Conference on
Information Systems. 81-92.
Mooney, J., Gurbaxani, V., & Kraemer, K. (1996). A
Process Oriented Framework for Assessing the
Business Value of Information Technology. The
DATA BASE for Advances in Information System, Vol.
27, Is. 2, 68-81.
PMBOK (2004). A Guide to the Project Management
Body of Knowledge (PMBOK), 3
rd
Ed.. Newton
Square, PA: Project Management Institute-PMI.
Porter, M. (1979). How Competition Shapes Strategy.
Harvard Business Review, March-April, 9-18.
Soh, C., & Markus, M. (1995). How IT Creates Business
Value: A Process Theory Synthesis. Proceedings of
the 16th International Conference on Information
Systems, 29-41.
Thorp, J. (1999). The Information Paradox: Realizing the
Business Benefits of Information Technology. Toronto,
ON: MacGraw-Hill.
Venkatraman, N. (1994). IT-Enabled Business
Transformation: From Automation to Business Scope
Redefinition. Sloan Management Review, Vol. 32 Is. 2,
73-87.
VALUE-BASED SOFTWARE PROJECT MANAGEMENT - A Business Perspective on Software Projects
225