RD SDM 1 Software Project Management Project Scheduling

  • Slides: 29
Download presentation
R&D SDM 1 Software Project Management Project Scheduling and Tracking 2010 Theo Schouten

R&D SDM 1 Software Project Management Project Scheduling and Tracking 2010 Theo Schouten

Content What is project scheduling & tracking ? Which steps can be recognized in

Content What is project scheduling & tracking ? Which steps can be recognized in project scheduling? Work Breakdown Structure Techniques: CPM, Gantt Charts Examples Final remarks Book chapter 24 (27 for 7 e) 2

What is project scheduling&tracking? Scheduling: –The partitioning of the total work in tasks, which

What is project scheduling&tracking? Scheduling: –The partitioning of the total work in tasks, which deliver defined products. –The planning of those tasks in calendar time. –The allocation of resources to these tasks. Tracking: –Following of the progress of the tasks. –Adapting the schedule according the latest developments. How software projects fall behind schedule? 3

Why software is delivered late? • • Unrealistic deadline established outside the team Changing

Why software is delivered late? • • Unrealistic deadline established outside the team Changing customer requirements not reflected in schedule Underestimating the resources required to complete the project Risks that were not considered when project began Technical difficulties that have not been predicted in advance Human difficulties that have not been predicted in advance Miscommunication among project staff resulting in delays Failure by project management to recognize project falling behind schedule and failure to take corrective action people, process, technology 4

Perspectives • the end-date for the software release is set externally – the software

Perspectives • the end-date for the software release is set externally – the software organization is constrained to distribute effort in the prescribed time frame. • the rough chronological bounds have been discussed by the developers and customers – the end-date is best set by the developer after carefully considering how to best use the resources needed to meet the customer's needs. – negotiation process 5

Basic principles for scheduling Compartimentalization – decomposition of both the product and the process

Basic principles for scheduling Compartimentalization – decomposition of both the product and the process – the work is divided in tasks (work-breakdown structure) – each delivers (possible in combination with other tasks) a part of the product. Interdependency – minimize the dependency between tasks – which products of other tasks are needed to start a task – sequential and parallel tasks Time allocation for each task How much work is needed in e. g. person-days Determine whether this will be part-time of full-time Assign a start and completion date (not assigned yet to a person). 6

