The project structure (WBS)

24-March-2015

1

Recap

Software Development Planning

2

Recap – What IS or ISN’T a Project Plan A project plan IS a collection of different

views of the project A project plan IS a model of the project’s

future A project plan IS a living artifact A project plan is NOT a GANTT chart A project plan is NOT a schedule

3

Recap - PMBOK Definition

The process necessary for defining, preparing, integrating and coordinating all subsidiary plans into a project management plan.

The project management plan becomes the primary source of information for how the project will be planned, executed, monitored and controlled, and closed.

4

Recap - Planning timeline

5

Project Planning Process Areas

Developing the Project Plan Interacting with Stakeholders Getting Commitment to Plan Maintaining the Plan

6

Specific Goals

Establish Estimates Develop a Project Plan Obtain Commitment to the Plan

7

Role: Project Manager (RUP)

8

Project Planning Roles and Responsibilities

Responsible Accountable Consulted Informed

Project Management

X X

Project Stakeholders

X X

Project Team X X

Project Review Authority

X

9

Activities for developing the SDP Develop the SDP project management

content Develop enclosed project management

plans Coordinate the development of supporting

plans

10

Topic – Scope Management and WBS Planning the Development

The project structure (WBS) References

Software Project Management: A Unified Framework, Walker Royce, Addison Wesley

Fundamentals of Project Management, James P. Lewis, AMACOM Books

Software Project Management, Bob Huges, Mike Cotterrel

PMBOK

11

Going further into Planning

Planning is about answering some questions like:“What must be done?” “When will it be done?” “Who will build it?”“How much will it cost?”

12

Planning the “WHAT”

Planning the “what” is crucial One frequent reason projects fail is that a

significant part of the work is forgotten!

13

Project Scope Management

Scope Planning Scope Definition Create WBS Scope Verification Scope Control

14

Scope Planning

Defining and managing the scope is key to project success

Detailed project scope statement process Process for creating the WBS from the

detailed statement Formal verification specification Change control process

15

Scope Definition

Detailed project scope statement Change Requests Project Scope Management Plan update

16

Scope Definition [1] Detailed project scope statement

Project Objectives (Specific, Measurable, Attainable, Relevant, Time-limited)

RequirementsBoundariesDeliverablesAcceptance CriteriaConstraintsAssumptions

17

Scope Definition [2] Detailed project scope statement

Initial Organization Initial RiskMilestonesFund limitationsCost estimateConfiguration Management RequirementsSpecificationsApproval Requirements

18

Create WBS Project Scope Statement Updates Work Breakdown Structure WBS Dictionary Scope Baseline Project Scope Management Plan Updates Change Requests

19

Scope Verification

Assures that the detailed scope definition, WBS and WBS dictionary are formally reviewed and approved by the project stakeholders

20

Scope Verification

Accepted deliverables Change Requests Recommend corrective actions

21

Scope Control

Assures that all Requested Changes and Corrective Actions are processed by the Integrated Change Control Management process

22

Scope Control Project Scope Statement (Updates) Work Breakdown Structure (Updates) WBS Dictionary (Updates) Scope Baseline (Updates) Requested Changes Recommended Corrective Action Organizational Process Assets (Updates) Project Management Plan (Updates)

23

What is the WBS? WBS is a hierarchical decomposition of

work Can be action driven or deliverable driven

(verbs or nouns) Organizes and defines the total scope of

the project Each level of the WBS represents an

increased level of detail

24

WBS Introduction

25

WBS Dictionary

26

WBS Goals

Improve estimates Keep the team focused Assign work to resources Keep the project on track

27

WBS

28

WBS Example

Build a House

Plans development

Architecture Resilience

Construction

Concrete Walls Roof

29

WBS ExampleLevel 1 Level 2 Level 31 Widget Management System

1.1 Initiation 1.1.1 Evaluation & Recommendations1.1.2 Develop Project Charter1.1.3 Deliverable: Submit Project Charter1.1.4 Project Sponsor Reviews Project Charter1.1.5 Project Charter Signed/Approved

1.2 Planning 1.2.1 Create Preliminary Scope Statement1.2.2 Determine Project Team1.2.3 Project Team Kickoff Meeting1.2.4 Develop Project Plan1.2.5 Submit Project Plan1.2.6 Milestone: Project Plan Approval

30

31

Level 1 Level 2 Level 31Widget

Management System

1.3 Execution 1.3.1 Project Kickoff Meeting1.3.2 Verify & Validate User Requirements1.3.3 Design System1.3.4 Procure Hardware/Software1.3.5 Install Development System1.3.6 Testing Phase1.3.7 Install Live System1.3.8 User Training1.3.9 Go Live

1.4 Control 1.4.1 Project Management1.4.2 Project Status Meetings1.4.3 Risk Management1.4.4 Update Project Management Plan

1.5 Closeout 1.5.1 Audit Procurement1.5.2 Document Lessons Learned1.5.3 Update Files/Records1.5.4 Gain Formal Acceptance1.5.5 Archive Files/Documents

