SOFTWARE

PROJECT
MANAGEMENT
OBJECTIVES

Building the
Schedule Optimizing
Project
Reviews Schedule
Schedule

Post- Managing Diagnosing

Scheduling Multiple Scheduling
Tasks Projects Problems

SOFTWARE PROJECT MANAGEMENT 2

BUILDING THE PROJECT SCHEDULE

SOFTWARE PROJECT MANAGEMENT 3

PROJECT SCHEDULE
• Is a calendar that links the tasks to be done with the
resources that will do them
• Pre-requisites
• WBS
• Effort estimate for each task
• A resource list with availability for each resource
• Process
1. Resource allocation
2. Dependency identification
3. Schedule creation
4. Matching up with organization’s needs

SOFTWARE PROJECT MANAGEMENT 4

RESOURCE ALLOCATION
• A resource is any person, item, tool, or service that is
needed by the project that is either scarce or has limited
availability
• Allocate resources to each task – a certain resource is
not usually free until the task is finished; time can be
divided among tasks if not a full-day task
Effort vs. Duration
• Duration = starting time till ending time
• Effort = person-hours (total number of hours each person
spent working on the task)
• Example: 3 people working for 2 days, 8hrs daily
• Duration = 2 x 8 = 16 hours
• Effort = 3 x 16 = 48 person-hours

SOFTWARE PROJECT MANAGEMENT 5

RESOURCE ALLOCATION
Overhead - any effort that does not go to the core
activities of the task but is still required
Example
• 1 person  12 days
• 2 people  7 days (1 day overhead to communicate,
integrate and catch up)

SOFTWARE PROJECT MANAGEMENT 6

DEPENDENCY IDENTIFICATION
• A task has a dependency if it involves an activity,
resource, or work product that is subsequently required
by another task
• PM take the WBS and add dependency information
• Each task in the WBS gets a number
• Tasks dependent on it get numbered as dependents

SOFTWARE PROJECT MANAGEMENT 7

DEPENDENCY IDENTIFICATION
2 reasons for dependency
1. Causal relationship – the dependent task relies on a
work product generated by the predecessor e.g.
review dependent on document being completed
2. Resource sharing – two tasks need the same resource
e.g. 1 developer needed by 2 tasks

SOFTWARE PROJECT MANAGEMENT 8

 SCHEDULE CREATION
Most common form is Gantt
Chart – a bar chart
1. Each task is represented by
a bar
2. Dependency between
tasks are represented by
arrows
 Arrow either points to the
start or the end of the
task, depending on the
type of predecessor
3. Milestones are represented
by filled in diamonds
4. Black bar is inserted above
subtasks (a single WBS task
divided in an iteration) SOFTWARE PROJECT MANAGEMENT 9
MATCHING UP
• Once the schedule is created, end date of a project
can be determined
• In case, it does not match with the deadline
1. Reallocate resources to tasks in a different manner
2. Rearrange tasks to reduce the gap – two
independent tasks can overlap
3. Add more resources
4. Revisit assumptions (team may have assumed to
build a feature, when it could be purchased)
5. Plan for phased releases

SOFTWARE PROJECT MANAGEMENT 10

SCHEDULE REVIEWS

SOFTWARE PROJECT MANAGEMENT 11

PROGRESS REVIEWS
• Held to keep track of the actual plan’s conformance to
the scheduled plan
• Stakeholders must be present in case a major problem
arises
• If a delay is detected:
1. Re-adjust project schedule
2. Put in overtime

SOFTWARE PROJECT MANAGEMENT 12

MILESTONE REVIEWS
• Better to conduct them at the end of a phase
• Stakeholders must be present in case a major problem
arises
• Different from a progress review as PM writes up a report
after the milestone review
1. Any schedule delays or changes
2. any modifications to the scope
3. Any serious issues that came up since the last
milestone review meeting

SOFTWARE PROJECT MANAGEMENT 13

OPTIMIZING SCHEDULE

SOFTWARE PROJECT MANAGEMENT 14

CRITICAL PATH
• Critical path – sequence of tasks that represents the
minimum time required to complete the project i.e. the
sequence that, if delayed, will delay the schedule
• Free of slack
• If a certain task is not on the critical path, it can be
delayed without affecting the project (slack)
• If a new resource is to be added, the PM will know that
assigning it to a task off the critical path will not be
helpful

