IT Project Management 22MCA421

MODULE - 1
PROJECT EVALUATION AND PROJECT PLANNING
Importance of Software Project Management - Activities - Methodologies –
Categorization of Software Projects – Setting objectives – Management Principles –
Management Control – Project portfolio Management – Cost-benefit evaluation
technology – Risk evaluation Strategic program Management – Stepwise Project
Planning.
1.1 Importance of Software Project Management
Why is it important to become familiar with project management?
First, there is the question of money. A lot of money is at stake with ICT projects. In the United
Kingdom during the financial year 2002–2003, the central government spent more on contracts
for ICT projects than on contracts related to roads (about £2.3 billion as opposed to £1.4
billion). The biggest departmental spender was the Department for Work and Pensions, who
spent over £800 million on ICT. Mismanagement of ICT projects means that there is less to
spend on good things such as hospitals.
Unfortunately, projects are not always successful. In a report published in 2003, the Standish
Group in the United States analysed 13,522 projects and concluded that only a third of projects
were successful; 82% of projects were late and 43% exceeded their budget.
The reason for these project shortcomings is often the management of projects. The National
Audit Office in the UK, for example, among other factors causing project failure identified
‘lack of skills and proven approach to project management and risk management’.

1.2 Activities
A software project is not only concerned with the actual writing of software. In fact, where a
software application is bought ‘off the shelf’, there may be no software writing as such, but
this is still fundamentally a software project because so many of the other activities associated
with software will still be present.

FIGURE 1.1 The feasibility study/plan/execution cycle

Usually there are three successive processes that bring a new system into being – see Figure
1.1.

1. The feasibility study assesses whether a project is worth starting – that it has a valid business
case. Information is gathered about the requirements of the proposed application. Requirements
elicitation can, at least initially, be complex and difficult. The stakeholders may know the aims
they wish to pursue, but not be sure about the means of achievement. The developmental and
operational costs, and the value of the benefits of the new system, will also have to be estimated.
With a large system, the feasibility study could be a project in its own right with its own plan.
The study could be part of a strategic planning exercise examining a range of potential software
developments. Sometimes an organization assesses a programme of development made up of
a number of projects.

YOGEESH S 1
IT Project Management 22MCA421

2. Planning If the feasibility study indicates that the prospective project appears viable, then
project planning can start. For larger projects, we would not do all our detailed planning at the
beginning. We create an outline plan for the whole project and a detailed one for the first stage.
Because we will have more detailed and accurate project information after the earlier stages of
the project have been completed, planning of the later stages is left to nearer their start.

3. Project execution The project can now be executed. The execution of a project often
contains design and implementation sub-phases. Students new to project planning often find
that the boundary between design and planning can be hazy. Design is making decisions about
the form of the products to be created. This could relate to the external appearance of the
software, that is, the user interface, or the internal architecture. The plan details the activities
to be carried out to create these products. Planning and design can be confused because at the
most detailed level, planning decisions are influenced by design decisions. Thus a software
product with five major components is likely to require five sets of activities to create them.
Figure 1.2 shows the typical sequence of software development activities recommended in the
international standard ISO 12207. Some activities are concerned with the system while others
relate to software. The development of software will be only one part of a project. Software
could be developed, for example, for a project which also requires the installation of an ICT
infrastructure, the design of user jobs and user training.

• Requirements analysis starts with requirements elicitation or requirements gathering which

establishes what the potential users and their managers require of the new system. It could
relate to a function – that the system should do something. It could be a quality requirement
– how well the functions must work. An example of this is dispatching an ambulance in
response to an emergency telephone call. In this case transaction time would be affected by
hardware and software performance as well as the speed of human operation. Training to
ensure that operators use the computer system efficiently is an example of a system
requirement for the project, as opposed to a specifically software requirement. There would
also be resource requirements that relate to application development costs.

FIGURE 1.2 The ISO 12207 so ware development life cycle

YOGEESH S 2
IT Project Management 22MCA421
• Architecture design The components of the new system that fulfil each requirement have
to be identified. Existing components may be able to satisfy some requirements. In other
cases, a new component will have to be made. These components are not only software:
they could be new hardware or work processes. Although software developers are primarily
concerned with software components, it is very rare that these can be developed in isolation.
They will, for example, have to take account of existing legacy systems with which they
will interoperate. The design of the system architecture is thus an input to the software
requirements. A second architecture design process then takes place that maps the software
requirements to software components.
• Detailed design Each software component is made up of a number of software units that
can be separately coded and tested. The detailed design of these units is carried out
separately.
• Code and test refers to writing code for each software unit. Initial testing to debug
individual software units would be carried out at this stage.
• Integration The components are tested together to see if they meet the overall requirements.
Integration could involve combining different software components, or combining and
testing the software element of the system in conjunction with the hardware platforms and
user interactions.
• Qualification testing The system, including the software components, has to be tested
carefully to ensure that all the requirements have been fulfilled.
• Installation This is the process of making the new system operational. It would include
activities such as setting up standing data (for example, the details for employees in a
payroll system), setting system parameters, installing the software onto the hardware
platforms and user training.
• Acceptance support This is the resolving of problems with the newly installed system,
including the correction of any errors, and implementing agreed extensions and
improvements. Software maintenance can be seen as a series of minor software projects. In
many environments, most software development is in fact maintenance.

