1. The project structure (WBS) 24-March-2015 1

2. Recap Software Development Planning 2

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

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

5. Recap - Planning timeline 5

6. Project Planning Process Areas Developing the Project Plan Interacting with Stakeholders Getting Commitment to Plan Maintaining the Plan 6

7. Specific Goals Establish Estimates Develop a Project Plan Obtain Commitment to the Plan 7

8. Role: Project Manager (RUP) 8

9. Project Planning Roles and Responsibilities ResponsibleAccountableConsultedInformed Project Management XX Project Stakeholders XX Project TeamXX Project Review Authority X 9

10. Activities for developing the SDP Develop the SDP project management content Develop enclosed project management plans Coordinate the development of supporting plans 10

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

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

13. Planning the “WHAT” Planning the “what” is crucial One frequent reason projects fail is that a significant part of the work is forgotten! 13

14. Project Scope Management Scope Planning Scope Definition Create WBS Scope Verification Scope Control 14

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

16. Scope Definition Detailed project scope statement Change Requests Project Scope Management Plan update 16

17. Scope Definition [1] Detailed project scope statement  Project Objectives (Specific, Measurable, Attainable, Relevant, Time-limited)  Requirements  Boundaries  Deliverables  Acceptance Criteria  Constraints  Assumptions 17

18. Scope Definition [2] Detailed project scope statement  Initial Organization  Initial Risk  Milestones  Fund limitations  Cost estimate  Configuration Management Requirements  Specifications  Approval Requirements 18

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

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

21. Scope Verification Accepted deliverables Change Requests Recommend corrective actions 21

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

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

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

25. WBS Introduction 25

26. WBS Dictionary 26

27. WBS Goals Improve estimates Keep the team focused Assign work to resources Keep the project on track 27

28. WBS 28

29. WBS Example Build a House Plans development ArchitectureResilienceConstructionConcreteWallsRoof 29

30. WBS Example Level 1Level 2Level 3 1 Widget Managem ent System 1.1 Initiation1.1.1 Evaluation & Recommendations 1.1.2 Develop Project Charter 1.1.3 Deliverable: Submit Project Charter 1.1.4 Project Sponsor Reviews Project Charter 1.1.5 Project Charter Signed/Approved 1.2 Planning1.2.1 Create Preliminary Scope Statement 1.2.2 Determine Project Team 1.2.3 Project Team Kickoff Meeting 1.2.4 Develop Project Plan 1.2.5 Submit Project Plan 1.2.6 Milestone: Project Plan Approval 30

31. 31 Level 1Level 2Level 3 1Widget Manageme nt System 1.3 Execution1.3.1 Project Kickoff Meeting 1.3.2 Verify & Validate User Requirements 1.3.3 Design System 1.3.4 Procure Hardware/Software 1.3.5 Install Development System 1.3.6 Testing Phase 1.3.7 Install Live System 1.3.8 User Training 1.3.9 Go Live 1.4 Control1.4.1 Project Management 1.4.2 Project Status Meetings 1.4.3 Risk Management 1.4.4 Update Project Management Plan 1.5 Closeout1.5.1 Audit Procurement 1.5.2 Document Lessons Learned 1.5.3 Update Files/Records 1.5.4 Gain Formal Acceptance 1.5.5 Archive Files/Documents

32. 32

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

34. 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 Disciplines  Second-level elements are lifecycle phases  Third-level should focus on the activities that produce the artefacts of every phase/iteration 34

35. WBS tailoring criteria Project scale Organizational structure Custom development Business context Precedent experience 35

36. WBS Creation Activities Identifying the deliverables and related work Structuring and organizing the WBS  Top-down approach  Chronological approach  Bottom-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

37. WBS development guidelines When to stop? What is the best level of detail? Whom should be involved? 37

38. WBS RACI ResponsibleAccountableConsultedInformed Project ManagerXX Project TeamX Project Review Authority X Project Stakeholders XX 38

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

40. WBS Structure by Phase 40

41. WBS By Discipline 41

42. Level of detail Projects can under-plan as they can over- plan  Balance is crucial in finding the right level of detail  Must be detailed enough to buy in stakeholders and still remain manageable  Normally 3-7 levels 42

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

44. WBS in MS Project 44

45. Project organization Closely linked to WBS Two organizations  Matrix  Project Plan for evolution and accommodate change 45

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

47. GANTT (Visio) 47

48. GANTT (MS Project) 48

49. Network Diagrams 49

50. Network Diagram Details 50

51. Budgeting defaults example (no actual numbers) WBS DisciplineBudget(%) Management10 Environment10 Requirements10 Design15 Implementation25 Assessment25 Deployment5 Total100 51

52. Generic WBS Project WBS TemplateTemplate Software Development.mpp MSF Application Development.mpp 52

53. WBS for Agile Agile based WBS is built around user functionality (“Epics”, “User stories”) 53

54. F(eature) BS should provide business value should be estimable should be small enough to fit within an iteration should be testable 54

55. EVM 55

56. EVM in Agile 56

57. Define WBS 57

58. Identify OBS 58

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

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

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

62. Next time Scheduling 62