Applied Software Project Management
Software Project Management
Introduction
http://www.stellman-greene.com
1
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Why do software projects fail?
People begin programming before they
understand the problem
Everyone likes to feel that they’re making progress
When the team starts to code as soon as the project
begins, they see immediate gains
When problems become more complex (as they
always do!), the work gets bogged down
In the best case, a team that begins programming too
soon will end up writing good software that solves the
wrong problem
http://www.stellman-greene.com
2
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Why do software projects fail?
The team has an unrealistic idea about
how much work is involved.
From far away, most complex problems seem
simple to solve
Teams can commit to impossible deadlines by
being overly optimistic and not thinking
through the work
Few people realize the deadline is optimistic
until it’s blown
http://www.stellman-greene.com
3
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Why do software projects fail?
Defects are injected early but discovered late.
Projects can address the wrong needs
Requirements can specify incorrect behavior
Design, architecture and code can be technically
flawed
Test plans can miss functionality
The later these problems are found, the more likely
they are to cause the project to fail
http://www.stellman-greene.com
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Why do software projects fail?
Programmers have poor habits – and they don’t
feel accountable for their work.
Programmers don’t have good control of their source
code
Code written by one person is often difficult for another
person to understand
Programmers don’t test their code, which makes
diagnosing and fixing bugs more expensive
The team does not have a good sense of the overall
health of the project.
http://www.stellman-greene.com
5
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Why do software projects fail?
Managers try to test quality into the software.
Everyone assumes that the testers will catch all of the
defects that were injected throughout the project.
When testers look for defects, managers tell them they
are wasting time.
When testers find defects, programmers are
antagonized because they feel that they are being
personally criticized.
When testers miss defects, everyone blames them for
not being perfect.
http://www.stellman-greene.com
6
Andrew Stellman & Jennifer Greene
Applied Software Project Management
How can we make sure that our
projects succeed?
Make sure all decisions are based on openly
shared information
It’s important to create a culture of transparency,
where everyone who needs information knows where
to find it and is comfortable looking at it.
All project documents, schedules, estimates, plans
and other work products should be shared with the
entire team, managers, stakeholders, users and
anyone else in the organization who wants them.
Major decisions that are made about the project
should be well-supported and explained.
http://www.stellman-greene.com
7
Andrew Stellman & Jennifer Greene
Applied Software Project Management
How can we make sure that our
projects succeed?
Don’t second-guess your team members’
expertise
Managers need to trust team members.
Just because a manager has responsibility for
a project’s success, it doesn’t mean that he’s
more qualified to make decisions than the
team members.
If you don’t have a good reason to veto an
idea, don’t.
http://www.stellman-greene.com
8
Andrew Stellman & Jennifer Greene
Applied Software Project Management
How can we make sure that our
projects succeed?
Introduce software quality from the very
beginning of the project
Review everything, test everything.
Use reviews to find defects – but don’t expect
the review to be perfect.
Use reviews to gain a real commitment from
the team.
It’s always faster in the long run to hold a
review than it is to skip it.
http://www.stellman-greene.com
9
Andrew Stellman & Jennifer Greene
Applied Software Project Management
How can we make sure that our
projects succeed?
Don’t impose an artificial hierarchy on the project
team
All software engineers were created equal.
A manager should not assume that programming is
more difficult or technical than design, testing or
requirements engineering.
Managers should definitely not assume that the
programmer is always right, or the tester is always
raising false alarms.
http://www.stellman-greene.com
10
Andrew Stellman & Jennifer Greene
Applied Software Project Management
How can we make sure that our
projects succeed?
Remember that the fastest way through the
project is to use good engineering practices
Managers and teams often want to cut important tasks
– especially estimation, reviews, requirements
gathering and testing.
If it were faster to build the software without these
practices, we would never use them.
Every one of these practices is about saving time and
increasing quality by planning well and finding defects
early. Cutting them out will cost time and reduce
quality.
http://www.stellman-greene.com
11
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Software Project Management
Software Project Planning
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Who needs software?
Most software is built in organizations for people
with specific needs.
A stakeholder is a anyone who has an interest (or
stake) in the software being completed
A user is someone who will need to use the software to
perform tasks.
Sometimes stakeholders will be users; but often the
stakeholder will not use the software.
• For example, a senior manager (like a CEO or CTO in a
company) will usually have a stake in the software that is built
(since it affects the bottom line), even if she won’t ever use it.
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Who builds software?
Software is typically built by a team of software
engineers, which includes:
Business analysts or requirements analysts who talk to
users and stakeholders, plan the behavior of software
and write software requirements
Designers and architects who plan the technical solution
Programmers who write the code
Testers who verify that the software meets its
requirements and behaves as expected
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Project Management
The project manager plans and guides the software
project
The project manager is responsible for identifying the
users and stakeholders and determining their needs
The project manager coordinates the team, ensuring that
each task has an appropriate software engineer assigned
and that each engineer has sufficient knowledge to
perform it
To do this well, the project manager must be familiar with
every aspect of software engineering
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Identifying Needs
The project manager drives the scope of the
project.
The project manager should identify and talk to
the main stakeholder
The effective way to show stakeholders that
their needs are understood and that those
specific needs will be addressed is with a vision
and scope document
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Vision and Scope Document
A typical vision and scope document follows an outline
like this one:
1. Problem Statement
a)
b)
c)
d)
e)
Project background
Stakeholders
Users
Risks
Assumptions
2. Vision of the Solution
a)
b)
c)
d)
Vision statement
List of features
Scope of phased release (optional)
Features that will not be developed
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Project Plan
The project plan defines the work that will be done on the
project and who will do it. It consists of:
 A statement of work (SOW) that describes all work products that
will be produced and a list of people who will perform that work
 A resource list that contains a list of all resources that will be
needed for the product and their availability
 A work breakdown structure and a set of estimates
 A project schedule
 A risk plan that identifies any risks that might be encountered and
indicates how those risks would be handled should they occur
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Statement of Work
The statement of work (SOW) is a detailed
description of all of the work products which will be
created over the course of the project. It includes:
A list of features that will be developed
A description of each intermediate deliverable or work
product that will be built.
The estimated effort involved for each work product to be
delivered
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Resource List
The project plan should contain a list of all
resources that will be used on the project.
A resource is a person, hardware, room or anything
else that is necessary for the project but limited in its
availability
The resource list should give each resource a name,
a brief one-line description, and list the availability
and cost (if applicable) of the resource
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Estimates and Project Schedule
The project plan should also include estimates and a
project schedule:
 A work breakdown structure (WBS) is defined. This is a list
of tasks which, if performed, will generate all of the work
products needed to build the software.
 An estimate of the effort required for each task in the WBS is
generated.
 A project schedule is created by assigning resources and