1.3 Methodologies
A plan for an activity must be based on some idea of a method of work. For example, if you
were asked to test some software, you may know nothing about the software to be tested, but
you could assume that you would need to:
• analyse the requirements for the software;
• devise and write test cases that will check that each requirement has been satisfied;
• create test scripts and expected results for each test case;
• compare the actual results and the expected results and identify discrepancies. While a
method relates to a type of activity in general, a plan takes that method (and perhaps others)
and converts it to real activities, identifying for each activity:
• its start and end dates;
• who will carry it out;
• what tools and materials – including information – will be needed.
The output from one method might be the input to another. Groups of methods or techniques
are often grouped into methodologies such as object-oriented design.

1.4 Categorization of Software Projects

Projects may differ because of the different technical products to be created. Thus we need to
identify the characteristics of a project which could affect the way in which it should be planned
and managed. Other factors are discussed below.

YOGEESH S 3
IT Project Management 22MCA421
Compulsory versus voluntary users
In workplaces there are systems that staff have to use if they want to do something, such as
recording a sale. However, use of a system is increasingly voluntary, as in the case of computer
games. Here it is difficult to elicit precise requirements from potential users as we could with
a business system. What the game will do will thus depend much on the informed ingenuity of
the developers, along with techniques such as market surveys, focus groups and prototype
evaluation.

Information systems versus embedded systems

A traditional distinction has been between information systems which enable staff to carry out
office processes and embedded systems which control machines. A stock control system would
be an information system. An embedded, or process control,
system might control the air conditioning equipment in a building. Some systems may have
elements of both where, for example, the stock control system also controls an automated
warehouse.

Outsourced projects
While developing a large project, sometimes, it makes good commercial sense for a company
to outsource some parts of its work to other companies. There can be several reasons behind
such a decision. For example, a company may consider outsourcing as a good option, if it feels
that it does not have sufficient expertise to develop some specific parts of the product or if it
determines that some parts can be developed cost-effectively by another company. Since an
outsourced project is a small part of some project, it is usually small in size and needs to be
completed within a few months. Considering these differences between an outsourced project
and a conventional project, managing an outsourced project entails special challenges.
Indian software companies excel in executing outsourced software projects and have earned a
fine reputation in this fi eld all over the world. Of late, the Indian companies have slowly begun
to focus on product development as well.
The type of development work being handled by a company can have an impact on its
profitability. For example, a company that has developed a generic software product usually
gets an uninterrupted stream of revenue over several years. However, outsourced projects fetch
only one time revenue to any company.

Objective-driven development
Projects may be distinguished by whether their aim is to produce a product or to meet certain
objectives.
A project might be to create a product, the details of which have been specified by the client.
The client has the responsibility for justifying the product.
On the other hand, the project requirement might be to meet certain objectives which could be
met in a number of ways. An organization might have a problem and ask a specialist to
recommend a solution.
Many software projects have two stages. First is an objective-driven project resulting in
recommendations. This might identify the need for a new software system. The next stage is a
project actually to create the software product.
This is useful where the technical work is being done by an external group and the user needs
are unclear at the outset. The external group can produce a preliminary design at a fixed fee. If
the design is acceptable the developers can then quote a price for the second, implementation,
stage based on an agreed requirement.

YOGEESH S 4
IT Project Management 22MCA421
1.5 Setting objectives
Among all these stakeholders are those who actually own the project. They control the
financing of the project. They also set the objectives of the project. The objectives should defi
ne what the project team must achieve for project success. Although different stakeholders
have different motivations, the project objectives identify the shared intentions for the project.
Objectives focus on the desired outcomes of the project rather than the tasks within it – they
are the ‘post-conditions’ of the project. Informally the objectives could be written as a set of
statements following the opening words ‘the project will be a success if. . . .’ Thus, one
statement in a set of objectives might be ‘customers can order our products online’ rather than
‘to build an e-commerce website’. There is often more than one way to meet an objective and
the more possible routes to success the better.
There may be several stakeholders, including users in different business areas, who might have
some claim to project ownership. In such a case, a project authority needs to be explicitly
identified with overall authority over the project.
This authority is often a project steering committee (or project board or project management
board) with overall responsibility for setting, monitoring and modifying objectives. The project
manager runs the project on a day-to-day basis, but regularly reports to the steering committee.

