Software Engineering and Project Management (BCS501)

Module 4
CHAPTER 1

INTRODUCTION TO SOFTWARE PROJECT MANAGEMENT

1.1. Introduction
1.2. Why is Software Project Management Important
1.3. What is Project?
1.4. Software Projects versus Other Types of Projects
1.5. Contract Management and Technical Project Management
1.6. Activities Covered by Software Project Management
1.7. Plans, Methods and Methodologies
1.8. Some Ways of Categorizing Software Projects
1.9. Project Charter
1.10. Stakeholders
1.11. Setting Objectives
1.12. The Business Case
1.13. Project Success and Failure
1.14. What is Management?
1.15. Management Control
1.16. Project Management Lift Cycle
1.17. Traditional versus Modern Project Management Practices

Dept. of ISE BGSCET 1

 Software Engineering and Project Management (BCS501)

1.1. Introduction
The first question that we encounter is whether the management of software projects is really
that different from that of other projects.

Comparison of Software and Other Projects:

 Evaluates whether software project management differs significantly from managing

other types of projects.

Key Ideas in Software Project Management:

 Focuses on planning, monitoring, and controlling software projects.

Objective of All Projects:

 All projects, including software projects, aim to meet specific objectives and satisfy
real needs.

Stakeholders and Objectives:

 Identifying the project's stakeholders and their objectives is crucial.

 Ensuring that these objectives are met is the primary aim of project management.

Assessing the Project's Progress:

 Knowing the current state of the project is essential to predict whether it will meet its
objectives in the future.

1.2. Why is Software Project Management Important?

First, there is the question of money. A lot of money is at stake with ICT (Information and
Communication) projects. In UK during 2002/2003, the central government spent more on
contracts for ICT projects than on contracts related to roads.

The biggest departmental spender was the Department of Work and Pensions, who spent
over 800 million euros on ICT. Mismanagement of ICT projects means there is shortage in
budget to spend on other domain projects such as hospitals.

Unfortunately projects are not always successful. In a report published in 2003, the Standish
Group in the USA analyzed 13 thousand projects and concluded that only a third of projects
were successful, 82% of the projects were late, and 43% exceeds their budget.

The reason for these project shortcomings is often the management of projects. The National
Audit Office in UK identified that “lack of skills and proven approach to project management
and risk management” were the main reasons among many other.

Dept. of ISE BGSCET 2

 Software Engineering and Project Management (BCS501)

1.3. What is a Project?

The dictionary definitions put a clear emphasis on the project being a planned activity.

The emphasis on being planned assumes we can determine how to carry out a task before
we start. Yet with exploratory projects this might be difficult.

Planning is in essence, thinking carefully about something before you do it, even with
uncertain projects this is worth doing as long as the resulting plans are seen as provisional.

Other activities, such as routine maintenance, will have been performed so many times that
everyone knows exactly what to do. In these cases, planning hardly seems necessary,
although procedures might be documented to ensure consistency and to help newcomer.

The activities that benefit most from convectional project management are likely to lie
between two extremes.

There is a hazy boundary between the non-routine projects and the routine job. The first time
you do a routine task, it will be like a project. On the other hand, a project to develop a system
similar to previous ones that you have developed will have a larger element of the routine.

Activities most likely to benefit from project management

The following characteristics distinguish projects:

 Non-routine tasks are involved.

 Planning is required.
 Specific objectives are to be met or a specified products is to be created.
 The project has a predetermined time spam.
 Work is carried out for someone other than yourself.
 Work involves several specialisms.
 People are formed into a temporary work groups to carry out the task.
 Work is carried out in several phases.
 The resources that are available for use on the project are constrained.
 The project is large or complex.

Dept. of ISE BGSCET 3

 Software Engineering and Project Management (BCS501)

The more any of these factors apply to a task, the more difficult that task will be. Project size
is particularly important. The project that employs 20 developers is likely to be
disproportionately more difficult than one with only 10 staff because of the need for
additional coordination.

Some argue that projects are especially problematic as they are temporary sub-organizations.
A group of people is brought together to carry out a task. The existence of this sub-
organization cuts across the authority of the existing units within the organization. This has
the advantage that a group containing various specialists is focused on a single important
task.

