Software project Management

4. PROJECT SCHEDULING AND TRACKING

4.1 BASIC CONCEPTS
There are many reasons why software is delivered late, most can be traced to one or more of the
following root causes:
• An unrealistic deadline was established by someone outside the software development
group and forced on managers and practitioner's within the group.
• Changing customer requirements that are not reflected in schedule changes.
• An honest underestimate of the amount of effort and/or the number of resources that will
be required to do the job
• Predictable and/or unpredictable risks that were not considered when the project
commenced
• Technical difficulties that could not have been foreseen in advance
• Human difficulties that could not have been foreseen in advance.
• Miscommunication among project staff results in delays.
• A failure by project management to recognize that the project is falling behind schedule
and a lack of action to correct the problem.
Aggressive (read "unrealistic") deadlines are a fact of life in the software business. Sometimes
such deadlines are demanded for legitimate reasons, from the point of view of the person who
sets the deadline. But common sense says that legitimacy must also be perceived by the people
doing the work.
4.1.1 Comments on “Lateness”
Assume that a software development group has been asked to build a real-time controller
for a medical diagnostic instrument that is to be introduced to the market in nine months. After
careful estimation and risk analysis, the software project manager concludes that the software, as
requested, will require 14 calendar months to create with available staff. How does the project
manager proceed?
It is unrealistic to march into the customer's office (in this case the likely customer is
marketing/sales) and demands that the delivery date be changed. External market pressures have
dictated the date, and the product must be released. It is equally foolhardy to refuse to undertake
the work (from a career standpoint). So, what to do?
The following steps are recommended in this situation:
1. Perform a detailed estimate using historical data from past projects. Determine the
estimated effort and duration for the project.
2. Using an incremental process model, develop a software engineering strategy that will
deliver critical functionality by the imposed deadline, but delay other functionality until
later. Document the plan.
3. Meet with the customer and (using the detailed estimate), explain why the imposed
deadline is unrealistic. Be certain to note that all estimates are based on performance on

1
 Software project Management

past projects. Also, be certain to indicate the percent improvement that would be required
to achieve the deadline as it currently exists. The following comment is appropriate:
"I think we may have a problem with the delivery date for the XYZ controller
software. I've given each of you an abbreviated breakdown of production rates for past
projects and an estimate that we've done several different ways. You'll note that I've
assumed a 20 percent improvement in past production rates, but we still get a delivery date
that's 14 calendar months rather than 9 months away."
4. Offer the incremental development strategy as an alternative:
“We have a few options, and I'd like you to make a decision based on them. First, we can
increase the budget and bring on additional resources so that we'll have a shot at getting
this job done in nine months. But understand that this will increase the risk of poor quality
due to the tight timeline. Second, we can remove a number of the software functions and
capabilities that you're requesting. This will make the preliminary version of the product
somewhat less functional, but we can announce all functionality and then deliver over
the 14 months. Third, we can dispense with reality and wish the project completed in nine
months. We'll wind up with nothing that can be delivered to a customer. The third option,
I hope you'll agree, is unacceptable. History and our best estimates say that it is unrealistic
and a recipe for disaster."
There will be some grumbling, but if solid estimates based on good historical data are presented,
negotiated versions of option 1 or 2 will likely be chosen. The unrealistic deadline evaporates
4.1.2 Basic Principles
The reality of a technical project (whether it involves building a hydroelectric plant or
developing an operating system) is that hundreds of small tasks must occur to accomplish a
larger goal. Some of these tasks lie outside the mainstream and may be completed without worry
about the impact on a project completion date. Other tasks lie on the "critical” path. If these
"critical" tasks fall behind schedule, the completion date of the entire project is put into jeopardy.
The project manager’s objective is to define all project tasks, build a network that depicts
their interdependencies, identify the tasks that are critical within the network, and then track their
progress to ensure that delay is recognized "one day at a time." To accomplish this, the manager
must have a schedule that has been defined at a degree of resolution that enables the manager to
monitor progress and control the project.
Software project scheduling is an activity that distributes estimated effort across the
planned project duration by allocating the effort to specific software engineering tasks. It is
important to note, however, that the schedule evolves. During the early stages of project
planning, a macroscopic schedule is developed. This type of schedule identifies all major
software engineering activities and the product functions to which they are applied. As the
project gets underway, each entry on the macroscopic schedule is refined into a detailed
schedule. Here, specific software tasks (required to accomplish an activity) are identified and
scheduled.