Sub-objectives and goals

An effective objective for an individual must be something that is within the control of that
individual. An objective might be that the software application produced must pay for itself by
reducing staff costs. As an overall business objective this might be reasonable. For software
developers it would be unreasonable as any reduction in operational staff costs depends not
just on them but on the operational management of the delivered system. A more appropriate
goal or sub-objective for the software developers would be to keep development costs within
a certain budget.
We can say that in order to achieve the objective we must achieve certain goals or sub-
objectives first. These are steps on the way to achieving an objective, just as goals scored in a
football match are steps towards the objective of winning the match. Informally this can be
expressed as a set of statements following the words ‘To reach objective. . ., the following must
be in place. . .’.
The mnemonic SMART is sometimes used to describe well-defined objectives:
• Specific Effective objectives are concrete and well defined. Vague aspirations such as
‘to improve customer relations’ are unsatisfactory. Objectives should be defi ned so
that it is obvious to all whether the project has been successful.
• Measurable Ideally there should be measures of effectiveness which tell us how
successful the project has been. For example, ‘to reduce customer complaints’ would
be more satisfactory as an objective than ‘to improve customer relations’. The measure
can, in some cases, be an answer to simple yes/no question, e.g. ‘Did we install the new
software by 1 June?’
• Achievable It must be within the power of the individual or group to achieve the
objective.
• Relevant The objective must be relevant to the true purpose of the project.
• Time constrained There should be a defi ned point in time by which the objective should
have been achieved.

1.6 Management Principles

We have explored some of the special characteristics of software. We now look at the
‘management’ aspect of software project management. It has been suggested that management
involves the following activities:
• planning – deciding what is to be done;
• organizing – making arrangements;
YOGEESH S 5
IT Project Management 22MCA421
• staffing – selecting the right people for the job etc.;
• directing – giving instructions;
• monitoring – checking on progress;
• controlling – taking action to remedy hold-ups;
• innovating – coming up with new solutions;
• representing – liaising with clients, users, developer, suppliers and other stakeholders.

Much of the project manager’s time is spent on only three of the eight identified activities, viz.,
project planning, monitoring, and control. The time period during which these activities are
carried out is indicated in Fig. 1.3. It shows that project management is carried out over three
well-defi ned stages or processes, irrespective of the methodology used. In the project initiation
stage, an initial plan is made. As the project starts, the project is monitored and controlled to
proceed as planned. However, the initial plan is revised periodically to accommodate additional
details and constraints about the project as they become available. Finally, the project is closed.
In the project closing stage, all activities are logically completed and all contracts are formally
closed.
Initial project planning is undertaken immediately after the feasibility study phase and before
starting the requirements analysis and specification process. Figure 1.4 shows this project
initiation period. Initial project planning involves estimating several characteristics of a project.
Based on these estimates, all subsequent project activities are planned. The initial project plans
are revised periodically as the project progresses and more project data becomes available.
Once the project execution starts, monitoring and control activities are taken up to ensure that
the project execution proceeds as planned. The monitoring activity involves monitoring the
progress of the project. Control activities are initiated to minimize any significant variation in
the plan.

FIGURE 1.3 Principal project management processes

Project planning is an important responsibility of the project manager. During project planning,
the project manager needs to perform a few well-defi ned activities that have been outlined
below. Note that we have given a very brief description of these activities in this chapter. We
will discuss these activities in more detail in subsequent chapters. Several best practices have
been proposed for software project planning activities. In Chapter 3 we will discuss Step Wise,
which is based on the popular PRINCE2 (PRojects IN Controlled Environments) method.
While PRINCE2 is used extensively in the UK and Europe, similar software project
management best practices have been put forward in the USA by the Project Management
Institute’s ‘PMBOK’ which refers to their publication ‘A Guide to the Project Management
Body of Knowledge.’
• Estimation The following project attributes are estimated.
• Cost How much is it going to cost to complete the project?
• Duration How long is it going to take to complete the project?
• Effort How much effort would be necessary for completing the project?