determining the calendar time required for each task.
Estimates and project schedules will be discussed in
detail in later slides.
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Risk Plan
A risk plan is a list of all risks that threaten the
project, along with a plan to mitigate some or
all of those risks.
The project manager selects team members to
participate in a risk planning session:
• The team members brainstorm potential risks
• The probability and impact of each risk is estimated
• A risk plan is constructed
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Software Project Management
Estimation
Andrew Stellman & Jennifer Greene
Applied Software Project Management
What is estimation?
The project manager must set expectations about
the time required to complete the software among
the stakeholders, the team, and the organization’s
management.
If those expectations are not realistic from the
beginning of the project, the stakeholders will not
trust the team or the project manager.
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Elements of a Sound Estimate
To generate a sound estimate, a project manager
must have:
A work breakdown structure (WBS), or a list of tasks
which, if completed, will produce the final product
An effort estimate for each task
A list of assumptions which were necessary for making
the estimate
Consensus among the project team that the estimate is
accurate
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Assumptions Make Estimates
More Accurate
Team members make assumptions about the work
to be done in order to deal with incomplete
information
Any time an estimate must be based on a decision that
has not yet been made, team members can assume the
answer for the sake of the estimate
Assumptions must be written down so that if they prove
to be incorrect and cause the estimate to be inaccurate,
everyone understands what happened
Assumptions bring the team together very early on in the
project so they can make progress on important
decisions that will affect development
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Wideband Delphi
Wideband Delphi is a process that a team
can use to generate an estimate
The project manager chooses an estimation
team, and gains consensus among that team
on the results
Wideband Delphi is a repeatable estimation
process because it consists of a straightforward
set of steps that can be performed the same
way each time
Andrew Stellman & Jennifer Greene
Applied Software Project Management
The Wideband Delphi Process
Step 1: Choose the team
The project manager selects the estimation team
and a moderator. The team should consist of 3 to
7 project team members.
• The moderator should be familiar with the Delphi
process, but should not have a stake in the outcome
of the session if possible.
• If possible, the project manager should not be the
moderator because he should ideally be part of the
estimation team.
Andrew Stellman & Jennifer Greene
Applied Software Project Management
The Wideband Delphi Process
Step 2: Kickoff Meeting
The project manager must make sure that each team
member understands the Delphi process, has read the
vision and scope document and any other
documentation, and is familiar with the project
background and needs.
The team brainstorms and writes down assumptions.
The team generates a WBS with 10-20 tasks.
The team agrees on a unit of estimation.
Andrew Stellman & Jennifer Greene
Applied Software Project Management
The Wideband Delphi Process
Step 3: Individual Preparation
Each team member independently generates a
set of preparation results.
For each task, the team member writes down an
estimate for the effort required to complete the
task, and any additional assumptions he needed
to make in order to generate the estimate.
Andrew Stellman & Jennifer Greene
Applied Software Project Management
The Wideband Delphi Process
Step 4: Estimation Session
During the estimation session, the team comes to a
consensus on the effort required for each task in the
WBS.
Each team member fills out an estimation form which
contains his estimates.
The rest of the estimation session is divided into rounds
during which each estimation team member revises her
estimates based on a group discussion. Individual
numbers are not dicsussed.
Andrew Stellman & Jennifer Greene
Applied Software Project Management
The Wideband Delphi Process
Step 4: Estimation Session (continued)
The moderator collects the estimation forms and plots the
sum of the effort from each form on a line:
Andrew Stellman & Jennifer Greene
Applied Software Project Management
The Wideband Delphi Process
Step 4: Estimation Session (continued)
 The team resolves any issues or disagreements that are brought up.
• Individual estimate times are not discussed. These disagreements are usually
about the tasks themselves. Disagreements are often resolved by adding
assumptions.
 The estimators all revise their individual estimates. The moderator updates
the plot with the new total:
Andrew Stellman & Jennifer Greene
Applied Software Project Management
The Wideband Delphi Process
Step 4: Estimation Session (continued):
 The moderator leads the team through several rounds of estimates
to gain consensus on the estimates. The estimation session
continues until the estimates converge or the team is unwilling to
revise estimates.
Step 5: Assemble Tasks
 The project manager works with the team to collect the estimates
from the team members at the end of the meeting and compiles the
final task list, estimates and assumptions.
Step 6: Review Results
 The project manager reviews the final task list with the estimation
team.
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Other Estimation Techniques
PROBE, or Proxy Based Estimating
 PROBE is based on the idea that if an engineer is building a component
similar to one he built previously, then it will take about the same effort as it
did in the past.
 Individual engineers use a database to maintain a history of the effort they
have put into their past projects.
 A formula based on linear regression is used to calculate the estimate for
each task from this history.
COCOMO II
 In Constructive Cost Model, or COCOMO, projects are summarized using
a set of variables that must be provided as input for a model that is based
on the results of a large number of projects across the industry.
 The output of the model is a set of size and effort estimates that can be
developed into a project schedule.
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Other Estimation Techniques
The Planning Game
 The Planning Game is the software project planning method from
Extreme Programming (XP), a lightweight development
methodology developed by Kent Beck in the 1990s at Chrysler.
 It is a full planning process that combines estimation with identifying
the scope of the project and the tasks required to complete the
software.
 The Planning Game is highly iterative. The scope is established by
having Development and Business work together to interactively
write “user stories” written on index cards to describe the scope.
Each story is given an estimate of 1, 2 or 3 weeks. This process is
repeated continuously throughout the project.
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Software Project Management
Project Schedules
Andrew Stellman & Jennifer Greene
Applied Software Project Management
What is a project schedule?
The project schedule is a calendar that
links the tasks to be done with the
resources that will do them.
Before a project schedule can be created,
the project manager must have a work
breakdown structure (WBS) and estimates.
The schedule is part of the project plan.
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Scheduling concepts:
Effort vs. Duration
Effort represents the work required to perform a task.
 Effort is measured in person-hours (or person-days, personweeks, etc.)
 It represents the total number of hours that each person
spent working on the task.
Duration is amount of time that elapses between the
time the task is started and the time it is completed.
 Duration is measured in hours (or days, weeks, etc.)
 It does not take into account the number of people
performing the task
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Scheduling concepts:
Slack and Overhead
Slack is the amount of time which any of the tasks can be
delayed without causing the due date of the final task in the
sequence to be delayed as well.
 A tight schedule has very little slack; a delay in any task will cause
a delay in the due date
 Parkinson’s Law: “Work expands so as to fill the time available for
its completion.”
Overhead is any effort that does not go to the core activities of
the task but is still required in order for the people to perform it—
a sort of “real world” cost of actually doing the work.
 Two people performing a task will require more effort than one
person doing the same task
 Assigning two people to the task requires more effort, but the task
has a shorter duration
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Building the project schedule
Allocate resources
For each task in the WBS, one or more
resources must be assigned
Choose person or people for each task
based on qualifications, familiarity and
availability
Take overhead into account when
calculating the duration of each task
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Building the project schedule
Identify dependencies
A task has a dependency if it involves an
activity, resource or work product which is
subsequently required by another task
Tasks may have dependencies because
they require the same resource
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Building the project schedule
Identify dependencies (continued)
 Every dependency has a predecessor, or a task that must be