2
 Software project Management

Scheduling for software engineering projects can be viewed from two rather different
perspectives. In the first, an end date for the release of a computer-based system has already (and
irrevocably) been established. The software organization is constrained to distribute effort within
the prescribed time frame. The second view of software scheduling assumes that rough
chronological bounds have been discussed but that the end date is set by the software
engineering organization. The effort is distributed to make the best use of resources and the end
date is defined after careful analysis of the software. Unfortunately, the first situation is
encountered far more frequently than the second.
Like all other areas of software engineering, several basic principles guide software project
scheduling:
• Compartmentalization. The project must be compartmentalized into several
manageable activities and tasks. To accomplish compartmentalization, both the
product and the process are decomposed.
• Interdependency. The interdependency of each compartmentalized activity or
task must be determined. Some tasks must occur in sequence while others can
occur in parallel. Some activities cannot commence until the work product
produced by another is available. Other activities can occur independently.
• Time allocation. Each task to be scheduled must be allocated some number of
work units (e.g., person-days of effort). In addition, each task must be assigned a
start date and a completion date that are a function of the interdependencies and
whether work will be conducted on a full-time or part-time basis.
• Effort validation. Every project has a defined number of staff members. As time
allocation occurs, the project manager must ensure that no more than the allocated
number of people has been scheduled at any given time. For example, consider a
project that has three assigned staff members (e.g., 3 person-days are available per
day of assigned effort). On a given day, seven concurrent tasks must be
accomplished. Each task requires 0.50 person-days of effort. More effort has been
allocated than there are people to do the work.
• Defined responsibilities. Every task that is scheduled should be assigned to a
specific team member.
• Defined outcomes. Every task that is scheduled should have a defined outcome.
For software projects, the outcome is normally a work product (e.g., the design of
a module) or a part of a work product. Work products are often combined with
deliverables.
• Defined milestones. Every task or group of tasks should be associated with a
project milestone. A milestone is accomplished when one or more work products
have been reviewed for quality and have been approved.
Each of these principles is applied as the project schedule evolves.

3
 Software project Management

4.2 THE RELATIONSHIP BETWEEN PEOPLE AND EFFORT

In a small software development project, a single person can analyze requirements,
perform design, generate code, and conduct tests. As the size of a project increases, more people
must become involved. (We can rarely afford the luxury of approaching a ten-person-year effort
with one person working for ten years!)
There is a common myth that is still believed by many managers who are responsible for
software development efforts: "If we fall behind schedule, we can always add more programmers
and catch up later in the project." Unfortunately, adding people late to a project often has a
disruptive effect on the project, causing schedules to slip even further. The people who are added
must learn the system, and the people who teach them are the same people who were doing the
work. While teaching, no work is done, and the project falls further behind.
In addition to the time it takes to learn the system, more people increase the number of
communication paths and the complexity of communication throughout a project. Although
communication is essential to successful software development, every new communication path
requires additional effort and therefore additional time.
4.2.1 An Example
Consider four software engineers, each capable of producing 5000 LOC/year when
working on an individual project. When these four engineers are placed on a team project, six
potential communication paths are possible. Each communication path requires time that could
otherwise be spent developing software. We shall assume that team productivity (when measured
in LOC) will be reduced by 250 LOC/year for each communication path, due to the overhead
associated with the communication. Therefore, team productivity is 20,000 - (250 x 6) = 18,500
LOC/year 7.5 percent less than what we might expect.
The one-year project on which the team is working falls behind schedule, and with two
months remaining, two additional people are added to the team. The number of communication
paths escalates to 14. The productivity input of the new staff is the equivalent of 840 x 2 = 1680
LOC for the two months remaining before delivery. Team productivity now is 20,000 + 1680 -
(250 x 14) = 18,180 LOC/year.
Although the example is a gross oversimplification of real-world circumstances, it does
illustrate another key point: The relationship between the number of people working on a
software project and overall productivity is not linear. Based on the people/work relationship, is
a team counterproductive? The answer is an emphatic "no," if communication improves software
quality. Formal technical reviews conducted by software teams can lead to better analysis and
design, and more importantly, can reduce the number of errors that go undetected until testing
(thereby reducing testing effort). Hence, productivity and quality, when measured by time to
project completion and customer satisfaction, can improve
4.3 DEFINING A TASK SET FOR THE SOFTWARE PROJECT
No single set of tasks is appropriate for all projects. The set of tasks that would be
appropriate for a large, complex system would likely be perceived as overkill for a small,