YOGEESH S 6
IT Project Management 22MCA421
The effectiveness of all activities such as scheduling and staffing, which are planned at a later
stage, depends on the accuracy with which the above three project parameters have been
estimated.
• Scheduling Based on estimations of effort and duration, the schedules for manpower
and other resources are developed.
• Staffi ng Staff organization and staffing plans are made.
• Risk Management This activity includes risk identification, analysis, and abatement
planning.
• Miscellaneous Plans This includes making several other plans such as quality assurance
plan, configuration management plan, etc.
Project monitoring and control activities are undertaken after the initiation of development
activities. The aim of project monitoring and control activities is to ensure that the software
development proceeds as planned. While carrying out project monitoring and control activities,
a project manager may sometimes find it necessary to change the plan to cope with specific
situations and make the plan more accurate as more project data becomes available.
At the start of a project, the project manager does not have complete knowledge about the
details of the project. As the project progresses through different development phases, the
manager’s information base gradually improves. The complexities of different project
activities become clear, some of the anticipated risks get resolved, and new risks appear. The
project parameters are re-estimated periodically incorporating new understanding and change
in project parameters. By taking these developments into account, the project manager can plan
subsequent activities more accurately with increasing levels of confidence. Figure 1.4 shows
this aspect as iterations between monitoring and control, and the plan revision activities.

1.7 Management Control

Management, in general, involves setting objectives for a system and then monitoring the
performance of the system. In Figure 1.4 the ‘real world’ is shown as being rather formless.
Especially in the case of large undertakings, there will be a lot going on about which
management should be aware.
This will involve the local managers in data collection. Bare details, such as ‘location X has
processed 2000 documents’, will not be very useful to higher management: data processing
will be needed to transform this raw data into useful information. This might be in such forms
as ‘percentage of records processed’, ‘average documents processed per day per person’ and
‘estimated completion date’.

FIGURE 1.4 The project control cycle

YOGEESH S 7
IT Project Management 22MCA421

In our example, the project management might examine the ‘estimated completion date’ for
completing data transfer for each branch. These can be checked against the overall target date
for completion of this phase of the project. In effect they are comparing actual performance
with one aspect of the overall project objectives. They might find that one or two branches will
fail to complete the transfer of details in time. They would then need to consider what to do
(this is represented in Figure 1.4 by the box Making decisions/ plans). One possibility would
be to move staff temporarily from one branch to another. If this is done, there is always the
danger that while the completion date for the one branch is pulled back to before the overall
target date, the date for the branch from which staff are being moved is pushed forward beyond
that date. The project manager would need to calculate carefully what the impact would be in
moving staff from particular branches. This is modelling the consequences of a potential
solution. Several different proposals could be modelled in this way before one was chosen for
implementation.
Having implemented the decision, the situation needs to be kept under review by collecting
and processing further progress details. For instance, the next time that progress is reported, a
branch to which staff have been transferred could still be behind in transferring details. This
might be because the reason why the branch has got behind in transferring details is because
the manual records are incomplete and another department, for whom the project has a low
priority, has to be involved in providing the missing information. In this case, transferring extra
staff to do data inputting will not have accelerated data transfer.
It can be seen that a project plan is dynamic and will need constant adjustment during the
execution of the project. Courses and books on project management (such as this one) often
focus considerable attention on project planning. While this is to be expected, with nearly all
projects much more time is spent actually doing the project rather than planning it. A good plan
provides a foundation for a good project, but is nothing without intelligent execution. The
original plan will not be set in stone but will be modified to take account of changing
circumstances.

1.8 Project portfolio Management

Portfolio project management provides an overview of all the projects that an organization is
undertaking or is considering. It prioritizes the allocation of resources to projects and decides
which new projects should be accepted and which existing ones should be dropped.

The concerns of project portfolio management include:

• identifying which project proposals are worth implementation;
• assessing the amount of risk of failure that a potential project has;
• deciding how to share limited resources, including staff time and finance, between
projects – one problem can be that too many projects are started given the resources
available so that inevitably some projects will miss planned completion dates;
• being aware of the dependencies between projects, especially where several projects
need to be completed for an organization to reap benefits;
• ensuring that projects do not duplicate work;
• ensuring that necessary developments have not been inadvertently been missed.
The three key aspects of project portfolio management are portfolio definition, portfolio
management and portfolio optimization. An organization would undertake portfolio definition
before adopting portfolio management and then proceeding to optimization.

Project portfolio definition

An organization should record in a single repository detail of all current projects. A decision
will be needed about whether projects of all types are to be included. Should just ICT projects
be included in the repository, or should other projects such as the setting up of a new warehouse

