Software Project management

Software project management is an essential part of software engineering. Good management cannot
guarantee project success. However, bad management usually results in project failure: The software is
delivered late, costs more than originally estimated and fails to meet its requirements.

Software managers are responsible for planning and scheduling project development.
They supervise the work to ensure that it is carried out to the required standards and monitor progress to
check that the development is on time and within budget. We need software project management
because professional software engineering is always subject to organizational budget and schedule
constraints. The software project manager's job is to ensure that the software project meets these
constraints and delivers software that contributes to the goals of the company developing the software.
Software managers do the same kind of job as other engineering project managers.
However, software engineering is different from other types of engineering in a number of ways. These
distinctions make software management particularly difficult. Some of the differences are:

1. The product is intangible

The manager of a shipbuilding project or of a civil engineering project can see the product being
developed. If a schedule slips, the effect on the product is visible-parts of the structure are obviously
unfinished. Software is intangible. It cannot be seen or touched. Software project managers cannot see
progress. They rely on others to produce the documentation needed to review progress.

2. There are no standard software processes

In engineering disciplines with a long history, the process is tried and tested. The engineering process for
some types of system, such as bridges and buildings is well understood. However, software processes vary
dramatically from one organisation to another. Although our understanding of these processes has
developed significantly in the past few years, we still cannot reliably predict when a particular software
process is likely to cause development problems. This is especially true when the software project is part
of a wider systems engineering project.

3. Large software projects are often 'one-off projects

Large software projects are usually different in some ways from previous projects. Therefore, even
managers who have a large body of previous experience may find it difficult to anticipate problems.
Furthermore, rapid technological changes in computers and communications can make a manager's
experience obsolete. Lessons learned from previous projects may not be transferable to new projects.

1
Because of these problems, it is not surprising that some software projects are late, over budget and
behind schedule. Software systems are often new and technically innovation.

Three important management activities: project planning, project scheduling and risk management. Other
aspects of software management, including managing people, software cost estimation and quality
management.

Management activities
It is impossible to write a standard job description for a software manager. The job varies tremendously
depending on the organization and the software product being developed. However, most managers take
responsibility at some stage for some or all of the following activities:
o Proposal writing
o Project planning and scheduling
o Project cost
o Project monitoring and reviews
o Personnel selection and evaluation
o Report writing and presentations

NB:
Project managers usually have to select people to work on their project. Ideally, skilled staff with
appropriate experience will be available to work on the project.
However, in most cases, managers have to settle for a less-than-ideal project team.
The reasons for this are:
1. The project budget may not cover the use of highly paid staff. Less experienced, less well-paid staff may
have to be used.
2. Staff with the appropriate experience may not be available either within an organization or externally.
It may be impossible to recruit new staff to the project. Within the organization, the best people may
already be allocated to other projects.
3. The organization may wish to develop the skills of its employees, Inexperienced staff may be assigned
to a project to learn and to gain experience.

Project planning
Effective management of a software project depends on thoroughly planning the progress of the project.
Managers must anticipate problems that might arise and prepare tentative solutions to those problems. A

2
plan, drawn up at the start of a project, should be used as the driver for the project. This initial plan
should be the best possible plan given the available information. It evolves as the project progresses and
better information becomes available.
At the beginning of a planning process, you should assess the constraints (required delivery date, staff
available, overall budget, etc.) affecting the project. In conjunction with this, you should estimate project
parameters such as its structure, size, and distribution of functions. You next define the progress
milestones and deliverable

The project plan

The project plan sets out the resources available to the project, the work breakdown and a schedule for
carrying out the work.
The details of the project plan vary depending on the type of project and organisation.

However, most plans should include the following sections:

1. Introduction This briefly describes the objectives of the project and sets out the constraints (e.g.,
budget, time, etc.) that affect the project management.
2. Project organization This describes the way in which the development team is organised, the people
involved and their roles in the team.
3. Risk analysis This describes possible project risks, the likelihood of these risks arising and the risk
reduction strategies that are proposed. I explain the principles of risk management in Section 5.4.
4. Hardware and software resource requirements This specifies the hardware and the support software
required to carry out the development. If hardware has to be bought, estimates of the prices and the
delivery schedule may be included.
5. Work breakdown This sets out the breakdown of the project into activities and identifies the
milestones and deliverables associated with each activity.
6. Project schedule This shows the dependencies between activities, the estimated time required to reach
each milestone and the allocation of people to activities.
7. Monitoring and reporting mechanisms This defines the management reports that should be produced,
when these should be produced and the project monitoring mechanisms used.

Milestones and deliverables

Because software is intangible, this information can only be provided as reports and documents that
describe the state of the software being developed. Without this information, it is impossible to assess
how well the work is progressing, and cost estimates and schedules cannot be updated.

3
When planning a project, you should establish a series of milestones, where a milestone is a recognisable
end-point of a software process activity. At each milestone, there should be a formal output, such as a
report, that can be presented to management. Milestone reports need not be large documents. They may
simply be a short report of what has been completed. Milestones should represent the end of a distinct,
logical stage in the project. Indefinite milestones such as 'Coding 80% complete' that can't be checked are
useless for project management. You can't check whether this state has been achieved because the
amount of code that still has to be developed is uncertain.
A deliverable is a project result that is delivered to the customer. It is usually delivered at the end of some
major project phase such as specification or design.
Deliverables are usually milestones, but milestones need not be deliverables.

Project scheduling
Project scheduling is one of the most difficult jobs for a project manager. Managers estimate the time and
resources required to complete activities and organize them into a coherent sequence. Unless the project
being scheduled is similar to a previous project, previous estimates are an uncertain basis for new project
scheduling.
Schedule estimation is further complicated by the fact that different projects may use different design
methods and implementation languages.
Project scheduling involves separating the total work involved in a project into separate activities and
judging the time required to complete these activities. Usually, some of these activities are carried out in
parallel. You have to coordinate these parallel activities and organize the work so that the workforce is
used optimally. It's important to avoid a situation where the whole project is delayed because a critical
task is unfinished.

Software Risk management

Risk management is increasingly seen as one of the main jobs of project managers.
It involves anticipating risks that might affect the project schedule or the quality of the software being
developed and taking action to avoid these risks
The results of the risk analysis should be documented in the project plan along with an analysis of the
consequences of a risk occurring. Effective risk management makes it easier to cope with problems and to
ensure that these do not lead to unacceptable budget or schedule slippage.

There are, therefore, three related categories of risk:

4
1. Project risks are risks that affect the project schedule or resources. An example might be the loss of an
experienced designer.
2. Product risks are risks that affect the quality or performance of the software being developed. An
example might be the failure of a purchased component to perform as expected.
3. Business risks are risks that affect the organization developing or procuring the software. For example,
a competitor introducing a new product is a business risk.

Risk management is particularly important for software projects because of the inherent uncertainties
that most projects face. These stem from
1. Loosely defined requirements,
2. difficulties in estimating the time and resources required for software development,
3. dependence on individual skills and
4. Requirements changes due to changes in customer needs.

The process of risk management is illustrated in Figure 5.10. It involves several stages:

5
1. Risk identification Possible project, product and business risks are identified.
2. Risk analysis The likelihood and consequences of these risks are assessed.
3. Risk planning Plans to address the risk either by avoiding it or minimizing its effects on the project are
drawn up.
4. Risk monitoring the risk is constantly assessed and plans for risk mitigation are revised as more
information about the risk becomes available.

You should document the outcomes of the risk management process in a risk management plan. This
should include a discussion of the risks faced by the project, an analysis of these risks and the plans that
are required to manage these risks.

There are at least six types of risk that can arise:

1. Technology risks
Risks that derive from the software or hardware technologies that are used to develop the system
2. People risks
Risks that are associated with the people in the development team.
3. Organizational risks
Risks that derive from the organizational environment where the software is being developed.
4. Tools risks
Risks that derive from the CASE tools and other support software used to develop the system.
5. Requirements risks
Risks that derive from changes to the customer requirements and the process of managing the
requirements change.
6. Estimation risks
Risks that derive from the management estimates of the system characteristics and the resources
required to build the system.