begun, in progress, or completed, for another task to begin
 Identify the type of predecessor for each dependency
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Building the project schedule
Create the schedule
Most project
schedules are
represented using a
Gantt chart
The Gantt chart
shows tasks,
dependencies and
milestones using
different shapes
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Building the project schedule
Reconcile the schedule with the
organization’s needs
Once resources are allocated to each task, a final
date can be calculated
If this date is unacceptable, the project plan must
change
Either additional resources must be allocated to
the project or the scope must be cut down
refers to women
a well-knowncannot
software development
principle
Brooks’ Law: “Nine
have a baby
in coined
one month.” by Fred Brooks in The Mythical Man-Month.
• In other words, some tasks can only be done by one
person, no matter how critical they are.
The law, “Adding manpower to a late software project makes it later,” states that when a person is
added to a project team, and the project is already late, the project time is longer, rather than shorter.
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Building the project schedule
Reconcile the schedule with the
organization’s needs
Once resources are allocated to each task, a final
date can be calculated
If this date is unacceptable, the project plan must
change
Either additional resources must be allocated to
the project or the scope must be cut down
refers to women
a well-knowncannot
software development
principle
Brooks’ Law: “Nine
have a baby
in coined
one month.” by Fred Brooks in The Mythical Man-Month.
• In other words, some tasks can only be done by one
person, no matter how critical they are.
The law, “Adding manpower to a late software project makes it later,” states that when a person is
added to a project team, and the project is already late, the project time is longer, rather than shorter.
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Building the project schedule
Add review meetings to the schedule
Progress reviews are meetings held regularly to
check the progress of a project versus it's
scheduled progress.
Milestone reviews are meetings which the project
manager schedules in advance to coincide with
project events.
• The most common way for project managers to handle
milestone reviews is to schedule them to occur after the
last task in a project phase (such as the end of design or
programming).
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Building the project schedule
Step 4: Optimize the schedule
 The critical path is the sequence of tasks that represent the
minimum time required to complete the project.
• If a task is only on the critical path when delaying that task will
delay the project.
• Allocating resources to tasks on the critical path will reduce the
project schedule; allocating them to other tasks will have less
effect.
 A resource is over-allocated if more than 100% allocated to
multiple tasks simultaneously
• If any resource is over-allocated, it means that there is a
dependency between two tasks which was not discovered.
• When this happens, the schedule is guaranteed to be
inaccurate. Find and fix over-allocated resources.
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Don’t abuse buffers
A buffer is a task added to the schedule with no specific purpose
except to account for unexpected delays.
 This practice involves either adding extra tasks or padding existing
tasks at strategic points in the schedule where overruns are
“expected”.
 Buffers can be useful:
• On a year-long project, every programmer will take two weeks of
vacation
• Buffers can be used to account for this known delay
 Buffers are often abused
• The idea that overruns are expected means that there is an implicit
assumption that the estimate is incorrect.
• Buffers should not be used to add time to compensate for an inaccurate
estimate.
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Project metrics
The baseline is the version of the schedule
that has been approved
The schedule will change based on the actual
work done by the project team.
When the deadline of the revised schedule is later
than that of the baseline, the project has slipped.
Variance is the difference between the
estimated effort in the baseline and the actual
effort performed by the team.
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Project metrics
Earned value management tracks the project
by considering effort “earned” against a
budget only after it has actually been
performed
The budgeted cost for work scheduled (BCWS) is
the estimated effort of the actual tasks that appear
on the schedule to date.
The actual cost of work performed (ACWP) is the
effort spent on the tasks in the schedule that have
actually been completed by the development team
members.
Variance = BCWS – ACWP
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Project metrics
The cost performance index is used to compare projects with
each other or to compare phases within a project
 CPI is calculated by dividing BCWS / ACWP (budgeted cost for
work scheduled/actual cost for work performed) and multiplying by
100 to express it as a percentage.
 A CPI of 100% means that the estimated cost was exactly right and
the project came in exactly on budget.
 A CPI under 100%, the work cost less effort than planned; a CPI
greater than 100% means that the estimate was not adequate for
the work involved.
• For example, if the programming tasks took twice as long as estimated
but every other type of task in the project took less time than estimated,
the total variance for the project might still be low. However, the
problem can still be pinpointed by calculating the CPI for each phase of
development.
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Software Project Management
Reviews
Andrew Stellman & Jennifer Greene
Applied Software Project Management
When are reviews needed?
A review is any activity in which a work product is
distributed to reviewers who examine it and give
feedback.
 Reviews are useful not only for finding and eliminating
defects, but also for gaining consensus among the project
team, securing approval from stakeholders, and aiding in
professional development for team members.
 Reviews help teams find defects soon after they are injected
making them cost less to fix than they would cost if they
were found in test.
 All work products in a software project should be either
reviewed or tested.
• Software requirements specifications, schedules, design
documents, code, test plans, test cases, and defect reports
should all be reviewed.
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Types of Review:
Inspections
Inspections are moderated meetings in which
reviewers list all issues and defects they have
found in the document and log them so that
they can be addressed by the author.
The goal of the inspection is to repair all of
the defects so that everyone on the
inspection team can approve the work
product.
Commonly inspected work products include
software requirements specifications and test
plans.
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Types of Review:
Inspections
Running an inspection meeting:
1. A work product is selected for review and a team is gathered for
an inspection meeting to review the work product.
2. A moderator is chosen to moderate the meeting.
3. Each inspector prepares for the meeting by reading the work
product and noting each defect.
4. In an inspection, a defect is any part of the work product that will
keep an inspector from approving it.
5. Discussion is focused on each defect, and coming up with a
specific resolution.
•
It’s the job of the inspection team to do more than just identify the
problems; they must also come up with the solutions.
6. The moderator compiles all of the defect resolutions into an
inspection log
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Types of Review:
Deskchecks
A deskcheck is a simple review in which
the author of a work product distributes
it to one or more reviewers.
The author sends a copy of the work
product to selected project team members.
The team members read it, and then write
up defects and comments to send back to
the author.
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Types of Review:
Deskchecks
Unlike an inspection, a deskcheck does not
produce written logs which can be archived
with the document for later reference.
Deskchecks can be used as predecessors to
inspections.
In many cases, having an author of a work product
pass his work to a peer for an informal review will
significantly reduce the amount of effort involved in
the inspection.
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Types of Review:
Walkthroughs
A walkthrough is an informal way of presenting a
technical document in a meeting.
 Unlike other kinds of reviews, the author runs the
walkthrough: calling the meeting, inviting the reviewers,
soliciting comments and ensuring that everyone present
understands the work product.
 Walkthroughs are used when the author of a work product
needs to take into account the perspective of someone who
does not have the technical expertise to review the
document.
 After the meeting, the author should follow up with individual
attendees who may have had additional information or
insights. The document should then be corrected to reflect
any issues that were raised.
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Types of Review:
Code Review
A code review is a special kind of inspection
in which the team examines a sample of code
and fixes any defects in it.
In a code review, a defect is a block of code which
does not properly implement its requirements,
which does not function as the programmer
intended, or which is not incorrect but could be
improved
• For example, it could be made more readable or its
performance could be improved
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Types of Review:
Code Review
 It’s important to review the code which is most likely to have
defects. This will generally be the most complex, tricky or
involved code.
 Good candidates for code review include:
• A portion of the software that only one person has the expertise
to maintain
• Code that implements a highly abstract or tricky algorithm
• An object, library or API that is particularly difficult to work with
• Code written by someone who is inexperienced or has not
written that kind of code before, or written in an unfamiliar
language
• Code which employs a new programming technique
• An area of the code that will be especially catastrophic if there
are defects
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Types of Review:
Pair Programming
Pair programming is a technique in which two
programmers work simultaneously at a single
computer and continuously review each others’ work.
Although many programmers were introduced to pair
programming as a part of Extreme Programming, it is
a practice that can be valuable in any development
environment.
Pair programming improves the organization by
ensuring that at least two programmers are able to
maintain any piece of the software.
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Types of Review:
Pair Programming
In pair programming, two programmers sit at one computer to
write code. Generally, one programmer will take control and
write code, while the other watches and advises.
 Some teams have found that pair programming works best for them
if the pairs are constantly rotated; this helps diffuse the shared
knowledge throughout the organization. Others prefer to pair a
more junior person with a more senior for knowledge sharing.
The project manager should not try to force pair programming
on the team; it helps to introduce the change slowly, and where
it will meet the least resistance.
 It is difficult to implement pair programming in an organization
where the programmers do not share the same nine-to-five (or tento-six) work schedule.
 Some people do not work well in pairs, and some pairs do not work
well together.
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Software Project Management
Requirements
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Software Requirements
Software requirements are documentation that
completely describes the behavior that is required of
the software-before the software is designed built and
tested.
 Requirements analysts (or business analysts) build software
requirements specifications through requirements elicitation.
• Interviews with the users, stakeholders and anyone else whose
perspective needs to be taken into account during the design,
development and testing of the software
• Observation of the users at work
• Distribution of discussion summaries to verify the data gathered
in interviews
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Discussion Summary
A requirements analyst can
use a discussion summary to
summarize information
gathered during elicitation
and validate it through a
review.
Notes gathered during the
elicitation should fit into the
discussion summary
template
The discussion summary
outline can serve as a guide
for a novice requirements
analyst in leading interviews
and meetings
Discussion Summary outline
1.
Project background
a)
b)
c)
2.
Perspectives
a)
b)
3.
Who will use the system?
Who can provide input about the
system?
Project Objectives
a)
b)
c)
d)
4.
5.
6.
7.
Purpose of project
Scope of project
Other background information
Known business rules
System information and/or
diagrams
Assumptions and dependencies
Design and implementation
constraints
Risks
Known future enhancements
References
Open, unresolved or TBD issues
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Use Cases
A use case is a description of a specific interaction
that a user may have with the system.
Use cases are deceptively simple tools for describing
the functionality of the software.
 Use cases do not describe any internal workings of the
software, nor do they explain how that software will be
implemented.
 They simply show how the steps that the user follows to use
the software to do his work.
 All of the ways that the users interact with the software can
be described in this manner.
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Functional Requirements
Functional requirements define the outward
behavior required of the software project.
The goal of the requirement is to communicate the
needed behavior in as clear and unambiguous a
manner as possible.
The behavior in the requirement can contain lists,
bullets, equations, pictures, references to external
documents, and any other material that will help
the reader understand what needs to be
implemented.
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Nonfunctional Requirements
Nonfunctional requirements define characteristics of
the software which do not change its behavior.
 Users have implicit expectations about how well the software
will work.
 These characteristics include how easy the software is to
use, how quickly it executes, how reliable it is, and how well
it behaves when unexpected conditions arise.
 The nonfunctional requirements define these aspects about
the system.
• The nonfunctional requirements are sometimes referred to as
“non-behavioral requirements” or “software quality attributes”
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Software Requirements
Specification
The software requirements specification (SRS)
represents a complete description of the behavior of
the software to be developed.
The SRS includes:
 A set of use cases that describe all of the interactions that
the users will have with the software.
 All of the functional requirements necessary to define the
internal workings of the software: calculations, technical
details, data manipulation and processing, and other specific
functionality that shows how the use cases are to be
satisfied
 Nonfunctional requirements, which impose constraints on
the design or implementation (such as performance
requirements, quality standards or design constraints).
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Requirements vs. Design
Many people have difficulty understanding the
difference between scope, requirements and
design.
Scope demonstrates the needs of the
organization, and is documented in a vision and
scope document
Requirements document the behavior of the
software that will satisfy those needs
Design shows how those requirements will be
implemented technically
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Change Control
Change control is a method for implementing
only those changes that are worth pursuing,
and for preventing unnecessary or overly
costly changes from derailing the project.
Change control is an agreement between the
project team and the managers that are
responsible for decision-making on the project to
evaluate the impact of a change before
implementing it.
Many changes that initially sound like good ideas
will get thrown out once the true cost of the
change is known.
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Change Control
A change control board (CCB) is made up of the
decision-makers, project manager, stakeholder or
user representatives, and selected team members.
 The CCB analyzes the impact of all requested changes to
the software and has the authority to approve or deny any
change requests once development is underway.
 Before the project begins, the list of CCB members should
be written down and agreed upon, and each CCB member
should understand why the change control process is
needed and what their role will be in it.
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Change Control
Whenever a change is needed, the CCB
follows the change control process to
evaluate the change:
The potential benefit of the change is written
down, and the project manager works with the
team to estimate the potential impact that the
change will have on the project.
If the benefit of the change is worth the cost, the
project manager updates the plan to reflect the
new estimates. Otherwise, the change is thrown
out and the team continues with the original plan.
The CCB either accepts or rejects the change.
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Andrew Stellman & Jennifer Greene
Examples to illustrate the difference between needs, behavior and design
Needs
Behavior
Design
Vision and Scope
Document
Software Requirements
Specification
Design or Architecture
Document
The users need to be
able to easily search
and replace text.
A user indicates that search and
replace is needed. The software
responds by prompting for a
search term and replacement
text. The user enters the text and
indicates that the software is to
do a case-sensitive search to
replace all occurrences.
A user selects “Search” from the
“Edit” menu. The software pops
up a window with a textbox for a
search term, a textbox for the
replacement text, a checkbox for
case-sensitivity (defaulted to
unchecked) and a button labeled
“Replace All”. The user enters
the search term and replacement
text
into
the
appropriate
textboxes, checks the checkbox,
and clicks the button to initiate
the search.
A user composing email needs to be able
to look up contacts in
an address book.
A user entering the header
information in an e-mail being
composed indicates that the
current header field should be
populated using the address
book. The software responds by
displaying a list of contacts,
including full name and e-mail
address. The user specifies one.
The software responds by
returning to the e-mail and
adding the specified name and
address to the header field.
The user has the “compose email” window active, selects one
of the textboxes that contain the
To: or From: header, and clicks
the address book button next to
the textbox. The software
responds by popping up a modal
dialog that contains the address
book entries in a listbox. The
user scrolls down to the e-mail
address to be added to the field,
clicks on the name and clicks the
“Add” button. The software
closes the address book window
and adds the name to the field
that was being edited.
A user needs to search
the internet for web
pages that contain
certain words.
A user indicates a search term to
the search engine. The software
responds by displaying a list of
pages that match the criteria. The
list is limited to 100 results. The
user may indicate that the next
100 results are to be displayed, in
which case the system displays
those results instead.
A user navigates to the home
page of the search engine. The
software responds by displaying
a textbox and a button labeled
“Search”. The user enters the
search term into the textbox and
clicks the button. The software
responds by displaying a page
with 100 results, with? one link
per result. At the bottom of the
page is a link labeled “Next 100
hits”. If the user clicks on that
link, the search engine displays
the next 100 hits, with a link
labeled “Next 100 hits” and
another labeled “Previous 100
hits”.
http://www.stellman-greene.com
Applied Software Project Management
Software Project Management
Design and Programming
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Review the Design
Once the SRS has been approved, implementation begins.
Programming teams have many options:
 The programmers can simply start building the code and create the