YOGEESH S 8
IT Project Management 22MCA421
also be included? One problem for many organizations is that projects can be divided into new
product developments (NPD) where the project deliverable is a product, such as a computer
game, that is sold to customers, and renewal projects which improve the way an organization
operates – information systems projects are often like this. The distinction is not always clear-
cut. For example, a new information system could be used to provide a customer service such
as recording the details of people buying a new insurance product.
NPD projects are often more frequent in organizations which have a continuous development
of new goods and services. Renewal projects may be less frequent and thus inherently more
risky as there is less experience of these types of project. NPD projects find attracting funding
easier with their clear relationship between the project and income. Where both types of project
call upon the same pools of resources, including finance, the argument for a common portfolio
is strong.

Project portfolio management

Once the portfolio has been established, more detailed costings of projects can be recorded.
The value that managers hope will be generated by each project can also be recorded. Actual
performance of projects on these performance indicators can then be tracked. This information
can be the basis for the more rigorous screening of new projects.

Project portfolio optimization

The performance of the portfolio can be tracked by high-level managers on a regular basis. A
better balance of projects may be achieved. Some projects could potentially be very profitable
but could also be risky. In the case of an e-commerce site, for example, sales may not be as
great as hoped because established competitors reduce prices. Other projects could have modest
benefits, such as those cutting costs by automating processes, but have fewer risks. The
portfolio ought to have a carefully thought-out balance between the two types of projects.

Some problems with project portfolio management

An important role of project portfolio management is sharing resources between projects. There
can be problems because while apparently full-time staff are allocated to a project, they may
effectively be part-time because they still have routine work to do. This is particularly so with
users, and with developers who may on occasion be called away from project work to deal with
support tasks.
The official project portfolio may not accurately reflect organizational activity if some projects
are excluded. A formal decision may be made that only projects over a certain level of cost will
be recorded in the portfolio.
The ‘below the line’ projects could in fact consume substantial staff effort and bleed away
effort from the official projects. It can be argued that all projects should be included in the
official portfolio.
However, there are advantages in allowing these tasks. It allows small ad hoc tasks to be done,
such as quick fixes to systems to deal with externally imposed changes. They reduce work for
higher management by saving them from having to process a large number of small work
requests. Developers may find these small tasks rewarding: dealing with these small requests
is an easy way to keep users happy. Thus when allocating resources to projects, a margin should
be set to allow first-line managers some judgement in accepting non-planned work.

1.9 Cost-benefit evaluation technology

We now take a look at some methods for comparing projects on the basis of their cash flow
forecasts.
Table 1.1 illustrates cash flow forecasts for four projects. In each case it is assumed that the
cash flows take place at the end of each year. For short-term projects or where there are

YOGEESH S 9
IT Project Management 22MCA421
significant seasonal cash flow patterns, quarterly, or even monthly, cash fl ow forecasts could
be appropriate.
TABLE 1.1 Four project cash flow projections – figures are end of year totals (£)

Net profit
The net profit of a project is the difference between the total costs and the total income over
the life of the project. Project 2 in Table 1.1 shows the greatest net profit but this is at the
expense of a large investment. Indeed, if we had £1 m to invest, we might undertake all of the
other three projects and obtain an even greater net profit. Note also that all projects contain an
element of risk and we might not be prepared to risk £1 m. We shall look at the effects of risk
and investment later in this chapter.
Moreover, the simple net profit takes no account of the timing of the cash flows. Projects 1 and
3 each have a net profit of £50,000 and therefore, according to this selection criterion, would
be equally preferable. The bulk of the income occurs late in the life of project 1, whereas project
3 returns a steady income throughout its life. Having to wait for a return has the disadvantage
that the investment must be funded for longer. Add to that the fact that, other things being
equal, estimates in the more
distant future are less reliable than short-term estimates and we can see that the two projects
are not equally preferable.

Payback period
The payback period is the time taken to break even or pay back the initial investment.
Normally, the project with the shortest payback period will be chosen on the basis that an
organization will wish to minimize the time that a project is ‘in debt’.
The advantage of the payback period is that it is simple to calculate and is not particularly
sensitive to small forecasting errors. Its disadvantage as a selection technique is that it ignores
the overall profitability of the project – in fact, it totally ignores any income (or expenditure)
once the project has broken even. Thus the fact that projects 2 and 4 are, overall, more profitable
than project 3 is ignored.

Return on investment
The return on investment (ROI), also known as the accounting rate of return (ARR), provides
a way of comparing the net profitability to the investment required. There are some variations
on the formula used to calculate the return on investment but a straightforward common version
is:
𝑎𝑣𝑒𝑟𝑎𝑔𝑒 𝑎𝑛𝑛𝑢𝑎𝑙 𝑝𝑟𝑜𝑓𝑖𝑡
𝑅𝑂𝐼 = × 100
𝑡𝑜𝑡𝑎𝑙 𝑖𝑛𝑣𝑒𝑠𝑡𝑚𝑒𝑛𝑡