4
 Software project Management

relatively simple software product. Therefore, an effective software process should define a
collection of task sets, each designed to meet the needs of different types of projects.
A task set is a collection of software engineering work tasks, milestones, and deliverables
that must be accomplished to complete a particular project. The task set to be chosen must
provide enough discipline to achieve high software quality. But, at the same time, it must not
burden the project team with unnecessary work
Task sets are designed to accommodate different types of projects and different degrees
of rigor. Although it is difficult to develop a comprehensive taxonomy of software project types,
most software organizations encounter the following projects:
1. Concept development projects are initiated to explore some new business concept or
application of some new technology.
2. New application development projects are undertaken as a consequence of a specific
customer request.
3. Application enhancement projects occur when existing software undergoes major
modifications to function, performance, or interfaces that are observable by the end-user.
4. Application maintenance projects that correct, adapt, or extend existing software in ways
that may not be immediately obvious to the end-user.
5. Reengineering projects are undertaken with the intent of rebuilding an existing (legacy)
system in whole or in part.
Even within a single project type, many factors influence the task set to be chosen. When
taken in combination, these factors indicate the degree of rigor with which the software process
should be applied. The degree of rigor is a function of many project characteristics. As an
example, small, non-business-critical projects can generally be addressed with somewhat less
rigor than large, complex business-critical applications. It should be noted, however, that all
projects must be conducted in a manner that results in timely, high-quality deliverables.
Four different degrees of rigor can be defined:
Casual. All process framework activities are applied, but only a minimum task set is required. In
general, umbrella tasks will be minimized and documentation requirements will be reduced. All
basic principles of software engineering are still applicable.
Structured. The process framework will be applied for this project. Framework activities and
related tasks appropriate to the project type will be applied and umbrella activities necessary to
ensure high quality will be applied. software quality assurance (SQA) and software configuration
management (SCM), documentation, and measurement tasks will be conducted in a streamlined
manner.
Strict. The full process will be applied for this project with a degree of discipline that will ensure
high quality. All umbrella activities will be applied and robust work products will be produced.
Quick reaction. The process framework will be applied for this project, but because of an
emergency, only those tasks essential to maintaining good quality will be applied. “Back-filling”
(i.e., developing a complete set of documentation, conducting additional reviews) will be
accomplished after the application/product is delivered to the customer

5
 Software project Management

