UNIT 1

Introduction
The job pattern of an IT company engaged in software development can be seen split in two
parts:

• Software Creation
• Software Project Management
A project is well-defined task, which is a collection of several operations done in order to
achieve a goal (for example, software development and delivery). A Project can be
characterized as:

• Every project may has a unique and distinct goal.

• Project is not routine activity or day-to-day operations.
• Project comes with a start time and end time.
• Project ends when its goal is achieved hence it is a temporary phase in the lifetime of
an organization.
• Project needs adequate resources in terms of time, manpower, finance, material and
knowledge-bank.

Software Project

A Software Project is the complete procedure of software development from requirement

gathering to testing and maintenance, carried out according to the execution methodologies,
in a specified period of time to achieve intended software product.

Need of software project management

Software is said to be an intangible product. Software development is a kind of all new

stream in world business and there’s very little experience in building software products.
Most software products are tailor made to fit client’s requirements. The most important is
that the underlying technology changes and advances so frequently and rapidly that
experience of one product may not be applied to the other one. All such business and
environmental constraints bring risk in software development hence it is essential to manage
software projects efficiently.
The image above shows triple constraints for software projects. It is an essential part of
software organization to deliver quality product, keeping the cost within client’s budget
constrain and deliver the project as per scheduled. There are several factors, both internal
and external, which may impact this triple constrain triangle. Any of three factor can
severely impact the other two.
Therefore, software project management is essential to incorporate user requirements along
with budget and time constraints.

Activities covered in Software Project Management

Usually there are three successive processes that bring a new system into being - see Figure 1 .2.

1. The feasibility study assesses whether a project is worth starting - that it has a valid business case.
lnformation is gathered about the aspects of requirements of the proposed application. The
developmental and operational costs, and the value of the benefits of the new system, will also
have to be estimated.
2. Planning lf the feasibility study indicates that the prospective project method 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. The later stage is left to nearer their start.
3. Project execution The project can now be executed. The execution of the project often contains
design and implementation sub-phases.
Design is making decision 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.

Figr- 1 .3 shows the typical sequence of software development activities recommended in the
international standard ISO .l 2207. Some activities are concerned with the system while others
relate to software. The development of software will be only one part of a project.
1. Requirements analysis starts with requirements elicitation or requirements gathering which
establishes what the potential users and their managers require of the new system
2. 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. ln 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
3. 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.
4. Code and test refers to writing code for each software unit. lnitial testing to debug individual
software units would be carried out at this stage.
5. Integration The components are tested together to see if they meet the overall requirements.
Integration could involve combing different software components, or combining and testing
the software element of the system in conjunction with the hardware platforms and user
interactions.
6. Qualification testing The system, including the software components, has to be tested
carefully to ensure that all the requirements have been fulfilled.
7. lnstallation 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.
8. 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
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;
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
Groups of methods or techniques are often grouped into methodologies such as obiect-oriented
technique
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. Other factors are discussed below

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

2. lnformation 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 system might control the air conditioning equipment in a building

3. Outsourced project : while developing a large project , sometime it make good sense for a
company to outsource some part of its work to other companies . A company may consider
outsourcing a a good option , if it feel that it does not have efficient expertise to develop
some specific part of the product or if it determine that some part can be developed by
another company cost effectively

4. Objectives driven products 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

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 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.
For example, end-users may be concerned with the ease of use of the new application,
while their managers may be more focused on staff savings. The project leader therefore
needs to be a good communicator and negotiator. 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 is Theory ‘W’. (The 'W' stands for 'win-
win'.)

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. Objectives focus
on the desired outcomes of the project rather than the tasks within it.
A project steering committee (or project board development or project management
board) has the overall responsibility for setting, management, monitoring and modifying
objectives. The project manager runs the project representatives' on a day-to-day basis,
but regularly reports to the steering committee.

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 ldeally there should be measures of effectiveness which
tell us how successful the project has been. For example,'to reduce customer complaints'
would ld be more satisfactory as an objective than “to improve customer relations'.
The measure cart, in some cases, be simple yes/no question, eg: Did we install the
new software by 1st June?'
• Achievable lt 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

What is management?

lt has been suggested that management involves the following activities:

Planning: to decide beforehand what is to be done in future. It encompasses

formulating policies, establishing targets, scheduling actions.
 Organizing: Once the plans are formulated, the next step is to organise the activities
and resources, as in identifying the tasks, classifying them, assigning duties to
subordinates and allocating the resources.

Staffing: It involves hiring personnel for carrying out various activities of the
organization. It is to ensure that the right person is appointed to the right job.

Directing: It is the task of the manager to guide, supervise, lead and motivate the
subordinates, to ensure that they work in the right direction, so far as the objectives of
the organization are concerned

Controlling: steps to be taken to make sure that the performance of the employees
is as per the plans, establishing performance standards and comparing them with the
actual performance. In case of any variations, necessary steps are to be taken for its
correction.

Innovating: coming up with new solutions

Representing: Liaising with clients ,users, developers, suppliers and other

stakeholders

Project Planning Project Monitoring

and Control

Project Closing

Project Plan Revision

Project Initiation Project Execution Project Closing

Principal Project management processes

Much of 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 Is carried out Is
indicated in the fig. above.

In the project initiation phase, initial plan is made, as the project starts, it involve estimating several
characteristic of the project.

Once project execution starts, monitored and control activities are taken up to ensure that the project
execution proceeds as planned. Monitoring activity involve monitoring the progress of the project.
Control activities’ are initiated to minimize any significant variation in plan
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.

Management Control

Management in general involve setting objectives for the system and then monitoring the performance
of the system. ln Figure the 'real world' is shown as being rather formless.

This will involve the local managers in data collection. Data processing will be needed to transform
this raw data into useful information.

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. 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/plan). One possibility would be to move staff temporarily from one branch to
another. lf 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.
It can be seen that a project plan is dynamic and will need constant adjustment during the execution of
the project

