L6: Software Project Management – Part II

ELIZABETH BJARNASON

Resource allocation, Monitor & Control

Agile Software Project Management

SPM - An Iterative Process

Activity planning Effort estimation Risk management Resource allocation

Monitor & Control

 Resource allocation

Activity planning Effort estimation Risk management Resource allocation

Monitor & Control

Achieve optimized use of
resources within
budget and scope =>
defines lead time

INVOLVES MANAGING PEOPLE

http://philosophyforlife.org/a-technocratic-solution-to-a-spiritual-question/

The right amount of people for each activity

The right amount of work for each person
Resources Money buys
resources within
reasons
include
– Labour – humans!
– equipment (e.g. workstations)
– materials
– space
– services

Resource allocation

1. Identify the resources needed for each activity and

create a resource requirement list
– Identify resource types, ‘SW devs’, ‘SW testers’, ‘BT
SW Devs’
2. Request resources
3. Allocate allocated resources to activities. Ensure
even / smooth allocation.
Visualise with resource histogram
 Activity planning & Effort Estimation then…

Resource requirements list (Table 8.1)

Stage Activity Resource type mDays Quantity Notes

ALL Project manager 104

1 All Workstation 1 Check SW availability
IoE/P/1 Senior analyst 34
2 All Workstation 3 One per person
IoE/P/2 Analyst/designer 20
IoE/P/3 Analyst/designer 15
IoE/P/4 Analyst/designer 25
IoE/P/5 Analyst/designer 15 Possibly analyst/programmer

3 All Workstation 2
IoE/P/6 Senior analyst 2
… … …
Resource Allocation Concerns

• All scheduble resources covered? Specialists, testing

teams, continuous and not tied to activities (e.g. PM)
• All ’heads’ are not the same: affects estimates
• Multi-tasking (%) has an overhead time cost, context
switching etc
• Overplanning and micro-management
• Underplanning and weak foresight activity size

-> Resource Histogram:

1 per Resource type (Fig 8.3)

Max available

Resource smoothing required!

 IRL EXAMPLE: Resource Allocation
Resource Request per 200602 200602 200602 200603 200603 200603

Function Group 200602_REQ 200602_ALL Diff 200602_REQ 200602_ALL Diff

PG_A-DRM 1,7 1,9 -0,2 1,7 1,6 0,1

PG_BTLC L 2,65 2,4 0,25 2,1 1,85 0,25

PG_CORE L 3 2,7 0,3 2 2,3 -0,3

PG_GAMES L 3,75 3 0,75 2,75 2,75 0

PG_GFX L 3 3 0 3 3 0

PG_MESSA L 6 7,75 -1,75 5 4,5 0,5

PG_PCSW L 1 1 0 1 1 0
PG_PIM L 1,75 1,75 0 1,75 1,75 0

PG_UIAPP L 3,5 3,25 0,25 3,5 1,25 2,25

IRL Example: Continuous Resource Allocation

November - Requested versus Allocated

5
Persons

Requested
4
Allocated

Function Groups
Monitor & Control

Activity planning Effort estimation Risk management Resource allocation

Monitor & Control

Plan vs Reality

Roadworks!

Accident!

Sick passenger
Monitoring
to check if project is on track relative plan

Based on data = sw measurements

– Reports
– Actual cost vs planned cost
– Actual value vs planned value
– Subjective data on completion rate

Reporting
Oral – Written, Formal – Informal, Regular - Ad Hoc
Formal Informal
Regular
Oral Re-occurring progress Around coffee machine
meetings, stand-ups
Written Job sheets, progress reports Emails to known collegues

Ad Hoc
Oral Review meetings Ad hoc meetings
Written Issues reports, change Emails for issues
requests investigation
Assessing progress

Continuously
AND
at predetermined checkpoints
• Event driven
• Time driven

Frequency and level of reporting

• Corresponding to organizational level
• Higher risk → more frequent monitoring
Collecting progress details
Need to collect data about
• Achievements: Value - Scope
• Effort spent: Costs
Exercise on partial completion
Developer has produced 250 lines of Java code for a task estimated at
total 500 loc.

Questions
1.Reasonable to assume task 50% complete?
2.Why / Why Not?
3.How can PM deal with this?

Slip charts
 Red/Amber/Green or Traffic Lights

Dashboards etc

Prioritized monitoring [Hughes 9.7]

Monitoring and reporting has a $-tag!

Focus on monitoring based on risk