objects and user interface elements.
 Designers can build a user interface prototype to demonstrate to
the users, stakeholders and the rest of the team. Any code used to
develop the prototype is typically thrown away once the design has
been finalized.
 Pictures, flow charts, data flow diagrams, database design
diagrams and other visual tools can be used to determine aspects
of the design and architecture.
 An object model can be developed on paper, either using code,
simple class diagrams or Unified Modeling Language (UML)
diagrams.
 A written design specification may be created, which includes some
or all of the tools above.
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Review the Design
Design tasks should always include reviews,
even when there is no written design
specification.
Any written documentation should be
reviewed and, if possible, inspected.
It is important that the reviews and inspections
reach the correct audience.
Many users who have important input for the user
interface may be uninterested or confused by
object models and UML diagrams.
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Version Control
A version control system allows programmers to keep
track of every revision of all source code files
 The main element of the version control system is the
repository, a database or directory which contains each of
the files contained in the system.
 A programmer can pick a point at any time in the history of
the project and see exactly what those files looked like at the
time.
 It is always possible to find the latest version of any file by
retrieving it from the repository.
 Changing a file will not unexpectedly overwrite any previous
changes to that file; any change can be rolled back, so no
work will accidentally be overwritten.
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Version Control
There are two common models for version control
systems
 In a copy-modify-merge system, multiple people can work on
a single file at a time.
• When a programmer wants to update the repository with his
changes, he retrieves all changes which have occurred to the
checked out files and reconciles any of them which conflict with
changes he made before updating the repository.
 In a lock-modify-unlock system, only one person can work
on any file at a time.
• A programmer must check a file out of the repository before it
can be modified. The system prevents anyone else from
modifying any file until it is checked back in.
• On large projects, the team can run into delays because one
programmer is often stuck waiting for a file to be available.
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Refactoring
Refactoring is a programming technique in which the
design of the software is improved without changing
its behavior.
 There are many choices that programmers make which do
not affect the behavior of the software but which can have an
enormous impact on how easy the code is to read and
understand.
 Refactoring works especially well during code reviews.
 Because refactoring is a change to the design, it may impact
the design review process. If previously reviewed code is
refactored, changes to that should be distributed to the
review team.
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Unit Testing
Before a build is delivered, the person or program
building the software should execute unit tests to
verify that each unit functions properly.
 All code is made up of a set of objects, functions, modules or
other non-trivial units. The purpose of unit testing is to create
a set of tests for each unit to verify that it performs its
function correctly.
 Programmers create suites of unit tests, where each test is a
small block of code which exercises a specific behavior of
one unit.
 The most common (and effective) way for programmers to
do unit testing is to use a framework, a piece of software that
automatically runs the tests and reports the results.
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Everyone is responsible for quality
There are different kinds of testing that serve
different purposes.
Programmers use unit tests is to verify that the
software works exactly as the programmer
intended.
Software testers are responsible for verifying that
the software meets its requirements (in the SRS)
and the needs of the users and stakeholders (in
the Vision and Scope Document).
• Many defects arise when a programmer delivers software
that worked as he intended, but did not meet the needs
of the users. Software testers can catch these problems.
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Everyone is responsible for quality
Many programmers are confused about
exactly what it is that software testers do.
All they know is that they deliver a build to the QA
team. The QA people run the program and find
bugs, which the programmers fix.
It is often hard for them to figure out where unit
testing ends and functional testing begins.
The project manager should watch for this
confusion, and help to clarify it by making sure
that the programmers understand what kinds of
testing are expected of them.
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Project Automation
Many quality problems happen because the team
does not build the software consistently, and loses
track of the health of the code.
Effective project automation reduces these errors.
The team can adopt a tool which:
 Retrieves the latest build from the version control system,
builds it, copies it to a folder, and reports any build warnings
or errors
 Runs unit tests, generating a test report and reporting critical
failures
 Runs automated code review tools, reporting any warnings
or rule violations
 Lists any changes which have been committed and by
whom, including links to code listings for the changes
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Software Project Management
Software Testing
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Quality
Quality means “conformance to requirements”
The best testers can only catch defects that are
contrary to specification.
Testing does not make the software perfect.
If an organization does not have good
requirements engineering practices then it will be
very hard to deliver software that fills the users’
needs, because the product team does not really
know what those needs are.
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Test Plans
The goal of test planning is to establish the list of
tasks which, if performed, will identify all of the
requirements that have not been met in the software.
The main work product is the test plan.
 The test plan documents the overall approach to the test. In
many ways, the test plan serves as a summary of the test
activities that will be performed.
 It shows how the tests will be organized, and outlines all of
the testers’ needs which must be met in order to properly
carry out the test.
 The test plan should be inspected by members of the
engineering team and senior managers.
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Test Cases
A test case is a description of a specific interaction that a tester
will have in order to test a single behavior of the software. Test
cases are very similar to use cases, in that they are step-by-step
narratives which define a specific interaction between the user
and the software.
 A typical test case is laid out in a table, and includes:
• A unique name and number
• A requirement which this test case is exercising
• Preconditions which describe the state of the software before the test
case (which is often a previous test case that must always be run
before the current test case)
• Steps that describe the specific steps which make up the interaction
• Expected Results which describe the expected state of the software
after the test case is executed
Test cases must be repeatable.
 Good test cases are data-specific, and describe each interaction
necessary to repeat the test exactly.
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Test Execution
The software testers begin executing the test plan after the
programmers deliver the alpha build, or a build that they feel is
feature complete.
 The alpha should be of high quality—the programmers should feel
that it is ready for release, and as good as they can get it.
There are typically several iterations of test execution.
 The first iteration focuses on new functionality that has been added
since the last round of testing.
 A regression test is a test designed to make sure that a change to
one area of the software has not caused any other part of the
software which had previously passed its tests to stop working.
 Regression testing usually involves executing all test cases which
have previously been executed.
 There are typically at least two regression tests for any software
project.
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Defect Tracking
The defect tracking system is a program that testers
use to record and track defects. It routes each defect
between testers, developers, the project manager
and others, following a workflow designed to ensure
that the defect is verified and repaired.
 Every defect encountered in the test run is recorded and
entered into a defect tracking system so that it can be
prioritized.
 The defect workflow should track the interaction between the