YOGEESH S 10
IT Project Management 22MCA421
The return on investment provides a simple, easy-to-calculate measure of return on capital.
Unfortunately, it suffers from two severe disadvantages. Like the net profitability, it takes no
account of the timing of the cash flows. More importantly, this rate of return bears no
relationship to the interest rates offered or charged by banks (or any other normal interest rate)
since it takes no account of the timing of the cash flows or of the compounding of interest. It
is therefore, potentially, very misleading.

Net present value

The calculation of net present value is a project evaluation technique that takes into account
the profitability of a project and the timing of the cash flows that are produced. This is based
on the view that receiving £100 today is better than having to wait until next year to receive it.
We could, for example, invest the £100 in a bank today and have £100 plus the interest in a
year’s time. If we say that the present value of £100 in a year’s time is £91, we mean that £100
in a year’s time is the equivalent of £91 now.
The equivalence of £91 now and £100 in a year’s time means we are discounting the future
income by approximately 10%. If we received £91 now and invested it for a year at an annual
interest rate of 10%, it would be worth £100 in a year’s time. The annual rate by which we
discount future earnings is known as the discount rate – 10% in the above example.
Similarly, £100 received in two years’ time would have a present value of approximately £83
– in other words, £83 invested at an interest rate of 10% would yield approximately £100 in
two years’ time.
The present value of any future cash flow may be obtained by applying the following formula
𝑣𝑎𝑙𝑢𝑒 𝑖𝑛 𝑦𝑒𝑎𝑟 𝑡
𝑃𝑟𝑒𝑠𝑒𝑛𝑡 𝑣𝑎𝑙𝑢𝑒 =
(1 + 𝑟)𝑡
where r is the discount rate, expressed as a decimal value, and t is the number of years into the
future that the cash flow occurs.
Alternatively, and rather more easily, the present value of a cash flow may be calculated by
multiplying the cash flow by the appropriate discount factor. A small table of discount factors
is given in Table 2.2.
The NPV for a project is obtained by discounting each cash flow (both negative and positive)
and summing the discounted values. It is normally assumed that any initial investment takes
place immediately (indicated as year 0) and is not discounted. Later cash flows are normally
assumed to take place at the end of each year and are discounted by the appropriate amount.

TABLE 1.2 NPV discount factors

YOGEESH S 11
IT Project Management 22MCA421
TABLE 2.3 Applying the discount factors to project 1

It is interesting to note that the net present values for projects 1 and 3 are significantly different
– even though they both yield the same net profit and both have the same return on investment.
The difference in NPV reflects the fact that, with project 1, we must wait longer for the bulk
of the income.
The main difficulty with NPV for deciding between projects is selecting an appropriate
discount rate. Some organizations have a standard rate but, where this is not the case, then the
discount rate should be chosen to reflect available interest rates (borrowing costs where the
project must be funded from loans) plus some premium to reflect the fact that software projects
are normally more risky than lending money to a bank. The exact discount rate is normally less
important than ensuring that the same discount rate is used for all projects being compared.
However, it is important to check that the ranking of projects is not sensitive to small changes
in the discount rate – have a look at the following exercise.
Alternatively, the discount rate can be thought of as a target rate of return. If, for example, we
set a target rate of return of 15% we would reject any project that did not display a positive net
present value using a 15% discount rate. Any project that displayed a positive NPV would be
considered for selection – perhaps by using an additional set of criteria where candidate
projects were competing for resources.

Internal rate of return

One disadvantage of NPV as a measure of profitability is that, although it may be used to
compare projects, it might not be directly comparable with earnings from other investments or
the costs of borrowing capital. Such costs are usually quoted as a percentage interest rate. The
internal rate of return (IRR) attempts to provide a profitability measure as a percentage return
that is directly comparable with interest rates. Thus, a project that showed an estimated IRR of
10% would be worthwhile if the capital could be borrowed for less than 10% or if the capital
could not be invested elsewhere for a return greater than 10%.
The IRR is calculated as that percentage discount rate that would produce an NPV of zero. It
is most easily calculated using a spreadsheet or other computer program that provides functions
for calculating the IRR. Microsoft Excel, for example, provides IRR functions which, provided
with an initial guess or seed value (which may be zero), will search for and return an IRR.
One deficiency of the IRR is that it does not indicate the absolute size of the return. A project
with an NPV of £100,000 and an IRR of 15% can be more attractive than one with an NPV of
£10,000 and an IRR of 18% – the return on capital is lower but the net benefits greater.
Another objection to the internal rate of return is that, under certain conditions, it is possible to
find more than one rate that will produce a zero NPV. However, if there are multiple solutions,
it is always appropriate to take the lowest value and ignore the others. NPV and IRR are not,
however, a complete answer to economic project evaluation.