• Critical path activities: if delayed later dependent activities are
delayed
• Activities with less than a specified float
• High risk activities: E.g. top 5-10 risks
• Activities using critical resources
+ activities with external dependencies
+ resource allocations
IRL Example: Monitor and control
Weekly status report collected by PM from
development teams & various systems
- Progress relative delivery scope & timeline
- Software quality status (performance tests)
- Risks and Actions
Presented at project meeting &
to steering group & sponsor
Number of bubbles
Summary
The project is in the execution phase and the
project includes 97 SW deliveries (bubbles) in
the Anatomy.
28 SW deliveries (bubbles) are now
delivered.
A checkpoint is scheduled in week 48.5 in
order to summarize the status and to decide
how to move forward
Critical areas are:
1.Deliveries are pushed forward, see below
integration statistics.
2.Graphical performance. The graphical
performance
PPSPi2 Integration statistics is only 25% of the expected
performance. Root cause analysis is ongoing
30 3.Quality problems with the FM-Radio RDS
25
chip. Re-planning is ongoing.

20

15

10

5 MS2 plan

Current plan
0
up to week 339

rest of 2004
340
341
342
343
344
345
346
347
348
349
350
351
352
401
402
403
404
405
Integrated

Number of CCB
bubbles
Week number

IRL Example: Monitor & Control of COST

- Reported once a month & at checkpoints to steering group

- Extracted from internal systems
- View progress, not just spenditure
Cost monitoring
Total October
SYSTEM Project Total October
Forecas Forecas
Order & Cost (KEUR) Actual Actual
t t
Man Months 92 130 19 27
Labour hours 12 989 18 302 2 685 3 779
Labour costs 1 348 1 830 290 378
Material/Consumables 100 60 10 20
Travel & Living 11 39 3 5
Consultants 10 20 5 7
Misc 2 5 1 2
Control, or Getting back on track
[Hughes 9.8]

• Renegotiate deadlines
• Shorten critical path
• Reconsider activity dependencies

Understand the issues! E.g. missing information, weak

tools, non-functioning team etc etc etc

Example
Kim: developer, 27 yrs old, worked in team for 3 months

Kim’s task is going into “yellow” – “red”

What should PM do?

Control by Modifying the Target
• Re-negotiate the commitment: time (deadline), cost or scope

Involve
• All affected stakeholders
• Steering committee and project sponsor
• INFORM all affected parties, e.g. Customers, testing

Change
control
[Ch 9.9]

Summary: Monitor & Control

Two main PM tasks
• PLAN
• GUIDE and FACILITATE; monitor & control a project
to meet agreed goals and targets

Monitor and control

• Monitor through analysing, compiling incoming reports
• Take corrective and adjustive action when needed
• Manage change in a structured way
• Coordinate roles and people (project meetings etc)
 NOTE: Week ends are free! ® Only week days count.
Available via course web
2 d after Thursday seminar == Monday

From Project Assignment:

Subtask 6: Project Plan including Risk Management

Plan for implementation of the first version of the product or service of your business idea
(aka implementation project). The plan is to include
a. All necessary activities and dependencies between these, shown in e.g. a Gantt
chart. For software development activities, these should be defined at the software
Preparations component level or lower (if suitable and needed to gain sufficient level of detail).
You can perform activity planning using a hybrid breakdown structure consisting of
the levels 1 to 4 of IBM’s MITP, i.e. define the development project, its
deliverables, components and work packages. See Hughes pages 135-137.
The activities should be detailed enough to enable realistic and reliable cost
estimates for the project (task b, below). Activities are recommended to be of
duration ≤ 1 month, and maximum 3 manmonths each.
b. Reasonable cost estimates for all activities identified in a. Estimate the effort and
resource types required for each activity.
c. Resources allocated to each activity. You can identify resource needs, e.g. with an
initial resource requirements list [Hughes 8.3]
Also, perform risk management for the implementation project by applying the methods and
techniques taught in the course. Identify, analyse and prioritise the risks, and plan for
mitigating the top risks (adjust plan accordingly and describe strategies for mitigating risk).
The use the following as input to your risk management:
At seminar a. potentially critical activities, i.e. critical and near-critical paths [Hughes 6.12-6.15].
This can be done by sketching a precedence network of the identified activities
[Hughes 6.6-6.11]
b. risks related to resources by comparing the resource list (c above) with available
resources
 Guest lectures: L8 and L9
Expert lecture with Fredrik Edman IRL lecture with

Linda Danielsson (MSc EE):

“Personal engagement and
team effort will lead to higher
product quality –
more innovation, creativity and a fun place
to work!”

Experience
- 20 years of SW Dev within embedded systems
like mobile phones and respirators
- project and line management, in
organizations with 200 - 350 SW engineers

AGILE PROJECT MANAGEMENT

Ch 4.10-11, 4.13-15 [Hughes]

elizabeth.bjarnason@cs.lth.se
 Principle-Driven Approach