testers who find the defect and the programmers who fix it. It
should ensure that every defect can be properly prioritized
and reviewed by all of the stakeholders to determine whether
or not it should be repaired. This process of review and
prioritization referred to as triage.
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Smoke Tests
A smoke test is a subset of the test cases
that is typically representative of the overall
test plan.
Smoke tests are good for verifying proper
deployment or other non invasive changes.
They are also useful for verifying a build is
ready to send to test.
Smoke tests are not substitute for actual
functional testing.
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Test Automation
Test automation is a practice in which testers
employ a software tool to reduce or eliminate
repetitive tasks.
Testers either write scripts or use record-andplayback to capture user interactions with the
software being tested.
This can save the testers a lot of time if many
iterations of testing will be required.
It costs a lot to develop and maintain automated
test suites, so it is generally not worth developing
them for tests that will executed only a few times.
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Postmortem Reports
The postmortem report is an overall account
of the team’s experience in building the
software, and of the experience of the users
and stakeholders in working with the team.
The report should contain an honest assessment
of how the team members, users, and
stakeholders perceived the end product, and
assessed the decisions made throughout the
project.
The purpose of the post-mortem report is to
highlight the team’s successes and identify any
problems which should be fixed in future releases.
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Why Software Projects Fail
(Part I)
How to diagnose and fix a
troubled software project
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Lack of Leadership
It takes more than a talented and
motivated team to make a successful
project.
Lack of leadership manifests itself in the
team members suffering from:
Tunnel vision
Over-reliance on gut instincts
Repeated false starts in the project
Andrew Stellman & Jennifer Greene
Applied Software Project Management
The Mid-Course Correction
A change in project priorities throws the team
into disarray
This usually comes from a lack of
understanding of the scope of the project
When the engineers don’t understand the
users’ and stakeholders’ needs, they build the
wrong software
And they might not find out that there’s a problem
until after the work is done!
Andrew Stellman & Jennifer Greene
Applied Software Project Management
The Detached Engineering
Team
There is an artificial wall between the
people who build the software and those
who need it.
The business people feel like the engineers
are moving too slowly and don’t care about
their needs
The engineers feel like they’re always
shooting at a moving target because
business people don’t know what they want
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Fixing Planning Problems
Lack of Leadership, the Mid-Course
Correction and the Detached
Engineering Team are project planning
problems
Use a vision and scope document to define
the needs of the users and stakeholders
Use a project plan to keep every informed
about how those needs will be met
Use risk planning to keep the plan realistic
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Padded Estimates Generate
Distrust
Programmers add extra time to their
estimates
They may do this because of unknowns
Often they have been late in the past, and “know”
that they will need extra time
Project managers and senior managers
quickly figure this out, and start to question
individual estimates
And the programmers don’t have good answers!
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Self-Fulfilling Prophecy
A project manager under pressure
simply imposes a deadline, and creates
unrealistic estimates that meet it
The team works nights and weekends
to meet the deadline
The project manager feels vindicated
The team eventually gets frustrated and
disillusioned
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Fixing Estimation Problems
Padded estimates and the self-fulfilling
prophecy are estimation problems
Adopting a repeatable estimation process like
Wideband Delphi can help fix them
By writing down assumptions, the team can
handle risks without padding their time – and even
avoid the risks altogether
It reduces padding and increases honesty through
transparency, by letting the team correct each
other in an open meeting
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Working Backwards From a
Deadline
Project managers approach a nonnegotiable deadline for a project by
working backwards
They shorten the tasks in the schedule or
cutting them entirely until everything fits
When the schedule gets tight, any nonprogramming activities are cut and the
software is released before it’s finished
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Misunderstood Predecessors
The project manger does not take the time to
understand how tasks depend on each other
Problems are discovered partway through the
project one task can’t be started because it
depends on another
Delays cascade through the project, getting
increasingly worse
Some programmers are stuck waiting with
nothing to do, while others work overtime
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Fixing Scheduling Problems
Working backwards from a deadline and
misunderstood predecessors are
symptoms of underlying scheduling
problems
They can be avoided by adopting good
planning and estimation practices and
creating a project schedule
Schedule techniques like critical path
analysis can help spot problems early on
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Problems Are Found Too Late
There are preventable defects in the
software that aren’t caught until late in
the project
The team may misunderstand a need, but
that’s not discovered until delivery
Requirements may be missed or incorrect
The design may be difficult to use or fail to
take all of the features into account
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Big, Useless Meetings
A project manager who has previously been
burned by problems that were found too late
is determined to avoid falling into the same
trap
He calls a big meeting with everyone who could
possibly have input
The meeting drags on for hours, without making
any real progress
Eventually, everyone gives up and goes back to
the way they did things before
Andrew Stellman & Jennifer Greene
Applied Software Project Management
The Indispensable “Hero”
One “critical” person is seen as the
clear top programmer, and all important
work is sent through him
He may have a unique skill or experience
Sometimes he hoardes information so all
tasks that rely on it must go through him
He is always working long hours – and
causing bottlenecks
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Fixing Review Problems
Problems that are found too late, big useless
meetings, and the indispensable “hero” are
problems which can be solved with reviews
Reviews can catch defects early, when they are
cheaper to fix
A review meeting only includes the people
necessary for the work to be done
Reviews – especially code reviews – can help the
“hero” spread his expertise and knowledge
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Why Software Projects Fail
(Part II)
How to diagnose and fix a
troubled software project
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Iteration Abuse
Iteration can be a useful tool, but it is often
abused
The team uses iteration as a “guessing
game”
Programmers deliver build after build; users and
stakeholders make small changes to each build
Programmers like it because they can dive in
Users and stakeholders like it because they don’t
have to read documents or think about their needs
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Scope Creep
After the programming has started, users and
stakeholders make changes
Each change is easy to describe, so it sounds
“small” and the programmers agree to it
Eventually, the project slows to a crawl
It’s 90% done – with 90% left to go
The programmers know that if they had been told
from the beginning what to build, they could have
built it quickly from the start
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Fixing Requirements
Problems
When software requirements are not
gathered and specified before the software is
developed, it causes scope creep and the
team resorts to iteration abuse.
The team can adopt software requirements
engineering practices to write down most of the
changes before the work begins
A change control process gives them a handle on
the few changes that remain
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Haunted by Ghosts of Old
Problems
Programmers find that old bugs
suddenly reappear without warning
As the code base grows, it becomes
harder to keep control of the source code
They may use a shared folder to store
source code, but occasionally old copies of
files are copied over newer ones
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Broken Builds
The programmers deliver a build which does
not work – and the testers can’t even begin to
test it
The programmers get frustrated because they feel
that they put a lot of effort into testing the build
“Isn’t it the job of the QA team to figure out the
build is broken and tell them what to fix?”
The testers spend hours or days setting up a test
environment, only to redo it for the next build
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Spaghetti Code
Maintaining old code is the least
desirable programming job in many
organizations
Old, highly modified code turns into a
twisted mess of execution paths and
patches
Spaghetti code is often used as an excuse
to do an unnecessary rewrite
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Fixing Programming Problems
When the team adopts good
programming habits, they can avoid
ghosts of old problems, broken builds
and spaghetti code.
Get control of the source code with version
control software like Subversion
Use unit tests and test-driven development
to increase the quality of the build
Use refactoring to keep the code readable
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Requirements Haven’t Been
Implemented
The team delivers software missing
behavior or even entire features
Software is complex, and even with good
review practices, it’s difficult for
programmers to fully implement everything
Missing requirements are difficult to spot
because even the programmer missed
them when looking over his own work
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Obvious Bugs Slipped
Through
Inexperienced testers are expected to just
“bang on the software”
Technical support staff, junior programmers,
end users, outside temps and sales people
are drafted as “testers”
Even when experienced testers are used,
they are not given time to plan
Decisions about release readiness are made
based on the schedule, rather than the quality
Andrew Stellman & Jennifer Greene
Applied Software Project Management
“But It Worked For Us!”
When a product is not tested in all
environments in which it will be used,
the tests will be thrown off
Defects are missed when testers can’t
adequately replicate the environment in
which the software will be used
Test data may not resemble actual
production data
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Fixing Testing Problems
When code is delivered with too few
requirements implemented and too many
bugs included, the team needs better testing
practices.
Software testers must be involved in every stage
of development
Test planning must be given adequate time on the
schedule
Sufficient budget must be provided for a testing
environment.
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Common Problems Can Be
Avoided!
Almost everyone has experienced at
least a few of these problems.
We know what causes them, and we
have tools, techniques and practices
that can fix them.
All it takes is good project management
and sound software engineering… and
any project team can do it!
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Software Project Management
Understanding Change
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Why Change Fails?
The short answer: politics
 Many project problems are bigger than just your