1.4. Software Projects versus Other Types of Projects

Many techniques in general project management also apply to software project
management, but Fred Brooks identified some characteristics of software projects which
make them particularly difficult:

 Invisibility:

When a physical artefact such as a bridge is constructed the progress can actually be seen.
With software, progress is not immediately visible. Software project management can be seen
as the process of making the invisible visible.

 Complexity:

Per dollar, pound or euro spent, software products contain more complexity than other
engineered artefacts.

 Conformity:

The ‘traditional’ engineer usually works with physical systems and materials like cement and
steel. These physical systems have complexity, but are governed by consistent physical laws.
Software developers have to conform to the requirements of human clients. It is not just that
individuals can be inconsistent. Organizations, because of lapses in collective memory, in
internal communication or in effective decision making, can exhibit remarkable
‘organizational stupidity’.

 Flexibility:

That software is easy to change is seen as a strength. However, where the software system
inter faces with a physical or organizational system, it is expected that the software will
change to accommodate the other components rather than vice versa. Thus software systems
are particularly subject to change.

Dept. of ISE BGSCET 4

 Software Engineering and Project Management (BCS501)

1.5. Contract Management and Technical Project Management

 In-house projects are where the users and the developers of new software work for the
same organization.
 However, increasingly organizations contract out ICT development to outside developers
(Outsourcing projects).
 Here, the client organization will often appoint a ‘project manager’ to supervise the
contract who will delegate many technically oriented decisions to the contractors.
 Thus, the project manager will not worry about estimating the effort needed to write
individual software components as long as the overall project is within budget and on
time.
 On the supplier side, there will need to be project managers who deal with the more
technical issues.

1.6. Activities Covered by Software Project Managements

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.

Usually there are three successive processes that bring a new system into being

The feasibility study

 It 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.
 Sometimes an organization assesses a programme of development made up of a number
of projects.

Dept. of ISE BGSCET 5

 Software Engineering and Project Management (BCS501)

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.

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.

The Feasibility study/plan/execution cycle

Dept. of ISE BGSCET 6

 Software Engineering and Project Management (BCS501)

Below figure 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.

The ISO 12207 software development life cycle

 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.

 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. 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.

Dept. of ISE BGSCET 7

 Software Engineering and Project Management (BCS501)

 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.7. Plans, Methods and 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 converts
it to real activities, identifying for each activity:

 It’s 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.

Dept. of ISE BGSCET 8

 Software Engineering and Project Management (BCS501)

1.8. Some Ways of Categorizing 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.

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.

A Classification of Software Projects

Dept. of ISE BGSCET 9

 Software Engineering and Project Management (BCS501)

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 field all over the world. Of late, the Indian companies have
slowly begun to focus on product development as well.

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, and stage based on an agreed requirement.

Dept. of ISE BGSCET 10

 Software Engineering and Project Management (BCS501)

1.9. Project Charter

Project charter is an important high-level document that authorizes the starting of a project
and use of the required resources. Besides, it outlines the project objectives, deliverables
and the resources required. It also documents the aspect that are out of scope, and identifies
the main stakeholders, their roles and responsibilities.

A project charter document is usually developed for all types of projects, irrespective of
whether it is an in-house project or a project undertaken on behalf of some customers.

The project charter is signed and issued by a member of the top management of the
company who also takes up the role of the sponsor of the project.

The project sponsor champions the project, monitors the progress of the project and provides
regular feedbacks to the project manager, and helps in removing any obstacles that the
project manager may find difficult to overcome.

The project manager for a project is usually appointed before the project charter is issued
and undertakes to write the project charter in constitution with the project sponsor.

The project charter serves as a guiding document for all activities concerning the project. This
is a document that is not expected to change throughout the project life cycle, unlike other
project management documents.

The project charter is usually a short document that is only a couple of pages long and typically
contains the following:

 Overall objectives of the project and the broad items that are within the scope of the
project and those that are out of scope.
 The time schedule in terms of the start date and the expected completion date of the
project.
 The important stakeholders and their responsibilities towards the project.
 Overview of the resources that will be needed for the project and the overall budget.
 Major risks to the project and the broad strategies that can be adopted for overcoming
those.

Dept. of ISE BGSCET 11

 Software Engineering and Project Management (BCS501)