• Home task: read the following article

http://2020projectmanagement.com/2014/05/what-is-
the-critical-path/

SOFTWARE PROJECT MANAGEMENT 15

SLACK
• Slack – amount of time that any of the tasks can be
delayed without causing the due date of the final task in
the sequence to be delayed
• “if there is extra space between two tasks, then the
second task will have some protection, in case the first
task is late” – wrong
• Parkinson’s Law - work expands so as to fill the time
available for its completion

SOFTWARE PROJECT MANAGEMENT 16

BUFFERS
• Buffer – a task added to the schedule with no specific
purpose except to account for unexpected delays
• Buffers are good if they are added to expected delays
of unknown duration e.g. number of leaves/vacations
while working on long projects
• Buffers are bad when assumptions are estimated
incorrectly e.g. a team of 3 are stuck with a solution
more difficult than they estimated and each is counting
on the same buffer
• Hence, risks are planned beforehand and accurate
estimates are then made so that the stakeholders too
can be made aware of any unwanted situations that
might arise; preparing them mentally and reducing the
pressure on the team too

SOFTWARE PROJECT MANAGEMENT 17

POST-SCHEDULING TASKS

SOFTWARE PROJECT MANAGEMENT 18

BASELINE
• Baseline – a fixed schedule that represents the standard
that is used to measure the performance of the project
• Every time a change is approved, schedule must be
updated and saved as a separate version
• Slipped schedule – when the due date for the actual
schedule is later than that of the baseline

SOFTWARE PROJECT MANAGEMENT 19

SLIPPED SCHEDULE
• Variance - a measurement in person-hours (or person-
days/years) that shows the difference between the
effort planned on the baseline and the effort completed
on the actual schedule
• Budgeted cost for work scheduled (BCWS) – the
estimated effort of the actual tasks that appear on the
schedule
• Actual cost of work performed (ACWP) – the effort spent
on the tasks in the schedule that have actually been
completed
Variance = BCWS – ACWP
• If +ve  project cost fewer person-hours than budgeted
• If –ve  project overran the budget

SOFTWARE PROJECT MANAGEMENT 20

SLIPPED SCHEDULE
• Cost performance index (CPI)
CPI = (BCWS / ACWP) x 100
• If 100%  estimated cost was exactly right and the
project came in exactly on budget
• If <100  estimate was not adequate for the work
involved
• CPI can be used to:
1. Compare phases within a project to see which
phase actually lacked 100% efficiency
2. Compare projects against one another to see if the
CPI improves

SOFTWARE PROJECT MANAGEMENT 21

MANAGING MULTIPLE PROJECTS

SOFTWARE PROJECT MANAGEMENT 22

PROJECT DEPENDENCIES
If a PM is managing more than 1 projects:
• Independent projects – easy as both need a separate
schedule and plan
• Dependent projects – difficult
• Both need same resources - resources are not over-
allocated or under-allocated
• Product generated by one project is needed by the
other

SOFTWARE PROJECT MANAGEMENT 23

PROJECT PRIORITIES
• If no priority exists between shared-resource-projects, a
time will come when one might suffer due to resource
unavailability
• No two projects must have the same priority

SOFTWARE PROJECT MANAGEMENT 24

DIAGNOSING SCHEDULING PROBLEMS

SOFTWARE PROJECT MANAGEMENT 25

WORKING BACKWARD FROM A DEADLINE
• Usually happens with a non-negotiable deadline
• PM backtracks from the deadline to allot a certain
amount of time to each task
• If not do-able, phases like reviews and inspections are
skipped and overtime is made a compulsion
• Blaming the client or marketing/sales department is
wrong; PM needs to be straightforward before signing
the deal

SOFTWARE PROJECT MANAGEMENT 26

MISUNDERSTOOD PREDECESSORS
• If a dependency is missed or detected late, it can
create a chaos
• Reason: poorly formatted or missing WBS
• A delayed task will delay all the dependent tasks
• Most troublesome for testers since they have the
maximum workload towards the end of the
development

SOFTWARE PROJECT MANAGEMENT 27