Applied Software Project Management

Project Schedules

http://www.stellman-greene.com 1
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.

http://www.stellman-greene.com 2
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, person-weeks,
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

http://www.stellman-greene.com 3
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. For example, the integration
time required to assemble two completed modules from two
developers.
 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

http://www.stellman-greene.com 4
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

http://www.stellman-greene.com 5
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

http://www.stellman-greene.com 6
 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

http://www.stellman-greene.com 7
 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
 Consider Drawing Gantt
Chart in the lecture

http://www.stellman-greene.com 8
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
 Brooks’ Law: “Nine women cannot have a baby in one
month.”
 In other words, some tasks can only be done by one person, no
matter how critical they are.

http://www.stellman-greene.com 9
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).

http://www.stellman-greene.com 10
Applied Software Project Management

Building the project schedule

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

http://www.stellman-greene.com 11
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.

http://www.stellman-greene.com 12
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.

http://www.stellman-greene.com 13
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

http://www.stellman-greene.com 14
Applied Software Project Management

Project metrics
 The Cost Performance Index (CPI) 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.

http://www.stellman-greene.com 15
Applied Software Project Management

Managing Multiple Projects

 Many project managers are responsible for multiple
projects. If each project is planned well, managing a
set of them should not be difficult.
 When projects don’t share dependencies, managing
them is straightforward—just manage each project
individually, with a separate project schedule for each
one.

http://www.stellman-greene.com 16
Applied Software Project Management

Managing Multiple Projects

 When projects share dependencies, they are more
challenging to manage. There are two ways that one
project might depend on another. In the first type, two
projects rely on the same resources; in the second type,
a work product generated by one project is needed by
the other.
 Getting a handle on these dependencies is the first
important step in managing multiple projects

http://www.stellman-greene.com 17
Applied Software Project Management

Understand Dependencies
Between Projects
 The most common way for projects to be
interdependent is through shared resources
 Software projects go through a set of sequential
phases: SDLC.
 In each phase, most of the work is done by a small
subset of the team, leaving the rest of the team
available to work on other projects.

http://www.stellman-greene.com 18
Applied Software Project Management

Understand Dependencies
Between Projects
 One solution is to make each project in a different
phase so that they are complementary.
 The trouble with this system is that no two projects
take exactly the same time, and the phases don’t
always require the same percentage of the total effort

http://www.stellman-greene.com 19
Applied Software Project Management

Prioritize Projects Realistically

 Prioritizing projects is similar to prioritizing tasks—it
requires tough decisions, and will almost always make
someone unhappy.
 If two projects are not sharing the same resources then
there is no problem.
 Every project manager feels his project is the most
important one, therefore a single decision maker who
is higher rank than other project managers has to take
the decision.
 CEO, Owner, or any one has the power of money is the
one responsible of being the decision maker
http://www.stellman-greene.com 20
Applied Software Project Management

Diagnosing Scheduling
Problems

http://www.stellman-greene.com 21
Applied Software Project Management

Working Backwards From a Deadline

 Project managers approach a non-negotiable 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 non-programming
activities are cut and the software is released before it’s
finished

http://www.stellman-greene.com 22
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

http://www.stellman-greene.com 23
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

http://www.stellman-greene.com 24