project management begins with a set of activities that are collectively called
THE MANAGEMENT SPECTRUM
Effective software project management
focuses on the four P’s: people,
product, process, and project.
cultivation of motivated, highly skilled software people has been discussed
since the 1960s (e.g., [COU80], [WIT94], [DEM98]).
people management maturity model defines the following key practice areas for
software people: recruiting, selection, performance management, training,
compensation, career development, organization and work design, and
a project can be planned, product1 objectives and scope should be established,
alternative solutions should be considered, and technical and management
constraints should be identified.
·Without this information, it is impossible to
define reasonable (and accurate) estimates of the cost, an effective assessment
of risk, a realisticbreakdown of project tasks, or a manageable project
schedule that provides a meaningfulindication of progress.
software developer and customer must meet to define product objectives
identifies the primary data, functions and behaviors that characterizethe
product, and more important, attempts to bound these
characteristics in a quantitative manner.
the product objectives and scope are understood, alternative solutions
software process provides the framework from which a comprehensive plan for
software development can be established.
·A small number of framework activities are
applicable to all software projects, regardless of their size or complexity.
number of different task sets—tasks, milestones, work products, and quality
assurance points—enable the framework activities to be adapted to the
characteristics of the software project and the requirements of the project
activities—such as software quality assurance, software configuration
management, and measurement—overlay the process model.
activities are independent of any one framework activity and occur throughout
conduct planned and controlled software projects for one primary reason—it is the
only known way to manage complexity. And yet, we still struggle.
·In 1998, industry data indicated that 26 percent
of software projects failed outright and 46 percent experienced cost and
schedule overruns [REE99].
the success rate for software projects has improved somewhat, our project
failure rate remains higher than it should be.2
order to avoid project failure, a software project manager and the software
engineers who build the product must avoid a set of common warning signs,
understand the critical success factors that lead to good project management,
and develop a commonsense
for planning, monitoring and controlling the project.
THE W5HH PRINCIPLE:
an excellent paper on software process and projects, Barry Boehm [BOE96]
need an organizing principle that scales down to provide simple [project] plans
for simple projects.” Boehm suggests an approach that addresses project
objectives, milestones and schedules, responsibilities, management and
technical approaches, and required resources.
calls it the WWWWWHH principle, after a series of questions that lead to a
definition of key project characteristics and the resultant project plan:
is the system being developed?
answer to this question enables all parties to assess the validity of business
reasons for the software work. Stated in another way, does the business purpose
justify the expenditure of people, time, and money?
will be done, by when?
The answers to these questions help the team to establish a
project schedule by identifying key project tasks and the milestones that are
required by the customer.
is responsible for a function?
we noted that the role and responsibility of each member of the
software team must be defined.
are they organizationally located?
Not all roles and responsibilities reside within the software
team itself. The customer, users, and other stakeholders
also have responsibilities.
will the job be done technically and managerially? Once
product scope is established, a management and technical strategy for the
project must be defined.
much of each resource is needed?
The answer to this question is derived by developing
estimatesbased on answers
to earlier questions.
W5HH principle is applicable regardless of the size or complexity of a software
project. The questions noted provide an excellent planning outline for the
project manager and the software team.
Software project management begins with a set of activities that
are collectivelycalled project planning.
1.PROJECT PLANNING OBJECTIVES
The objective of software project planning is to provide a
framework that enables the manager to make reasonable estimates of resources,
cost, and schedule.
These estimates are made within a limited time frame at the
beginning of a software project and should be updated regularly as the project
The planning objective is achieved through a process of
information discovery that leads to
Software scope describes the data and control
to be processed, function, performance,
constraints, interfaces, and reliability.
Functions described in the statement of scope are evaluated and
in some cases refined to provide more detail prior to the beginning of estimation.
Because both cost and schedule estimates are functionally oriented, some degree
of decomposition is often useful.
Performance considerations encompass processing and response time
Constraints identify limits placed on the software by external
hardware, available memory, or other existing systems.
Necessary for Scope:
The most commonly used technique to bridge the communication gap
between the customer and developer and to get the communication process started
is to conduct a preliminary meeting or interview.
The first meeting between the software engineer (the analyst) and
the customer can be likened to the awkwardness of a first date between two
adolescents. Neither person knows what to say or ask; both are worried that
what they do say will be misinterpreted; both are thinking about where it might
lead (both likely have radically different expectations here); both want to get
the thing over with; but at the same time, both want it to be a success.
Yet, communication must be initiated. Gause and Weinberg [GAU89] suggest
that the analyst start by asking context-free questions; that
is, a set of questions that will lead to a basic understanding of the problem,
the people who want a solution, the nature of the solution desired, and the
effectiveness of the first encounter itself.
The first set of context-free questions focuses on the customer,
the overall goals and benefits.
For example, the analyst might ask:
is behind the request for this work?
will use the solution?
will be the economic benefit of a successful solution?
there another source for the solution?
The next set of questions enables the analyst to gain a better
understanding of the problem and the customer to voice any perceptions about a
would you (the customer) characterize "good" output that would be generated
by a successful solution?
problem(s) will this solution address?
you show me (or describe) the environment in which the solution will be used?
any special performance issues or constraints affect the way the solution is
a number of
independent investigators have developed a team-oriented approach to
requirements gathering that can be applied to help establish the scope of a
project. Called facilitated application specification techniques (FAST).
software feasibility has four solid dimensions:
Is a project technically feasible?
Is it within the state of the art?
Can defects be reduced to a level matching the application’s
Is it financially feasible?
Can development be completed at a cost the software organization,
its client, or the market can afford?
Will the project’s time-to-market beat the competition?
Does the organization have the resources needed to succeed?
3.SOFTWARE PROJECT ESTIMATION
Software cost and effort estimation will never be an exact
Too many variables— human, technical, environmental,
political—can affect the ultimate cost of software and effort applied to
develop it. However, software project estimation can be transformed from a
black art to a series of systematic steps that provide estimates with
To achieve reliable cost and effort estimates, a number of
vDelay estimation until late in the project (obviously, we can
achieve 100% accurate estimates after the project is complete!).
vBase estimates on similar projects that have already been
vUse relatively simple decomposition techniques to generate
project cost and effort estimates.
vUse one or more empirical models for software cost and effort estimation.
4.AUTOMATED ESTIMATION TOOLS
Although many automated estimation tools exist, all exhibit the
same general characteristics and all perform the following six generic
Sizing of project deliverables:-
“size” of one or more software work products is estimated. Work products
include the external representation of software (e.g., screen, reports), the
software itself (e.g., KLOC), functionality delivered (e.g., function points), descriptive
information (e.g. documents).
appropriate process framework is selected and the software engineering task set
Predicting staffing levels:-
The number of people who will be available to do the work is
specified. Because the relationship between people available and work
(predicted effort) is highly nonlinear, this is an important input.
Predicting software effort:-
Estimation tools use one or more models that relate the size of
the project deliverables to the effort required to produce them.
Predicting software cost:-
Given the results of step 4, costs can be computed by allocating
labor rates to the project activities noted in step 2.
Predicting software schedules:-
When effort, staffing level, and project activities are known, a
draft schedule can be produced by allocating labor across software engineering
activities based on recommended models for effort distribution.
Risk always involves two characteristics:
risk may or may not happen; that is, there are no 100% probable risks.
risk becomes a reality, unwanted consequences or losses will occur.
are analyzed, it is important to quantify the level of uncertainty and the
degree of loss associated with each risk.
risks threaten the project plan. That is, if project risks become real,
it is likely that project schedule will slip and that costs will increase.
risks identify potential budgetary, schedule, personnel (staffing and
organization), resource, customer, and requirements problems and their impact
on a software project.
Technical risks threaten the quality and
timeliness of the software to be produced.
technical risk becomes a reality, implementation may become difficult or
Business risks threaten the viability of the
software to be built. Business risks often jeopardize the project or the
for the top five business risks are
a excellent product or system that no one really wants (market risk)
a product that no longer fits into the overall business strategy for the
company (strategic risk)
a product that the sales force doesn't understand how to sell
the support of senior management due to a change in focus or
a change in people (management risk)
budgetary or personnel commitment (budget risks).
Risk identification is
a systematic attempt to specify threats to the project plan (estimates, schedule,
resource loading, etc.).
two distinct types of risks for each of the categories that have been presented
in Section software risk: generic risks and product-specific risks.
risks are a potential threat to every software project.
risks can be identified only by those with a clear under-standing of
the technology, the people, and the environment that is specific to the project
for identifying risks is to create a risk
item checklist. The checklist can be used for risk identification and focuses on
some subset of known and predictable risks in the following generic
vProduct size—risks associated with the
overall size of the software to be built or modified.
vBusiness impact—risks associated with
constraints imposed by management or the marketplace.
associated with the sophistication of the customer and the developer's ability
to communicate with the customer in a timely manner.
associated with the degree to which the software process has been defined and
is followed by the development organization.
associated with the availability and quality of the tools to be used to build
vTechnology to be built—risks
associated with the complexity of the system to be built and the
"newness" of the technology that is packaged by the system.
vStaff size and experience—risks
associated with the overall technical and project experience of the software
engineers who will do the work.
At this point in the risk management process, we have established
a set of triplets of the form :
[ri, li, xi]
Where ri is
risk, li is
the likelihood (probability) of the risk, and xi is the impact of the risk.
During risk assessment, we further examine the accuracy of the estimates
that were made during risk projection, attempt to rank the risks that have been
uncovered, and begin thinking about ways to control and/or avert risks that are
likely to occur.
For most software projects, the risk components discussed earlier
performance, cost, support, and schedule also represent risk referent levels.
That is, there is a level for performance degradation, cost
overrun, support difficulty, or schedule slippage (or any combination of the
four) that will cause the project to be terminated.
If a combination of risks create problems that cause one or more
of these referent levels to be exceeded, work will stop.
Risk Reference level
during risk assessment, we perform the following steps:
the risk referent levels for the project.
to develop a relationship between each (ri, li, xi)
and each of the referent levels.
the set of referent points that define a region of termination, bounded by a
curve or areas of uncertainty.
to predict how compound combinations of risks will affect a referent level.
8.RISK MITIGATION, MONITORING, AND
All of the risk analysis activities presented to this point have
a single goal to assist the project team in developing a strategy for dealing
with risk. An effective strategy must consider three issues:
vrisk management and contingency planning
If a software team adopts a proactive approach to risk, avoidance
is always the best strategy. This is achieved by developing a plan for risk mitigation.
example, assume that high staff turnover is noted as a project risk, r1. Based on past history and management
intuition, the likelihood, l1, of high
turnover is estimated to be 0.70 and the impact, x1,
is projected at level 2.
high turnover will have a critical impact on project cost and schedule.
this risk, project management must develop a strategy for reducing turnover.
possible steps to be taken are
with current staff to determine causes for turnover (e.g., poor working conditions,
low pay, competitive job market).
those causes that are under our control before the project starts.
the project commences, assume turnover will occur and develop techniques to
ensure continuity when people leave.
project teams so that information about each development activity is widely
documentation standards and establish mechanisms to be sure that documents are
developed in a timely manner.
peer reviews of all work
a backup staff member for every critical technologist.
monitoring activities commence. The project manager monitors factors that may
provide an indication of whether the risk is becoming more or less likely. In
the case of high staff turnover,
following factors can be monitored:
attitude of team members based on project pressures.
degree to which the team has jelled.
relationships among team members.
problems with compensation and benefits.
availability of jobs within the company and outside it.
Risk management and contingency planning assumes
that mitigation efforts have failed and that the risk has become a reality.
the example, the project is well underway and a number of people announce that
they will be leaving.
mitigation strategy has been followed, backup is available, information is
documented, and knowledge has been dispersed across the team.
important to note that RMMM steps incur additional project cost.
time to "backup" every critical technologist costs money. Part of
management, therefore, is to evaluate when the benefits accrued by the RMMM steps
are outweighed by the costs associated with implementing them.
the project planner performs a classic cost/benefit analysis. If risk aversion
steps for high turnover will increase both project cost and duration by an
estimated 15 percent, but the predominant cost factor is "backup,"
management may decide not to implement this step.
other hand, if the risk aversion steps are projected to increase costs by 5
percent and duration by only 3 percent management will likely put all into
9.THE RMMM PLAN
A risk management strategy can be included in the software
project plan or the risk management steps can be organized into a separate Risk Mitigation, Monitoring andManagement Plan.
The RMMM plan documents all work performed as part of risk analysis
and is used by the project manager as part of the overall project plan.
Some software teams do not develop a formal RMMM document.
Rather, each risk is documented individually using a risk information sheet (RIS).
In most cases, the RIS is maintained using a database system, so
that creation and information entry, priority ordering, searches, and other
analysis may be accomplished easily.
Once RMMM has been documented and the project has begun, risk
mitigation and monitoring steps commence. As we have already discussed, risk
mitigation is a problem avoidance activity.
Risk monitoring is a project tracking activity with three primary
vTo assess whether predicted risks do, in fact, occur
vTo ensure that risk aversion steps defined for the risk are being
vTo collect information that can be used for future risk analysis.
In many cases, the problems that occur during a project can be traced to more
than one risk.
Another job of risk monitoring is to attempt to allocate origin.