1.10. Stakeholders
These are people who have a stake or interest in the project. Their early identification is
important as you need to set up adequate communication channels with them. Stakeholders
can be categorized as:

 Internal to the project team: This means that they will be under the direct managerial
control of the project leader.
 External to the project team but within the same organization: For example, the project
leader might need the assistance of the users to carry out systems testing. Here the
commitment of the people involved has to be negotiated.
 External to both the project team and the organization: External stakeholders may be
customers (or users) who will benefit from the system that the project implements. They
may be contractors who will carry out work for the project. The relationship here is usually
based on a contract.

Different types of stakeholder may have different objectives and one of the jobs of the
project leader is to recognize these different interests and to be able to reconcile them.

The project leader therefore needs to be a good communicator and negotiator. Boehm and
Ross proposed a ‘Theory W’ of software project management where the manager
concentrates on creating situations where all parties benefit from a project and therefore
have an interest in its success. (The ‘W’ stands for ‘win–win’.)

Given the importance of coordinating the efforts of stakeholders, the recommended practice
is for a communication plan to be created at the start of a project.

1.11. 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
define 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. 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

Dept. of ISE BGSCET 12

 Software Engineering and Project Management (BCS501)

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. 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 defined 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’.
 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 defined point in time by which the objective should
have been achieved.

Dept. of ISE BGSCET 13

 Software Engineering and Project Management (BCS501)

Measure of Effectiveness
Measures of effectiveness provide practical methods of checking that an objective has been
met. ‘Mean time between failures’ (MTBF) might, for example, be used to measure reliability.
This is a performance measurement and, as such, can only be taken once the system is
operational.

Project managers want to get some idea of the performance of the completed system as it is
being constructed. They will therefore seek predictive measures. For example, a large number
of errors found during code inspections might indicate potential problems with reliability
later.

1.12. The Business Case

Most projects need to have a justification or business case: the effort and expense of pushing
the project through must be seen to be worthwhile in terms of the benefits that will
eventually be felt.

A cost–benefit analysis will often be part of the project’s feasibility study. This will itemize and
quantify the project’s costs and benefits.

The benefits will be affected by the completion date: the sooner the project is completed, the
sooner the benefits can be experienced. The quantification of benefits will often require the
formulation of a business model which explains how the new application can generate the
claimed benefits.

A simple example of a business model is that a new web-based application might allow
customers from all over the world to order a firm’s products via the internet, increasing sales
and thus increasing revenue and profits.

Any project plan must ensure that the business case is kept intact. For example:

 That development costs are not allowed to rise to a level which threatens to exceed the
value of benefits;
 That the features of the system are not reduced to a level where the expected benefits
cannot be realized;
 That the delivery date is not delayed so that there is an unacceptable loss of benefits.

Dept. of ISE BGSCET 14

 Software Engineering and Project Management (BCS501)

1.13. Project Success and Failure

The project plan should be designed to ensure project success by preserving the business
case for the project. However, every non-trivial project will have problems, and at what stage
do we say that a project is actually a failure? Because different stakeholders have different
interests, some stakeholders in a project might see it as a success while others do not.

Broadly speaking, we can distinguish between project objectives and business objectives.
The project objectives are the targets that the project team is expected to achieve. In the case
of software projects, they can usually be summarized as delivering:

 The agreed functionality

 To the required level of quality
 On time
 Within budget.

A project could meet these targets but the application, once delivered could fail to meet
the business case. A computer game could be delivered on time and within budget, but might
then not sell. A commercial website used for online sales could be created successfully, but
customers might not use it to buy products, because they could buy the goods more cheaply
elsewhere.

We have seen that in business terms it can generally be said that a project is a success if the
value of benefits exceeds the costs. We have also seen that while project managers have
considerable control over development costs, the value of the benefits of the project
deliverables is dependent on external factors such as the number of customers.

Project objectives still have some bearing on eventual business success. Increasing
development costs reduce the chances of the delivered product being profitable. A delay in
completion reduces the amount of time during which benefits can be generated and
diminishes the value of the project.

A project can be a success on delivery but then be a business failure, On the other hand, a
project could be late and over budget, but its deliverables could still, over time, generate
benefits that outweigh the initial expenditure.