YOGEESH S 12
IT Project Management 22MCA421
• A total evaluation must also take into account the problems of funding the cash fl ows –
will we, for example, be able to repay the interest on any borrowed money at the appropriate
time?
• While a project’s IRR might indicate a profi table project, future earnings from a relatively
risky project might be far less reliable than earnings from, say, investing with a bank. We
might undertake a more detailed risk analysis as described below.
• We must also consider any one project within the financial and economic framework of the
organization as a whole – if we fund this one, will we also be able to fund other worthy
projects?

1.10 Risk evaluation

Every project involves risk. We have already noted that project risks, which prevent the project
from being completed successfully, are different from the business risk that the delivered
products are not profitable. Project risks will be discussed in Chapter 7. Here we focus on
business risk.

Risk identification and ranking

In any project evaluation we should identify the risks and quantify their effects. One approach
is to construct a project risk matrix utilizing a checklist of possible risks and classifying risks
according to their relative importance and likelihood. Importance and likelihood need to be
separately assessed – we might be less concerned with something that, although serious, is very
unlikely to occur than with something less serious that is almost certain. Table 2.5 illustrates a
basic project risk matrix listing some of the business risks for a project, with their importance
and likelihood classified as high (H), medium (M), low (L) or exceedingly unlikely (—). So
that projects may be compared, the list of risks must be the same for each project assessed. It
is likely, in reality, that it would be longer than shown and more precise.
The project risk matrix may be used as a way of evaluating projects (those with high risks being
less favoured) or as a means of identifying and ranking the risks for a specific project.

TABLE 2.5 A fragment of a basic project/business risk matrix for an e-commerce application

Risk and net present value

Where a project is relatively risky it is common practice to use a higher discount rate to
calculate net present value. This risk premium might, for example, be an additional 2% for a
reasonably safe project or 5% for a fairly risky one. Projects may be categorized as high,
medium or low risk using a scoring method and risk
premiums designated for each category. The premiums, even if arbitrary, provide a consistent
method of taking risk into account.

Cost–benefit analysis
A rather more sophisticated approach to the evaluation of risk is to consider each possible
outcome and estimate the probability of its occurring and the corresponding value of the
YOGEESH S 13
IT Project Management 22MCA421
outcome. Rather than a single cash fl ow forecast for a project, we will then have a set of cash
flow forecasts, each with an associated probability of occurring. The value of the project is then
obtained by summing the cost or benefit for each possible outcome weighted by its
corresponding probability.
This approach is frequently used to evaluate large projects such as the building of motorways,
where variables such as traffic volumes, and hence the total benefit of shorter journey times,
are uncertain. The technique, of course, relies on being able to assign probabilities of
occurrence to each scenario, which requires extensive research.
When used to evaluate a single major project, the cost–benefit approach, by ‘averaging out’
the negative and positive outcomes of the different scenarios, does not take full account of
‘worst-case scenarios’. Because of this, it is more appropriate for the evaluation of a portfolio
of projects where overall profitability is the primary concern, more successful projects can
offset the impact of less successful ones.

Risk profile analysis

An approach which attempts to overcome some of the objections to cost–benefit averaging is
the construction of risk profiles using sensitivity analysis.
This involves varying each of the parameters that affect the project’s cost or benefits to
ascertain how sensitive the project’s profitability is to each factor. We might, for example, vary
one of our original estimates by plus or minus 5% and recalculate the expected costs and
benefits for the project. By repeating this exercise for each of our estimates in turn we can
evaluate the sensitivity of the project to each factor.
By studying the results of a sensitivity analysis we can identify those factors that are most
important to the success of the project. We then need to decide whether we can exercise greater
control over them or otherwise mitigate their effects. If neither is the case, then we must live
with the risk or abandon the project.

Using decision trees