project
 You have to make changes to the way people in
your organization work
 Your ideas on how to improve the way work is
done will not always be evaluated rationally
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Change is Uncomfortable
Nobody likes to think that they make mistakes
Making changes means talking about past
mistakes – and admitting that they are mistakes!
You may make a great case for change, and still
fail to convince people to do it.
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Common Excuses
Because change is uncomfortable, people in
organizations will resist it.
Project managers who try to change their
organizations run into several common
excuses when trying to implement tools,
techniques and practices.
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Common Excuses:
We Already Build Software Well
“This is just the way software projects always go.”
 People know that there are problems with the schedule
and quality, but think that nobody ever does any better
If you bring up past failures, you are trying to blame
people
This leads to an environment where it’s not
possible to admit that projects go wrong
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Common Excuses:
“Not Invented Here (NIH)” Syndrome
People intentionally avoid research or
innovations that were not developed within
the organization
 Yes, NIH syndrome really happens!
The idea that “we’re different” leads to
immediate resistance to outside ideas
In some small organizations, it’s even worse:
“Our ‘quirks’ mean we’re better.”
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Common Excuses:
It’s “Too Theoretical”
When ideas don’t make intuitive sense, they
are dismissed as merely academic
Many “hands-on” managers must personally
see a practice in place before they will
accept its value
Especially common in small teams facing
growing pains
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Common Excuses:
It Just Adds More Bureaucracy
Any work other than programming is wasteful
“busywork” that keeps the “real work” from
getting done.
“If I just add more programmers, it will fix all of
our schedule and quality problems!”
Planning the project, writing down
requirements, and holding inspection
meetings is seen as just pushing paper
around.
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Common Excuses:
You Can’t Give Me More Work!
Asking someone to review a document or
make an estimate is asking them to do more
work.
When you change the way other people
work, they may just say no.
For no good reason.
And if they have more power than you, they
may get their way.
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Common Excuses:
It’s Too Risky
A manager who backs a change puts his
reputation on the line.
It’s safer to let a project fail in a way it’s failed
before than to make a change that might not
work.
“Too risky” means risk to the manager, and
usually not risk to the project.
Andrew Stellman & Jennifer Greene
Applied Software Project Management
How to Make Change Succeed
Progress comes from making smart changes
Understand how people in your organization
think about and react to changes
 Prepare your organization
 Sell your change
 Account for common excuses in your “pitch”
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Prepare Your Organization
“We’ve always done it like this.”
Be positive about the work that’s already
being done
Take credit for the changes
Make the changes seem straightforward
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Prepare Your Organization
Build support from the team
Show that changes will save time and effort
Work around stragglers
Stick to the facts
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Plan for Change
Create a vision and scope document
Similar to the document for software projects,
except it describes the scope of the change
Inspect and approve the document to build
consensus
Add the changes to the schedule
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Push for Consensus
Get project team members on board first.
Managers are more likely to approve a change if
the entire team (especially the programming
staff) is behind it.
Help people recognize the problem, then
show that you have a solution.
Organizations do not change overnight.
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Software Project Management
Management and Leadership
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Responsibility, authority and
accountability
A person has responsibility for a task if:
He is given sufficient authority to perform it
He is accountable for its completion
A person has authority to perform a task only if he
has adequate control over the resources necessary
to complete the task.
A person is accountable for a task if failure to
adequately perform that task carries professional
consequences.
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Delegation
Delegation is assigning responsibility of a
task to a team member.
When delegating a task, the project manager
must ensure that the team member has the
authority to perform it and is accountable for
the results.
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Transparency
When the project manager creates a
document, holds a meeting of interest to
others, or makes an important project
decision, all of the information produced
should be shared and used with everyone
involved in the project.
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Transparency
All work products should be public
All team members, senior managers and
stakeholders should have access to every work
product produced for the project.
Project managers and team members benefit
because they make more informed decisions.
Senior managers and stakeholders are always
kept informed.
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Transparency
Decisions should be made based on known
guidelines
Published standards documents help others understand
the way certain roles must be filled.
Documents should be based on templates when
possible.
Process documents ensure that each project is done
using a repeatable process.
Use performance plans to set expectations for individual
team members.
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Manage the Organization
Prevent senior managers from seeing
software projects as a cost burden
A project is successful if its costs are justified by
its benefits.
Establishing a track record of successful
projects is the most effective way for a project
manager to reverse dangerous attitudes in
senior management.
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Manage the Organization
Show senior managers the impact of their
decisions
Decisions are frequently made based on gut
feelings instead of objective analysis.
The people making decisions about the project
need to understand the details.
Show senior managers that improving project
management practices will help them meet their
goals.
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Manage the Organization
Don’t confuse flexibility with always saying
yes
Don’t agree to an unrealistic schedule.
Change your approach when necessary.
Don’t confuse “easy to describe” with “easy to
implement.”
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Manage Your Team
Avoid common management pitfalls
Don’t manage from your gut.
Don’t second-guess estimates.
• Remember Brooks’ Law: “Adding manpower to a late
software project makes it later.”
Don’t expect consensus all of the time.
Make your mistakes public.
Accept criticism.
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Manage Your Team
Avoid micro-management
Don’t expect to review everything
Don’t fall into the “hands-on manager” trap
Use transparency to your advantage
Don’t be afraid to let your team members make
mistakes
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Manage Your Team
Address performance problems early
Work with each team member to develop a
performance plan.
Set standards that are fair and attainable.
Measure each team member’s progress
against known and agreed-upon goals.
Correct performance problems as early as
possible.
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Software Project Management
Managing an Outsourced Project
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Prevent Project Failure
Don’t be a hands-off client
Constantly communicate project goals
The vendor’s goals always differ from the clients
Don’t expect the team to ignore the vendor’s goals
Work with the team to establish the goals of the
project as an equal or greater priority
Transparency is especially important in an
outsourced project.
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Estimate the Work
Vendors often estimate the work as part
of contract negotiation
This happens before the team is assigned.
When the project team is assembled, it
may be necessary to re-estimate the work.
Unrealistic estimates cause projects to fail.
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Actively Manage the Project
A hands-off project manager is usually
surprised when the software is delivered
And the surprise is never a pleasant one.
It’s not enough to just have weekly
status meetings with no follow-up
Project managers need to know the team.
Just like an in-house project!
Andrew Stellman & Jennifer Greene
Applied Software Project Management
The Vendor’s Management
Build a relationship with the vendor’s
management
If they don’t support the project manager’s
goals or trust his decisions, the project will
likely fail.
Don’t allow the vendor’s escalation
process to interfere with the project.
Make sure the management at the vendor
recognizes and rewards good work.
Andrew Stellman & Jennifer Greene
Applied Software Project Management
The Project Team
Build a relationship with the team
A project manager doesn’t have the same
kind of relationship with the team that he
would with a team in his own organization.
The project manager isn’t always right! The
team does not report to him.
Gain credibility by making good decisions.
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Collaborate With the Vendor
Plan and manage the project scope
The project starts with a scope and a
budget.
• As opposed to an in-house project, which starts
with a set of known resources.
Plan for knowledge transfer.
Recognize that success for the project
manager and success for the vendor are
often two different things.
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Maintain Tracking and Oversight
Don’t depend on the vendor to maintain
the project plan and project schedule
When a project manager is responsible for
the project, he must keep track of its status
himself.
Hold reviews and inspections
Use a collaborative inspection process that
has been optimized for outsourced
projects.
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Design and Programming
Don’t delegate the entire design and
programming of the project to the
vendor
Establish design constraints early on.
If possible, design the software in-house,
or in collaboration with the vendor.
Monitor the code base using code reviews
and project automation.
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Software Quality
Take responsibility for the quality of the
software
Quality is not just another deliverable that
can be bought and paid for.
Don’t make decisions that undercut the QA
team.
Ensure that adequate time and budget is
allocated for test planning and execution.
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Don’t Blindly Trust the Vendor
Even though individual team members may
have certifications or degrees, it doesn’t
mean that they are competent.
Just because the vendor’s organization is
certified, that doesn’t guarantee that they
know better than you do how to run your
project.
Don’t be intimidated by the vendor’s
pedigree. If something on the project looks
wrong, it probably is!
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Software Project Management
Process Improvement
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Life Without a Formal Process
Many process improvement experts see
the world as black and white.
They often feel that there are bad software
teams without a formal process, and good
teams that have one in place.
But the world is not that simple!
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Life Without a Formal Process
Teams can be effective without a formal
software process
Teams can consist of “jack-of-all-trades”
programmers who understand the business of the
organization.
“Skunk works” programmers may often take
initiative and build useful software without input.
A highly capable development manager may be
willing to put in an enormous effort.
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Life Without a Formal Process
An organization that produces software
always has a software process
It’s just not formal, or documented and
repeatable
And teams without a formal process can
be happy and productive when they can
point to their successes!
Except when their projects fail.
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Life Without a Formal Process
A team without a formal process does not
scale up easily.
Programmers who used to produce lots of
software find that their projects have started to feel
“bogged down.”
This often happens when a small programming
group with a good track record is faced with
having to build a project on a larger scale.
It also happens when teams expand.
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Life Without a Formal Process
If there are no complaints about the way the
team is building software, then there’s no
reason to change!
However, few teams are really in this situation for
long.
Expanding the team is not the only place a
formal process is useful.
It can also help in an organization where experts,
users, or stakeholders are no longer readily
available to the programmers.
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Software Process Improvement
Software process improvement is the art and
science of changing an organization’s software
process in order to build better software.
Software process improvement always
involves looking at the big picture.
This means writing down the entire software
process as a whole and making sure that it is
followed on each project.
It involves looking at entire projects and identifying
areas that can be improved.
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Frameworks and Methodologies
Models and certifications that help assess the state
of the organization’s process and serve as a
framework for improving that process.
CMM, ISO 9000 and Six Sigma are frameworks
There are also methodologies that an organization
can adopt that describe the complete set of
activities, roles, and work products needed to build
software.
Rational Unified Process (RUP) and Extreme
Programming are methodologies.
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Capability Maturity Model
The CMM defines the characteristics of a
mature, capable process in a way that can be
measured and compared to processes at
other organizations.
The CMM consists of areas of improvement, goals
that must be met for each area, and specific
practices to be implemented.
A software engineering process group within the
organization identifies problems and inefficiencies
and defines practices to address them.
Independent assessors verify that an organization
is in compliance with CMM practices.
Andrew Stellman & Jennifer Greene
Applied Software Project Management
ISO 9000
ISO 9000 is a family of quality management standards defined
by the International Standards Organization. It is based on core
principles:
 Organizations must focus on their customers by understanding