Because the focus of project management is on the immediate project, it may not be seen
that the project is actually one of a sequence. Later projects benefit from the technical skills
learnt on earlier projects. Technical learning will increase costs on the earlier projects, but
later projects benefit as the learnt technologies can be deployed more quickly, cheaply and
accurately. This expertise is often accompanied by additional software assets, for example
reusable code.

Dept. of ISE BGSCET 15

 Software Engineering and Project Management (BCS501)

Customer relationships can also be built up over a number of projects. If a client has trust in
a supplier who has done satisfactory work in the past, they are more likely to use that
company again, particularly if the new requirement builds on functionality already delivered.
It is much more expensive to acquire new clients than it is to retain existing ones.

1.14. What is Management?

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;
 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 below figure.

Principal Project Management Processes

It shows that project management is carried out over three well-defined stages or processes,
irrespective of the methodology used.

Dept. of ISE BGSCET 16

 Software Engineering and Project Management (BCS501)

Project Initiation:

 Initial Planning: Undertaken immediately after the feasibility study and before starting
requirements analysis and specification.
 Estimations: Estimating cost, duration, and effort.
 Scheduling: Developing schedules for manpower and resources based on estimations.
 Staffing: Organizing staff and making staffing plans.
 Risk Management: Identifying, analyzing, and planning to mitigate risks.
 Miscellaneous Plans: Creating quality assurance plans, configuration management
plans, etc.

Project Execution:

 Monitoring: Tracking the progress of the project.

 Control: Taking corrective actions to ensure the project stays on track.

Project Closing:

 Completing all activities logically.

 Formally closing all contracts.

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.

1.15. Management Control

Management, in general, involves setting objectives for a system and then monitoring the
performance of the system.

In below figure, 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.

Dept. of ISE BGSCET 17

 Software Engineering and Project Management (BCS501)

The Project Control Cycle

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’.

Having implemented the decision, the situation needs to be kept under review by collecting
and processing further progress details.

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 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.

Software development and project management life cycle

Software development life cycle (SDLC) denotes the stages through which a software is
developed. A SDLC is shown in terms of the set of activities that are undertaken during a
typical software development project, their grouping into different phases and their
sequencing.

Dept. of ISE BGSCET 18

 Software Engineering and Project Management (BCS501)

Project Management Life Cycle versus Software Development Life Cycle

During SDLC, starting from its conception, the developers carry out several processes till the
software is fully developed and deployed at the client site.

A few examples of software development processes undertaken by the development team

includes requirements gathering and analysis, requirements specification, architectural
design, detailed design, coding and testing.

In contrast to SDLC, the project management life cycle (PMLC) typically starts well before
the software development activities start and continue for the entire duration of the SDLC.

During SDLC, the developers carry out several types of development processes. On the other
hand, during the PMLC, the software project manager carries out several project
management processes to perform the required software project management activities.

A few examples of the project management process carried out by a project manager
includes project initiation, planning, execution, monitoring, controlling and closing.

The activities carried out by the developers during SDLC as well as PMLC are grouped into
number of phases. Typical sets of phases and their sequencing in both the life cycles are
shown below.

Different phases of PMLC and SDLC

As can be seen, the phases of PMLC are initiation, planning, execution and closing. It can be
observed that by the time software development process starts, the initiating phase of
software project management life cycle is almost completed.

Dept. of ISE BGSCET 19

 Software Engineering and Project Management (BCS501)

1.16. Project Management Life Cycle

As seen above, the project management life cycle has four stages.

(i) Project Initiation

 Project management life cycle starts with project initiation. The project initiation phase
usually starts with project concept development. During concept development the
different characteristics of the software to be developed are thoroughly understood.
 The different aspect of the project that are investigated and understood include: the
scope of the project, project constraints, the cost that would be incurred and the benefits
that would accrue.
 Based on this understanding, a feasibility study is undertaken to determine whether the
project would be financially and technically feasible. This is true for all products, including
in-house development projects as well as outsourced projects.
 Based on the feasibility study, the business case is developed. Once the top management
agrees to the business case, the project manager is appointed, the project charter is
written, and finally the project team is formed. This sets the ground for the manager to
start the project planning phase.