Portfolio project management

portfolio project management provides an overview of all the projects that an organization is
undertaking or ís considering. lt 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
needed to be completed for an organization to reap benefits;
• Ensuring that projects do not duplicate work;
• 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.

COST BENEFIT EVALUATION TECHNIQUES

We would consider proceeding with a project only where the benefits outweigh the costs.
However, in order to choose among projects, we need to take into account the timing of the
costs and benefits as well as the benefits relative to the size of the investment.

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

Disadvantages: 1. Sometimes the greatest net profit but is at the expense of a large
investment.

2.the simple net profit takes no account of the timing of the cash flows. Having to wait for a
return means that the investment must be funded for longer.

3.Other things being equal, estimates in the more distant future are less reliable that short-
term estimates and we can see that the two projects are not equally preferable.
2.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.

3.RETURN ON INVESTMENT

It is also known as the accounting rate of return (ARR), it provides a way of comparing the
net profitability to the investment required.

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

4.INTERNAL RATE OF RETURN

One disadvantage of NPV is that 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 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.

Disadvantages: It does not indicate the absolute size of return.

Under certain conditions it is possible to find more than one rate that produce a zero NPV.
RISK EVALUATION

Every project involves risk of some form. Project risks are those which prevent the project
from being completed successfully and business risks are those when the delivered projects
are not project.

1. Risk identification and ranking

In any project evaluation we should attempt to identify the risks and quantify their potential
effects. One common approach is to construct a project risk matrix utilizing a checklist of
possible risks and to classify each risk according to its relative importance and likelihood.The
importance and likelihood need to be separately assessed. A basic project risk matrix listing
some of the risks that might be considered 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 being assessed.

The project risk matrix may be used as a way of evaluating projects or as a means of
identifying and ranking the risks for a specific project.

2.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 addition or 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 provide a consistent method of taking risk into
account.

3.Cost-benefit analysis
Cost -benefit analysis is considering each possible outcome and estimating 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 in the evaluation of large projects such as the building of
new motorways, where variables such as future traffic volumes, and hence the total benefit of
shorter journey times, are subject to uncertainty.

Disadvantages: The technique rely on our being able to assign probabilities of occurrence to
each scenario and, without extensive study, this can be difficult.

When used to evaluate a single project, the cost-benefit approach, by 'averaging out' the
effects of the different scenarios, does not take account an organization's reluctance to risk
damaging outcomes.

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

5.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 where we can
evaluate whether a risk is important and, if it is, indicate a suitable course of action.

Many such decisions will limit or affect the future profitability of the project. As an example
say a successful company is considering to replace its sales order purchasing system. It must
consider the alternative of completely replacing the existing system - which it will have to do
at some point in the future. The decision largely rests upon the rate at which its business
expands - if their market share significantly increases the existing system might need to be
replaced within 2 years. Not replacing the system in time could be an expensive option as it
could lead to lost revenue if they cannot cope with the increase in invoicing demand.
Replacing it immediately will, however, be expensive as it will mean deferring other projects
that have already been scheduled. If sales do not increase, however, the benefits will be
severely reduced and the project will suffer a loss. This scenario can be represented as a tree
structure.

The analysis of a decision tree consists of evaluating the expected benefit of taking each path
from a decision point. The expected value of each path is the sum of the value of each
possible outcome multiplied by its probability of occurrence.

Strateg¡c programme management

It is a form of programme management where a portfolio of projects all contribute to a

common objective. Take, for example, a business which carriesout mainterrance work for
clients. A customer’s experience of the organization might be found to to 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 cleals 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

Stepwise project planning