current and future customer needs.
 Leaders within the organization must create and maintain an
environment in which people can become involved and fulfill the
organization’s objectives.
 People at all levels are important to the organization.
 Activities and resources are best managed as a process.
 Organizations have many interrelated processes, which must be
understood and managed as a system.
 The organization should continually improve its performance.
 Decisions should be well informed and based on real data and
information.
 An organization and its suppliers are in a mutually beneficial
relationship.
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Six Sigma
Six Sigma is an approach to improving quality
in manufacturing and business processes.
The Greek letter sigma refers to standard
deviation—Six Sigma means “six standard
deviations from the mean.”
DMAIC is a five-phase approach to Six Sigma
improvement
Define opportunities, Measure performance,
Analyze opportunity, Improve performance,
Control performance
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Extreme Programming
XP consists of a set of rules and practices that
govern all areas of software development:
planning, designing, coding, and testing.
The goal of XP is to lower the cost of change. To
meet this goal, many XP practices are highly
iterative.
XP is a disciplined and well-defined process.
By making the stakeholders part of the project team,
XP addresses the problem of the hands-off customer.
Andrew Stellman & Jennifer Greene
Applied Software Project Management
Rational Unified Process
RUP is not being widely used nowadays, as alternative
approaches have come up with the way UML has grown.
RUP is a popular off-the-shelf process based on the idea of
highly iterative development
 One thing that makes RUP unique is that it is a product in addition to
a process.
RUP includes a disciplined approach to requirements
management that is based on the idea of managing
changes.
 RUP incorporates software design using the Unified Modeling
Language (UML), a visual modeling system for graphically
representing the use cases, class model, object interactions, and
components of the software.
One core element of RUP is the continuous assessment of
the quality of the system.
Andrew Stellman & Jennifer Greene