Barry Boehm summarized the questions that need to be asked and answered in order to have
an understanding of these projects characteristics in his W5HH principle:

 Why is the software being built?

 What will be done?
 When will it be done?
 Who is responsible for a function?
 Where are they organizationally located?
 How will the job be done technically and managerially?
 How much of each resource is needed?

Project Bidding:

Once an organization’s top management is convinced by the business case, the project
charter is developed. For some categories of projects, it may be necessary to have a formal
budding process to select a suitable vendor based on some cost-performance criteria. If the
project involves automating some activities of an organization, the organization may either
decide to develop in-house or may get various software venders to bid for the project.

Dept. of ISE BGSCET 20

 Software Engineering and Project Management (BCS501)

The different type of bidding techniques and their implication and applicability are:

 Request for Quotation (RFQ): An organization advertises an RFQ if it has good

understanding of the project and the possible solutions. While publishing RFQ, the
organization would have to mention the scope of the work in a statement of work (SOW)
document. Based on the RFQ different venders can submit their quotations. The RFQ
issuing organization can select a vender based on the price quoted as well as the
competency of the vender.
 Request for proposal (RFP): Many times it so happens that an organization has reasonable
understanding of the problem to be solved, however it does not have a good grasp of the
solution aspect. This is, the organization may not have sufficient knowledge about the
different features that are to be implemented, and may lack familiarity with the possible
choices of the implementation environment such as, database, operating system, and
client-server deployment. In this case, the organization may solicit solution proposals
from venders
 Request for Information (RFI): An organization soliciting bids may publish an RFI. Based
on the vendor response to RFI, the organization can assess the competencies of the
vendor and shortlist the vendor who can bid for the work. However, it must be noted that
vendor selection is seldom done based on RFI, but the RFI response from the vendor may
be used in conjunction with RFP and RFQ response for vender selection.

(ii) Project Planning

An important outcome of the project initiation phase is the project charter. During the
planning phase, the project manager carries out several process and creates the following
documents:

 Project plan: This document identifies the project tasks, and a schedule for the project
tasks that assigns project resources and time frames to the tasks.
 Resource plan: It lists the resources, manpower and equipment that would be required
to execute the project
 Financial plan: It documents the plan for manpower, equipment and other costs.
 Quality plan: Plan of quality targets and controls plans are included in this document.
 Risk plan: this document lists the identification of the potential risks, their prioritization
and a plan for the actions that would be taken to contain the different risks.

Dept. of ISE BGSCET 21

 Software Engineering and Project Management (BCS501)

(iii) Project Execution

In this phase the tasks are executed as per the project plan development during the planning
phase. A series of management process are undertaken to ensure that the tasks are executed
as per plan. Monitoring and control process are undertaken to ensure that the tasks are
executed as per plan and corrective actions are initiated whenever any deviation from the
plans are notices.

(iv) Project Closure

Project closure involves completing the release of all required deliverables to the customer
along with the necessary documentation. Subsequently, all the project resources and supply
agreement with the vendor are terminated and all the pending payments are completed.
Finally, a post implementation review is undertaken to analyse the project performance and
to list the lessons learnt for use in future projects.

1.17. Traditional versus Modern Project Management Practices

Over the last two decades, the basic approach taken by the software industry to develop
software has undergone a radical change. Hardly any software is being developed from
scratch any more. Software development projects are increasingly being based on either
tailoring some existing product or reusing certain pre-built libraries.

In either case, two important goals of recent life cycle models are maximization of code reuse
and compression of project durations.

Other goals include facilitating and accommodating client feedbacks and customer
participation in project development work, and incremental delivery of the product with
evolving functionalities.

Some important differences between modern project management practices and traditional
practices are:

Planning Incremental Delivery

Few decades ago, projects were much simpler and therefore more predictable than the
present day projects. In those days, projects were planned with sufficient detail, much before
the actual project execution started. After the project initiation, monitoring and control
activities were carried out to ensure that the project execution proceeded as per plan.

Dept. of ISE BGSCET 22

 Software Engineering and Project Management (BCS501)

Now, projects are required to be completed over a much shorter duration, and rapid
application development and deployment are considered key strategies. The traditional long-
term planning has given way to adaptive short-term planning. Instead of making a long-term
project completion plan, the project manager now plans all incremental deliveries with
evolving functionalities.