…continued Matching total time with available resources – Are the needed resources (persons, tools,

…continued Matching total time with available resources – Are the needed resources (persons, tools, hardware) available? (not assigned yet to a person). Defining responsibilities – Every task should be the responsibility of a person. Defining outcomes of tasks – Each task should have a defined outcome. (SMART) – More than 1 of these work products may be grouped into a deliverable. Defining milestones – the milestones of the project: a moment in time on which a (group of) deliverables should be finished. 7

Effort distribution • Use the data on the organization’s historical experience with similar projects

Effort distribution • Use the data on the organization’s historical experience with similar projects • When such data is not available, publicly available factors can be used for guidance. • The 40 -20 -40 rule (a rule of thumb): – 40% front-end analysis and design – 20% coding – 40% back-end testing • Generally accepted guidelines are: – 02 -03 % planning – 10 -25 % requirements analysis – 20 -25 % design – 15 -20 % coding – 30 -40 % testing and debugging 8

Critics of 40 -20 -40 % rule • Some Software Engineering Managers believe that

Critics of 40 -20 -40 % rule • Some Software Engineering Managers believe that more than 40% of overall effort should be expended during Analysis and Design. • Some proponents of Agile Development Method argue that Less time should be expended on “Frontend’’ of Project Phase and that a team should move quickly to Construction Phase (Build phase). • Theo: when a program is working, the documentation still need a lot of work. 9

Parts and steps Project task: A task is executable and delivers a well defined

Parts and steps Project task: A task is executable and delivers a well defined work product (SMART); Work-breakdown structure: Division of the total trajectory into tasks; Deliverable Intermediate or final product delivered by a task or a number of tasks; Milestone: Date on which a deliverable should be ready; Network of dependencies of project tasks: lsequential lparallel 10

…continued Determine which tasks are critical in the network: they determine the run time

…continued Determine which tasks are critical in the network: they determine the run time of a project; Determine what the size of the tasks are; Determine which resources are needed to execute each task; Building up of a project schedule: : dividing the tasks over time and allocating resources to tasks; Tracking of the progress of the project on basis of its schedule. 11

Steering project Steer on goals Project Sponsor Steering Committee Steer on goals, milestones and

Steering project Steer on goals Project Sponsor Steering Committee Steer on goals, milestones and deliverables Project Steering Committee Project Manager(s) Attention in this course Functional/Process Groups (User Focal Points) User Group 1 Steer on Milestones, deliverables and tasks User Group 2 …. . Technical Project Leader Analysts Designers Steer on Tasks and resources programmers User Group n 12

Work-Breakdown Structure • A detailed breakdown of the product into manageable work elements. •

Work-Breakdown Structure • A detailed breakdown of the product into manageable work elements. • A method for breaking down work within a project into logical steps: – Product WBS: • Work is broken down by system, subsystem, modules & the structure of the software product. – Activity WBS: • Work is broken down by activities of the project members such as management, requirements analysis, design & programming. 13

Product WBS 14

Product WBS 14

Activity WBS 15

Activity WBS 15

Work-breakdown structure Example Main phases of an information system based on software packets on

Work-breakdown structure Example Main phases of an information system based on software packets on the market. Phase 1 Develop Blueprint Phase 2 Design Information system Phase 3 Realize Information system Phase 4 Implement Information system 16

Steps in phase 1 Development blueprint Deliverables phase 1 1. 1. Preparation & Projectdefinition

Steps in phase 1 Development blueprint Deliverables phase 1 1. 1. Preparation & Projectdefinition 1. 2. Develop processmodel current situation Blueprint 1. 3. Analysis current situation 1. 4. Develop blueprint 1. 5 Fit-analysis shortlist Packets 1. 6 make principle choice 1. 7. Make plan next phases Principle -choice Fitanalysis Plan phase 2 17

Steps in phase 2 Design Information System Deliverables Phase 2 Input Phase 2 Blueprint

Steps in phase 2 Design Information System Deliverables Phase 2 Input Phase 2 Blueprint Principle -choice Fitanalysis Plan phase 2 Final choice Iterative Preparation Execution 2. 1. 2. 2. Develop simulation case Make simulation environment 2. 3. Prototype stepthrough 2. 4. 2. 5. Endreport Design interfaces + conversion Process model future sit. Finalreport Solutions for “gaps” 18

Relation deliverables-milestones Project Goals Task 1 Constraints Deliverable 1 . . . Task n

Relation deliverables-milestones Project Goals Task 1 Constraints Deliverable 1 . . . Task n Deliverable n Milestone 1 . . . Milestone n Timing, resourcing and dependencies 19

Relation between people and effort • Putnam-Nordon-Rayleigh (PNR) curve • putting more people on

Relation between people and effort • Putnam-Nordon-Rayleigh (PNR) curve • putting more people on a project does not decrease time linearly • people need time for communication • 4 zones in the curve for a certain defined project: 1) it can not be completed within a certain time 2) overstaffed: completed fast, but inefficient 3) linear range: efficient staffing, man-power trade-off with time is good possible 4) understaffed: becomes also inefficient 20

PNR Formula’s • The number of delivered lines of code L is related to

PNR Formula’s • The number of delivered lines of code L is related to effort and development time by the equation: L = P × E 1/3 t 4/3 E is development effort in person-months P is a productivity parameter that reflects various factors (typically 2, 000 -12, 000) t is the project duration in calendar months • Rearranged to solve for development effort: E = L 3/(P 3 t 4) 21