The project manager must develop a systematic approach for selecting the degree of rigor
that is appropriate for a particular project. To accomplish this, project adaptation criteria are
defined and a task set selector value is computed.
4.3.1 Defining Adaptation Criteria
Adaptation criteria are used to determine the recommended degree of rigor with which the
software process should be applied to a project. Eleven adaptation criteria are defined for
software projects:
1. Size of the project
2. Number of potential users
3. Mission criticality
4. Application longevity
5. Stability of requirements
6. Ease of customer/developer communication
7. Maturity of applicable technology
8. Performance constraints
9. Embedded and non-embedded characteristics
10. Project staff
11. Reengineering factors
Each of the adaptation criteria is assigned a grade that ranges between 1 and 5, where 1
represents a project in which a small subset of process tasks are required and overall
methodological and documentation requirements are minimal, and 5 represents a project in
which a complete set of process tasks should be applied and overall methodological and
documentation requirements are substantial
4.4 SELECTING SOFTWARE ENGINEERING TASKS
To develop a project schedule, a task set must be distributed on the project timeline. As
we noted, the task set will vary depending upon the project type and the degree of rigor. Each of
the project types may be approached using a process model that is linear sequential, iterative
(e.g., the prototyping or incremental models), or evolutionary (e.g., the spiral model). In some
cases, one project type flows smoothly into the next. For example, concept development projects
that succeed often evolve into new application development projects. As a new application
development project ends, an application enhancement project sometimes begins. This
progression is both natural and predictable and will occur regardless of the process model that is
adopted by an organization. Therefore, the major software engineering tasks described in the
sections that follow apply to all process model flows. As an example, we consider the software
engineering tasks for a concept development project.
Concept development projects are initiated when the potential for some new technology
must be explored. There is no certainty that the technology will be applicable, but a customer
(e.g., marketing) believes that potential benefit exists.

6
 Software project Management

Concept development projects are approached by applying the following major tasks:
Concept scoping determines the overall scope of the project.
Preliminary concept planning establishes the organization’s ability to undertake the
work implied by the project scope.
Technology risk assessment evaluates the risk associated with the technology to be
implemented as part of the project scope.
Proof of concept demonstrates the viability of new technology in the software context.
Concept implementation implements the concept representation in a manner that can be
reviewed by a customer and is used for “marketing” purposes when a concept must be
sold to other customers or management.
Customer reaction to the concept solicits feedback on a new technology concept and
targets specific customer applications.
4.5 DEFINING A TASK NETWORK
Individual tasks and subtasks have interdependencies based on their sequence. In
addition, when more than one person is involved in a software engineering project, development
activities and tasks will likely be performed in parallel. When this occurs, concurrent tasks must
be coordinated so that they will be complete when later tasks require their work product(s).
A task network also called an activity network, is a graphic representation of the task flow
for a project. It is sometimes used as the mechanism through which task sequence and
dependencies are input to an automated project scheduling tool.
The concurrent nature of software engineering activities leads to several important
scheduling requirements. Because parallel tasks occur asynchronously, the planner must
determine intertask dependencies to ensure continuous progress toward completion. In addition,
the project manager should be aware of those tasks that lie on the critical path. That is tasks that
must be completed on schedule if the project as a whole is to be completed on schedule.

FIGURE 4.1 A task network for concept development

7
 Software project Management

as a whole is to be completed on schedule. It is important to note that the task network shown in
Figure 4.1 is macroscopic. In a detailed task network (a precursor to a detailed schedule), each
activity shown in Figure 4.1 would be expanded.
Tracking the Schedule
The project schedule provides a road map for a software project manager. If it has been
properly developed, the project schedule defines the tasks and milestones that must be tracked
and controlled as the project proceeds. Tracking can be accomplished in several different ways:
• Conducting periodic project status meetings in which each team member reports progress
and problems.
• Evaluating the results of all reviews conducted throughout the software engineering
process.
• Determining whether formal project milestones have been accomplished by the scheduled
date.
• Comparing the actual start date to the planned start date for each project task
• Meeting informally with practitioners to obtain their subjective assessment of progress to
date and problems on the horizon.
• Using earned value analysis to assess progress quantitatively.
In reality, all of these tracking techniques are used by experienced project managers. Control
is employed by a software project manager to administer project resources, cope with problems,
and direct project staff. If things are going well (i.e., the project is on schedule and within
budget, reviews indicate that real progress is being made and milestones are being reached),
control is light. But when problems occur, the project manager must exercise control to reconcile
them as quickly as possible. After a problem has been diagnosed, additional resources may be
focused on the problem area: staff may be redeployed or the project schedule can be redefined
4.6 EARNED VALUE ANALYSIS
The earned value system provides a common value scale for every [software project]
task, regardless of the type of work being performed. The total hours to do the whole project are
estimated, and every task is given an earned value based on its estimated percentage of the total
Stated even more simply, earned value is a measure of progress. It enables us to assess the
“percent of completeness” of a project using quantitative analysis rather than relying on a gut
feeling.
To determine the earned value, the following steps are performed:
1. The budgeted cost of work scheduled (BCWS) is determined for each work task
represented in the schedule. During the estimation activity, the work (in person-hours or
person-days) of each software engineering task is planned. Hence, BCWSi is the effort
planned for work task i. To determine progress at a given point along with the project
schedule, the value of BCWS is the sum of the BCWSi values for all work tasks that
should have been completed by that point in time on the project schedule.