This type of project management is often called extreme project management. Extreme
project management is a highly flexible approach to project management that concentrates
on the human side of project management, rather than formal and complex planning and
monitoring techniques.

Quality Management
Of late, customer awareness about product quality has increased significantly. Tasks
associated with quality management have become an important responsibility of the project
manager. The key responsibilities of a project manager now include assessment of project
progress and tracking the quality of all intermediate artifacts.

Change Management
Earlier, when the requirements were signed off by the customer, any changes to the
requirements were rarely entertained. Customer suggestions are now actively being solicited
and incorporated throughout the development process.

To facilitate customer feedback, incremental delivery models are popularly being used.
Product development is being carried out through a series of product versions implementing
increasingly greater functionalities. Also customer feedback is solicited on each version for
incorporation. This has made it necessary for an organization to keep track of the various
versions and revisions through which the product develops.

Another reason for the increased importance of keeping track of the versions and revisions is
the following. Application development through customization has become a popular
business model. Therefore, existence of a large number of versions of a product and the need
to support these by a development organization has become common. In this context, the
project manager plays a key role in product base lining and version control. This has made
change management a crucial responsibility of the project manager.

Dept. of ISE BGSCET 23

 Software Engineering and Project Management (BCS501)

Requirements Management
 In modern software development practices, there is a conscious effort to develop
software such that it would, to a large extent, meet the actual requirements of the
customer.
 A basic premise of these modern development methodologies is that at the start of a
project the customers are often unable to fully visualize their exact needs and are only
able to determine their actual requirements after they start using the software.
 From this view point, modern software development practices advocate delivery of
software in increments as and when the increments are completed by the development
team, and actively soliciting change requests from the customer as they use the
increments of the software delivered to them.
 It has, therefore, become necessary to properly manage the requirements, so that as and
when there is any change in requirements, the latest and up-to-date requirements
become available to all.
 Requirements management has therefore become a systematic process of controlling
changes, documenting, analysing, tracing, prioritizing requirements and then
communicating the changes to the relevant stakeholders.

Release Management
 Release management concerns planning, prioritizing and controlling the different releases
of a software. For almost every software, multiple releases are made during its life cycle.
 Starting with an initial release, releases are made each time the code changes. There are
several reasons as to why the code needs to change. These reasons include functionality
enhancements, bug fixes and improved execution speed.
 Further, modern development processes such as the agile development processes
advocate frequent and regular releases of the software to be made to the customer during
the software development.
 Starting with the release of the basic or core functionalities of the software, more
complete functionalities are made available to the customers every couple of weeks. In
this context, effective release management has become important.

Dept. of ISE BGSCET 24

 Software Engineering and Project Management (BCS501)

Risk Management
 In modern software project management practices, effective risk management is
considered very important to the success of a project. A risk is any negative situation that
may arise.
 As the project progresses and may threaten the success of the project. Every project is
susceptible to a host of risks that could usually be attributed to factors such as technology,
personnel and customer.
 Unless proper risk management is practised, the progress of the project may get adversely
affected. Risk management involves identification of risks, assessment of the impacts of
various risks, prioritization of the risks and preparation of risk-containment plans.

Scope Management
 Once a project gets underway, many requirement change requests usually arise. Some of
these can be attributed to the customers and the others to the development team.
Modern development practices encourage the customer to come up with change
requests. While all essential changes must be carried out, the superfluous and ornamental
changes must be scrupulously avoided.
 However, while accepting change requests, it must be remembered that the three critical
project parameters: scope, schedule and project cost are interdependent and are very
intricately related. If the scope is allowed to change extensively, while strictly maintaining
the schedule and cost, then the quality of the work would be the major casualty.
 Therefore, for every scope change request, the project managers examine whether the
change request is really necessary and whether the budget and time schedule would
permit it. Often, the scope change requests are superfluous.

Dept. of ISE BGSCET 25

 Software Engineering and Project Management (BCS501)

CHAPTER 2

Project Evaluation

2.1. Evaluation of Individual Projects

2.2. Cost-Benefit Evaluation Techniques
2.3. Risk Evaluation

Dept. of ISE BGSCET 26

 Software Engineering and Project Management (BCS501)