Thi Figure provides an outline of the main planning activities. Steps 1 and 2 'ldentify 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.

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'

An outline of Step Wise planning is listed below:

0.Selecting project
This is called Step 0 because in a way it is outside the main project planning process.

1.Identify project scope and objectives –

The activities in this step ensure that all the parties to the project agree on the objectives and are
committed to the success of the project.

Step 1.1 Identify objectives and practical measures of the effectiveness in meeting
those objectives

Step 1.2 Establish a project authority

A single overall project authority needs to be established so that there is unity of purpose
among all those concerned.

Step 1.3 Identify all stakeholders in the project and their interests

Step 1.4 Modify objectives in the light of stakeholder analysis

This could mean adding new features to the system which give a benefit to some stakeholder
as a means of assuring their commitment to the project

Step 1.5 Establish methods of communication between all parties

2. Identify project infrastructure

Projects are never carried out in a vacuum .There is usually some kind of existing infrastructure into
which the project must fit

Step 2.1 Identify relationship between the project and strategic planning

Step 2.2 Identify installation standards and procedures

Step 2.3 Identify project team organization

3. Analyse project characteristics

Step 3.1 Distinguish the project as either objective driven or product-driven

Step 3.2 Analyse other project characteristics

Step 3.3 Identify high level project risks

Consideration must be given to the risks that threaten the successful outcome of the project.

Step 3.4 Take into account user requirements concerning implementation

The clients may have their own procedural requirenrerrts.

Step 3.5 Select general life-cycle approach in the light of the above

Step 3.6 Review overall resource estimates

4. Identify project products and activities

Step 4.1 Identify and describe project product (including quality criteria)

The projects will form a hierarchy. The main products will have sets of component products
which in turn may have sub-component products and so on. These relationships can be
documented in a Product Breakdown Structure (PBS). ln this example the products have been
grouped into those relating to the system as a whole, and those related to individual modules.
A third 'group', which happens to have only one product, is called 'management products' and
consists of progress reports. The asterisk in the progress reports indicates that there will be
new instances of the entity 'progress report' created repeatedly throughout the project.

Step 4.2 Document generic product flows

Program design must be created before the program can be written and the program
specification must exist before the design can be commenced. These relationships can be
portrayed in a product Flow Diagram (PFD). ln the example in ,'user requirements ‘is in an
oval which means that it is used by the project but is not created by it. lt is often convenient to
identify an overall product at the bottom of the diagram, in this case 'integrated/tested
software', into which all the other products feed.
 Step 4.3 Recognize product instances

Step 4.4 Produce an ideal activity network

ln order to generate one product from another there must be one or more activities that carry
out the transformation. By identifying these activities we can create an activity network which
shows the tasks that have to be carried out and the order in which they have to be executed.

Step 4.5 Modify the ideal to take into account need for stages and checkpoints

5.Estimate effort for each activity

Step 5.1 Carry out bottom-up estimates

At this point, estimates of the staff effort required, the probable elapsed time and the non-
staff resources needed for each activity will need to be produced.

Step 5.2 Revise plan to create controllable activities

6. Identify activity risks

 Step 6.1 Identify and quantify activity-based risks

A project plan will be based on a huge number of assumptions, and so some way of picking
out the risks that are most important is needed. The damage that each risk could cause and the
likelihood of it occurring have to be gauged.

Step 6.2 Plan risk reduction and contingency measures where appropriate

It may be possible to avoid or at least reduce some of the identified risks. On the other hand,
contingency plans specify action that is to be taken if a risk materializes.

Step 6.3 Adjust overall plans and estimates to take account of risks

We may change our plans, perhaps by adding new activities which reduce risks

7. Allocate resources

Step 7.1 Identify and allocate resources

The type of staff needed for each activity is recorded. The staff available for the project are
identified and are provisionally allocated to tasks

Step 7.2 Revise plans and estimates to take into account resource constraints

Some staff may be needed for more than one task at the same time and, in this case, an order
of priority is established. The decisions made here may have an effect on the overall duration
of the project when some tasks are delayed while waiting for staff to become free

The Gantt chart gives a clear picture of when activities will actually place and highlights
which ones will be executed at the same
8. Review plan

Step 8.1 Review quality aspects of project plan

lt is important to know that when a task is reported as completed and hence quality reviews
are important . Each task should have quality criteria. These are quality checks that have to
be passed before the activity can be 'signed off' as completed

Step 8.2 Document plans and obtain agreement

It is important that the plans be carefully documented and that all the parties to the project
understand and agree to the commitments required of them in the plan.

9/10. Execute plan/lower levels of planning

Once the project is under way, plans will need to be drawn up in greater detail for each
activity as it becomes due. Detailed planning of the later stages will need to be delayed
because more information will be available nearer the start of the stage