8
 Software project Management

2. The BCWS values for all work tasks are summed to derive the budget at completion,
BAC. Hence,
BAC = ∑(BCWSk) for all tasks k
3. Next, the value for the budgeted cost of work performed (BCWP) is computed. The
value for BCWP is the sum of the BCWS values for all work tasks that have
been completed by a point in time on the project schedule.
the distinction between the BCWS and the BCWP is that the former represents the budget of the
activities that were planned to be completed and the latter represents the budget of the activities
that were completed.” Given values for BCWS, BAC, and BCWP, important progress indicators
can be computed:
Schedule performance index, SPI = BCWP/BCWS
Schedule variance, SV = BCWP – BCWS
SPI is an indication of the efficiency with which the project is utilizing scheduled resources. An
SPI value close to 1.0 indicates the efficient execution of the project schedule. SV is simply an
absolute indication of variance from the planned schedule.
Percent scheduled for completion = BCWS/BAC
indicates the percentage of work that should have been completed
by time t.
Percent complete = BCWP/BAC
provides a quantitative indication of the percent of completeness of the project at a
given point in time, t.
It is also possible to compute the actual cost of work performed, ACWP. The value
for ACWP is the sum of the effort expended on work tasks that have been
completed by a point in time on the project schedule. It is then possible to compute
Cost performance index, CPI = BCWP/ACWP
Cost variance, CV = BCWP – ACWP
A CPI value close to 1.0 provides a strong indication that the project is within its defined budget.
CV is an absolute indication of cost savings (against planned costs) or shortfall at a particular
stage of a project. Like over-the-horizon radar, earned value analysis illuminates scheduling
difficulties before they might otherwise be apparent. This enables the software project manager
to take corrective action before a project crisis develops.
4.7 ERROR TRACKING
Throughout the software process, a project team creates work products (e.g.,
requirements specifications or prototypes, design documents, source code). But the team also
creates (and hopefully corrects) errors associated with each work product. If error-related
measures and resultant metrics are collected over many software projects, a project manager can
use these data as a baseline for comparison against error data collected in real-time. Error
tracking can be used as one means of assessing the status of a current project
To review, the software team performs formal technical reviews (and, later, testing) to
find and correct errors, E, in work products produced during software engineering tasks.

9
 Software project Management

Any errors that are not uncovered (but found in later tasks) are considered to be defects, D.
Defect removal efficiency has been defined as
DRE = E/(E + D)
DRE is a process metric that provides a strong indication of the effectiveness of quality
assurance activities, but DRE and the error and defect counts associated with it can also be used
to assist a project manager in determining the progress that is being made as a software project
moves through its scheduled work tasks.
Let us assume that a software organization has collected error and defect data
over the past 24 months and has developed averages for the following metrics:
• Errors per requirements specification page, Ereq
• Errors per component—design level, Edesign
• Errors per component—code level, Ecode
• DRE—requirements analysis
• DRE—architectural design
• DRE—component level design
• DRE—coding
As the project progresses through each software engineering step, the software team records and
reports the number of errors found during requirements, design, and code reviews. The project
manager calculates current values for Ereq, Edesign, and Ecode. These are then compared to averages
for past projects. If current results vary by more than 20% from the average, there may be cause
for concern and there is certainly cause for investigation.

10