2.1. Evaluation of Individual Projects

Technical assessment
 Technical assessment of a proposed system consists of evaluating whether the required
functionality can be achieved with current affordable technologies.
 Organizational policy, aimed at providing a consistent hardware/software infrastructure,
is likely to limit the technical solutions considered.
 The costs of the technology adopted must be taken into account in the cost-benefit
analysis.

Cost-benefit analysis
Even where the estimated benefits will exceed the estimated costs, it is often necessary to
decide if the proposed project is the best of several options. Not all projects can be
undertaken at any one time and, in any case, the most valuable projects should get most
resources.

Cost-benefit analysis comprises two steps:

 Identifying all of the costs and benefits of carrying out the project and operating the
delivered application: These include the development costs, the operating costs, and
the benefits expected from the new system. Where the proposed system is a
replacement, these estimates should reflect the change in costs and benefits due to
the new system.
 Expressing these costs and benefits in common units: We must express each cost and
benefit - and the net benefit which is the difference between the two- in money.

Most direct costs are easy to quantify in monetary terms and can be categorized as:

 Development costs, including development staff costs.

 Setup costs, consisting of the costs of putting the system into place, mainly of any new
hardware but also including the costs of file conversion, recruitment and staff training.
 Operational costs relating to operating the system after installation.

Cash Flow Forecasting

As important as estimating the overall costs and benefits of a project is producing a cash flow
forecast which indicates when expenditure and income will take place.

We need to spend money, such as staff wages, during a project's development. Such
expenditure cannot wait until income is received (either from using software developed in-

Dept. of ISE BGSCET 27

 Software Engineering and Project Management (BCS501)

house use or from selling it). We need to know that we can fund this development
expenditure either from the company's own resources or by borrowing. A forecast is needed
of when expenditure, such as the payment of salaries, and any income are to be expected.

Typical product life cycle cash flow

Accurate cash flow forecasting is difficult, as it is done early in the project's life cycle and many
items to be estimated might be some years in the future.

When estimating future cash flows, it is usual to ignore the effects of inflation. Forecasts of
inflation rates tend to be uncertain. Moreover, if expenditure is increased due to inflation it
is likely that income will increase proportionately.

2.2. Cost-benefit Evaluation Techniques

We now take a look at some methods for comparing projects on the basis of their cash flow
forecasts.

Below table 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
significant seasonal cash flow patterns, quarterly, or even monthly, cash flow forecasts could
be appropriate.

Dept. of ISE BGSCET 28

 Software Engineering and Project Management (BCS501)

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 shows the greatest net profit but this is at the
expense of a large investment. Indeed, if we had £1M to invest, we might undertake all of the
other three projects and obtain an even greater net profit.

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 of the project.

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:

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

Dept. of ISE BGSCET 29

 Software Engineering and Project Management (BCS501)

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

where r is the discount rate, expressed as a decimal value, and r 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 below.

Dept. of ISE BGSCET 30

 Software Engineering and Project Management (BCS501)

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.

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.

Dept. of ISE BGSCET 31

 Software Engineering and Project Management (BCS501)

NPV and IRR are not, however, a complete answer to economic project evaluation.

 A total evaluation must also take into account the problems of funding the cash flows -
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 profitable 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?

2.3. Risk Evaluation

Every project involves risk. Project risks prevents the project from being completed
successfully are different from business risk that the delivered products are not profitable.

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.

Below table 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.

Dept. of ISE BGSCET 32

 Software Engineering and Project Management (BCS501)

Risk and net present value

Where a project is relatively risky, it is a 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
outcome. Rather than a single cash flow 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 building of motorways,
where variables such as traffic volumes, and hence the total benefit of shorter journey time,
are uncertain. The technique relies on being able to assign probabilities of occurrence to each
scenario, which requires extensive research.

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.

Dept. of ISE BGSCET 33

 Software Engineering and Project Management (BCS501)

Using decision trees

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 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 at 80%. This scenario can be represented as a
tree structure as shown in below figure.

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). The expected value of each path is the sum 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 × 0.8-100,000 x 0.2) and the
expected value of replacing the system £10,000 (250,000 X 0.2-50,000 x 0.8). The company
should therefore choose the option of extending the existing system.

Dept. of ISE BGSCET 34