based on Agile Manifesto
More valuable Valuable
• Individuals & interactions • Processes and tools
• Working software • Comprehensive documentation
• Customer collaboration • Contract negotiation
• Responding to change • Following a plan

Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James
Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve
Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas
The Agile Manifesto, http://agilemanifesto.org/, 2001

Level of detail at dev start

Agile SPM Agile

project
• Gradual detailing
Traditional
• Work order project
• Priority
• Just-in-time
• Self-governing teams
 Traditional Development Process

Reqts Design Impl Testing

+ a preparatory phase:
Agile Development Process High-level reqts +
design
Reqts Design Impl Testing

Reqts Design Impl Testing

Reqts Design Impl Testing

• Same activities, different sizing and sequence

→ Different principles and management approach

Scrum Development

POST-GAME

PRE-GAME
 Scrum Roles
• Product owner –customer view & scope
• Scrum master – scrum processes Pigs - committed
• Team - development
Everyone else, e.g. stakeholders, mgmt – Chickens - involved

Continuous Feedback & Transparency

Business, Management and Development roles involved in
• Sprint planning meeting
• Daily stand-up meetings
• End-of-sprint demo
• Sprint retrospective meetings
 Kanban: No iterations, team pull

• Max velocity – WIP (work in process) / state

• Optimize average lead time / work item
http://www.crisp.se/gratis-material-och-guider/kanban

XP Development Phase
Continuous
Backlog
review
Stories

Pair programming, TDD

Test Customer approval
Analysis Design Testing
planning & release
Priorities
Feedback
Continuous
Effort estimates integration
Auto test
Code base

Kent Beck, eXtreme Programming eXplained, Addison Wesley, 2000

 Agile (XP) Phases

Exploration Planning: Development Production- Maintenance Death

Release + (iterations) izing
per iteration

Pair programming Maintce Final

Release
A D TP T Rel Rel

TCs

Kent Beck, eXtreme Programming eXplained, Ch 21, Addison Wesley, 2000

Development in Scrum vs XP
Iterations aka sprints
Scrum 30 days prescribed, varies in reality
XP 1-4 weeks
Work in prio order
Scrum team chooses stories in sprint planning
XP team chooses stories strictly according to agreed prio
(set by product owner)
Managing change: Constant re-prio of backlog
Scrum no changes in scope during sprint
XP changes allowed within sprint for non-started stories
Activity Planning
• Product Owner/Customer defines & prioritises User stories in product backlog
• Team defines detailed tasks for each user story in sprint backlog
• Dependencies are built into the prioritised list; not explicitly marked

Story cards
Backlogs

Effort Estimate
• Early estimates during exploration phase
• User stories estimated as part of iteration/sprint planning
• Time (man / person hours / days)
or relative estimates (story points, bananas, gummy bears)
• Planning game (XP) or Planning poker (Scrum)
Resource Allocation
• Capacity driven
– Project level: In exploration phase
– Iteration level: In iteration planning
• Within iteration: team pull, i.e. self-allocation

Risk Management

• Built into the process through transparency & feedback

– Stand-up meetings
– Sprint planning meetings
– Iteration demos with customer / product owner

Traditional risk management techniques can be used, even if not

prescribed
 Monitor
• Regular meetings
• Progress monitored by asking ”How much work remains?”
• Frequent status checks -> Burn-down charts
Story
points

day

… & Control

• Management does not control in agile, rather facilitate

• Team is responsible for managing itself– Team pull!

→ Team responsible for its own work practice / process

… within the ”rules”

• Regular feedback loops: pair programming, daily stand-up

• Sprint retrospectives
 IRL Example: Monitor & (Team) Control
• Regular feedback & knowledge share
– Daily stand-up meetings
– Sprint demos & planning, sprint retrospectives
• Burn-down charts used to monitor progress & ”remaining work”
• Dependant projects
– Status reporting delivered to / from other related projects
– Info on dependent functionality & deliveries,
considered in sprint planning as part of backlog
prioritization.

Incremental Delivery + and - [Ch 4.10]

Strengths
• quickly delivers working
increments
• avoids unnecessary overhead
• short communication paths
• feedback from early stages
used in developing latter
stages
Weaknesses
• weak long-term and overall
perspective
• weak / missing documentation
• weaker specialist competence
• Less structure/guidance
 ”Right-hand” items also valuable
More valuable Valuable
• Individuals & interactions • Processes and tools
• Working software • Comprehensive documentation
• Customer collaboration • Contract negotiation
• Responding to change • Following a plan

Traditional SPM methods and techniques useful, also in Agile

Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith,
Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas
The Agile Manifesto, http://agilemanifesto.org/, 2001