32

Widget Mgmt. System

1

Initiation 1.1

Planning 1.2

Execution 1.3

Control 1.4

Create Preliminary Scope Statement

1.2.1

Closeout 1.5

Evaluation & Recommendations

1.1.1

Develop Project Charter 1.1.2

Deliverable: Submit Project

Charter 1.1.3

Project Sponsor Reviews Project

Charter 1.1.4

Project Charter Signed/Approved

1.1.5

Determine Project Team 1.2.2

Project Team Kickoff Meeting

1.2.3

Develop Project Plan 1.2.4

Submit Project Plan 1.2.5

Milestone: Project Plan Approved

1.2.6

Project Kickoff Meeting

1.3.1

Verify & Validate User Requirements

1.3.2

Design System 1.3.3

Procure Hardware/Software

1.3.4

Install Development

System 1.3.5

Testing Phase 1.3.6

Install Live System 1.3.7

User Training 1.3.8

Go Live 1.3.9

Project Management

1.4.1

Project Status Meetings

1.4.2

Risk Management 1.4.3

Update Project Management Plan

1.4.4

Audit Procurement 1.5.1

Document Lessons Learned

1.5.2

Update Files/ Records

1.5.3

Gain Formal Acceptance

1.5.4

Archive Files/ Documents

1.5.5

Conventional WBS Issues

Prematurely structured around the product design

Prematurely decomposed, planned and budgeted into either too much detail or too little detail

They are project specific, and cross project comparison is impossible

33

Evolutionary WBS

An evolutionary WBS should organize around the PROCESS framework than around the product framework

Example (what the book says)First-level WBS elements are DisciplinesSecond-level elements are lifecycle phasesThird-level should focus on the activities that

produce the artefacts of every phase/iteration

34

WBS tailoring criteria

Project scale Organizational structure Custom development Business context Precedent experience

35

WBS Creation Activities Identifying the deliverables and related

work Structuring and organizing the WBS

Top-down approachChronological approachBottom-up approach

Developing and assigning identification codes to the WBS components

Verifying that the degree of decomposition of the work is necessary and sufficient. 36

WBS development guidelines

When to stop? What is the best level of detail? Whom should be involved?

37

WBS RACI

Responsible Accountable Consulted Informed

Project Manager X X

Project Team X

Project Review Authority

X

Project Stakeholders

X X

38

Project Plan Architecture

WBS is the project’s plan “architecture” It must encapsulate change It must evolve with the appropriate level of

detail through the project lifecycle It must cover ALL project tasks, and NO

MORE

39

WBS Structure by Phase

40

WBS By Discipline

41

Level of detail

Projects can under-plan as they can over-planBalance is crucial in finding the right level of

detailMust be detailed enough to buy in

stakeholders and still remain manageableNormally 3-7 levels

42

Is it a work package?

If you can estimate the work If it takes between 8 and 80 hours If you can complete it without interruption If you can outsource it

43

WBS in MS Project

44

Project organization

Closely linked to WBS Two organizations

MatrixProject

Plan for evolution and accommodate change

45

Project organization key points

Organizational structures form the architecture of the teams

Organizations involved in software line of business need to have an organization that supports a common process

Project organizations need to allocate artefacts and responsibilities clearly and balanced across project team(s)

The project organization must evolve with the WBS and the project lifecycle

46

GANTT (Visio)

47

GANTT (MS Project)

48

Network Diagrams

49

Network Diagram Details

50

Budgeting defaults example (no actual numbers)

WBS Discipline Budget(%)

Management 10

Environment 10

Requirements 10

Design 15

Implementation 25

Assessment 25

Deployment 5

Total 100 51

Generic WBS

Project WBS Template Software Development.mpp MSF Application Development.mpp

52

WBS for Agile Agile based WBS is built around user

functionality (“Epics”, “User stories”)

53

F(eature) BS

should provide business value should be estimable should be small enough to fit within an

iteration should be testable

54

EVM

55

EVM in Agile

56

Define WBS

57

Identify OBS

58

Wrap-up Use a top-down approach. Begin at the

project goal level and break the work successively to lower levels of definition.

Create it with the input from domain experts and team members.

Do not include any work which is not part of the project.

Cover the entire scope of the project at least at the upper level of the WBS

59

Wrap-up continued Each component of the WBS, excepting

the highest one, is a part of the parent WBS component.

The lowest level of the WBS shall have the following properties: It is possible to estimate its need for

resources, duration and costs. The start and the end of the execution can be

clearly defined.

60

Wrap-up continued

It's realization can be outsourced. It has a deliverable or a clear part of it.

It can be completed within reasonable time limits. There is no universally accepted rule regarding the length of an work package. However, it  shall not exceed 1-2 weeks to complete.

Specific to the software development projects, it can be executed by a single developer.

61

Next time

Scheduling

62