Setting up of a schedule Define deliverables and milestones; Identify tasks which belong to

Setting up of a schedule Define deliverables and milestones; Identify tasks which belong to deliverables; Identify relations between deliverables and activities; Determine the type and size of the resources needed for a task; Allocate people to activities; Create activity networks and ‘bar charts’ (Gantt Charts). 22

Example Task Run time in workdays Dependencies (milestone) T 1 8 T 2 15

Example Task Run time in workdays Dependencies (milestone) T 1 8 T 2 15 T 3 15 T 4 10 T 5 19 T 2, T 4 (M 2) T 6 5 T 1, T 2 (M 3) T 7 20 T 1 (M 1) T 8 25 T 4 (M 5) T 9 15 T 3, T 6 (M 4) T 10 15 T 5, T 7 (M 7) T 11 7 T 9 (M 6) T 12 10 T 11 (M 8) T 1 (M 1) 23

Activity network Insight in parallel and sequential tasks + dependencies 15 days 14/7/99 8

Activity network Insight in parallel and sequential tasks + dependencies 15 days 14/7/99 8 days M 1 T 3 4/7/99 25/7/99 15 days M 3 5 days 25/8/99 M 6 T 6 7 days 20 days T 2 M 2 T 4 10 days T 5 18/7/99 M 5 T 11 T 7 25/7/99 10 days T 9 M 4 T 1 Start 15 days 4/8/99 5/9/99 11/8/99 M 8 M 7 15 days 25 days 10 days T 10 T 12 T 8 End 19/9/99 24

Critical path 15 days 14/7/99 8 days M 1 T 3 4/7/99 25/7/99 M

Critical path 15 days 14/7/99 8 days M 1 T 3 4/7/99 25/7/99 M 3 15 days 25/8/99 M 6 T 6 7 days 20 days T 2 M 2 T 4 T 11 T 7 25/7/99 10 days T 9 M 4 T 1 Start 15 days 4/8/99 10 days T 5 18/7/99 5/9/99 11/8/99 M 8 M 7 15 days M 5 25 days 10 days T 10 T 12 T 8 = Critical Path End 19/9/99 25

Bar chart (Gantt chart) 4/7 Start 11/7 18/7 25/7 1/8 8/8 15/8 22/8 29/8

Bar chart (Gantt chart) 4/7 Start 11/7 18/7 25/7 1/8 8/8 15/8 22/8 29/8 5/9 12/9 19/9 26/9 T 4 T 1 T 2 M 1 T 7 T 3 M 5 T 8 M 3 M 2 T 6 T 5 M 4 T 9 M 7 T 10 M 6 T 11 M 8 T 12 End 26

Extra time 4/7 Start 11/7 18/7 25/7 1/8 8/8 15/8 22/8 29/8 5/9 12/9

Extra time 4/7 Start 11/7 18/7 25/7 1/8 8/8 15/8 22/8 29/8 5/9 12/9 19/9 26/9 T 4 T 1 T 2 M 1 T 7 T 3 M 5 T 8 M 3 M 2 T 6 T 5 M 4 T 9 M 7 T 10 M 6 T 11 M 8 T 12 End 27

Allocation of persons to tasks and time Task Software Engineer T 1 Jan T

Allocation of persons to tasks and time Task Software Engineer T 1 Jan T 2 Carolien T 3 Jan T 4 Frank T 5 Isabel T 6 Carolien T 7 Jim T 8 Frank T 9 Jan T 10 Carolien T 11 Frank T 12 Frank 4/7 Frank 11/7 18/7 25/7 1/8 8/8 15/8 22/8 29/8 5/9 12/9 19/9 T 4 T 8 T 11 T 12 Jan T 1 T 3 T 9 Carolien T 2 T 10 T 6 Jim Isabel T 7 T 5 Resources can influence the critial path, e. g. Frank with T 8 -T 11 28 26/9

Gantt chart 29

Gantt chart 29