The approaches to risk analysis discussed previously rather assume that we are passive
bystanders allowing nature to take its own course – the best we can do is to reject over-risky
projects or choose those with the best risk profile. There are many situations, however, where
we can evaluate whether a risk is important and, if it is, decide a suitable course of action.
Such decisions will limit or affect future options and, at any point, it is important to be able to
assess how a decision will affect the future profitability of the project.
As an example, say a successful company is considering when to replace its sales order
processing system. The decision largely rests upon the rate at which its business expands – if
its market share significantly increases (which it believes will happen if rumours of a
competitor’s imminent bankruptcy are fulfilled) the existing system might need to be replaced
within two years. Not replacing the system in time could be an expensive option as it could
lead to lost revenue if it cannot cope with increased sales. Replacing the system immediately
will, however, be expensive as it will mean deferring other projects already scheduled.
It is calculated that extending the existing system will have an NPV of £75,000, although if the
market expands significantly, this will be turned into a loss with an NPV of –£1 00,000 due to
lost revenue. If the market does expand, replacing the system now has an NPV of £250,000
due to the benefits of being able to handle increased sales and other benefits such as improved
management information. If sales do not increase, however, the benefits will be severely
reduced and the project will suffer a loss with an NPV of –£50,000.
The company estimate the likelihood of the market increasing significantly at 20% – and,
hence, the probability that it will not increase as 80%. This scenario can be represented as a
tree structure as shown in Figure 1.5.
The analysis of a decision tree consists of evaluating the expected benefit of taking each path
from a decision point (denoted by D in Figure 1.5). The expected value of each path is the sum

YOGEESH S 14
IT Project Management 22MCA421
of the value of each possible outcome multiplied by its probability of occurrence. The expected
value of extending the system is therefore £40,000 (75,000 3 0.8 – 100,000 3 0.2) and the
expected value of replacing the system £10,000 (250,000 3 0.2 – 50,000 3 0.8). The company
should therefore choose the option of extending the existing system.

Figure 1.5 A Decision tree

1.11 Strategic program Management
A different form of programme management is where a portfolio of projects all contribute to a
common objective. Take, for example, a business which carries out maintenance work for
clients. A customer’s experience of the organization might be found to be very variable and
inconsistent. The employee who records the customer’s requirements is different from the
people who actually carry out the work and different again from the clerk who deals with the
accounts. Often a customer has to explain to one company employee a problem that has already
been discussed at length with some other employee. A business objective might be to present
a consistent and uniform front to the client. This objective might require changes to a number
of different systems which until now have been largely self-contained. The work to reorganize
each individual area could be treated as a separate project, coordinated at a higher level as a
programme.
These types of programme are most often needed by large organizations which have a large
and complicated organizational structure. Government departments are typical examples and
it is not surprising that the OGC, the United Kingdom government agency which was
responsible (as the CCTA) for the introduction of PRINCE2 project management standards,
has directed its attention to guidelines for effective programme management. The approach
now described is based on the OGC guidelines.

1.12 Stepwise Project Planning.

This chapter describes a framework of basic steps in project planning upon which the following
chapters build. Many different techniques can be used in project planning and this chapter gives
an overview of the points at which these techniques can be applied during project planning.
Chapter 4 will illustrate how different projects may need different technical approaches, but
the overall framework should always apply to the planning process.

The framework described is called the Step Wise method to help to distinguish it from other
methods such as PRINCE2. PRINCE2 is a set of project management standards that were
originally sponsored by what is now the Office of Government Commerce (OGC) for use on
British government ICT and business change projects. The standards are now also widely used

YOGEESH S 15
IT Project Management 22MCA421
on non-government projects in the United Kingdom. Step Wise should be compatible with
PRINCE2. It should be noted, however, that Step Wise covers only the planning stages of a
project and not monitoring and control.

It should be clearly understood that the Step Wise method discussed in this chapter aims to
introduce the standardization of the project planning method brought about by PRINCE.
PRINCE stands for PRojects IN Controlled Environments. PRINCE2 is in the public domain,
and offers non-proprietary best practice guidance on project management. It is a de facto
standard used extensively in UK and also internationally. In contrast, the traditional project
planning approach discussed in many other text books, and practised in many industries allows
considerable flexibility in the steps to be carried out, and the manner in which they are carried
out. However, it should be clearly understood that all our discussions in the subsequent chapters
can be used in a traditional project management situation without any loss of generality.
In order to illustrate the Step Wise approach and how it might have to be adapted to deal with
different circumstances, two parallel examples are used. Let us assume that there are two
former Computing and Information Systems students who now have several years of software
development experience under their belts.
Figure 1.6 provides an outline of the main planning activities. Steps 1 and 2 ‘Identify project
scope and objectives’ and ‘Identify project infrastructure’ could be tackled in parallel in some
cases. Steps 5 and 6 will need to be repeated for each activity in the project

FIGURE 1.6 An overview of Step Wise

YOGEESH S 16
IT Project Management 22MCA421
A major principle of project planning is to plan in outline first and then in more detail as the
time to carry out an activity approaches. Hence the lists of products and activities that are the
result of Step 4 will be reviewed when the tasks connected with a particular phase of a project
are considered in more detail. This will be followed by a more detailed iteration of Steps 5 to
8 for the phase under consideration.

YOGEESH S 17