Chapter 14: Project Management

1. Chapter 14: Project Management

2. Outline • Work breakdown structure • What is it? • Building a work breakdown structure • Project scheduling • Dependency diagrams • Estimating task durations • Project organization • Types of organizations • Communications infrastructure • Software Project Management Plan (SPMP) • Overview of project control activities

3. Work Breakdown Structure • The hierarchical representation of all the tasks in a project is called the work breakdown structure (WBS). First Version of a UML Model • But Tasks are Parts of Activities. What would be a better model?

4. Tasks • Smallest unit of management accountability • Atomic unit of planning and tracking • Tasks have finite duration, need resources, produce tangible result (documents, code) • Specification of a task: Work package • Name, description of work to be done • Preconditions for starting, duration, required resources • Work product to be produced, acceptance criteria for it • Risk involved • Completion criteria • Includes the acceptance criteria for the work products (deliverables) produced by the task.

5. Major unit of work Culminates in major project milestone: Internal checkpoint should not be externally visible Scheduled event used to measure progress Milestone often produces project baselines: formally reviewed work product under change control (change requires formal procedures) Activitites may be grouped into larger activities: Establishes hierarchical structure for project (phase, step, ...) Allows separation of concerns Precedence relations often exist among activities Activities

6. Creating Work Breakdown Structures • Two major philosophies • Activity-oriented decomposition (“Functional decomposition”) • Write the book • Get it reviewed • Do the suggested changes • Get it published • Result-oriented (“Object-oriented decomposition”) • Chapter 1 • Chapter 2 • Chapter 3 • Which one is best for managing? Depends on project type: • Development of a prototype • Development of a product • Project team consist of many unexperienced beginners • Project team has many experienced developers

7. Developing Work Breakdown Structures • There are several different approaches to develop and display a work breakdown structure. Each is effective under different circumstances • Approaches to break activities into detail by • Product component approach • Examples: Design documents, manuals, the running system • Functional approach • Analysis, design, implementation, integration, testing, delivery, reviews • Geographical area • Examples: USA team, China team, India team, ... • Organizational approach • Research, product development, marketing, sales

8. When to use what approach • Distributed teams: • Geographical area approach • Experienced teams: • Product component approach • Project has mostly beginners or project manager is inexperienced: • Functional approach • Project is a continuation of previously successful projects, no change in requirements, no new technology • Organizational approach • When you choose an approach, stick with it to prevent possible overlap in categories

9. How do you develop a good WBS? • Top down approach: • Start at the highest, top level activities and systematically develop increasing levels of detail for all activities. • Brainstorming: • Generate all activities you can think of that will have to be done and then group them into categories. • Which one you use depends on • how familiar you and your team are with the project, • whether similar projects have successfully been performed in the past, and • how many new methods and technologies will be used.

10. The Top Down WBS approach • Specify all activities required for the entire project to be finished • Determine all task required to complete each activity • If necessary specify subactivities required to complete each task • Continue in this way until you have adequately detailed your project. • Approach is good if • You are or your team is familiar with the problem. • You have successfully managed a similar project in the past • You are not introducing new methodologies, methods or tools

11. Top-down example: Architecture-centric approach • Work with architect to come up with a tentative top-level design (software architecture) at the beginning of the project and use this decomposition to determine the work breakdown structure. • Top-level decomposition can be functional or object-oriented. • This approach is a deviation from traditional practices and may be feasible in certain domains with emerging standard architectures. • This architecture is used strictly for decomposing the project tasks. • Architecture must be revisited during system design after requirements analysis. • Project tasks may also be reorganized to reflect the changed architecture.

12. The Brainstorming WBS approach • On a single list, write any activities you think will have to be performed for your project. • Brainstorming means you • Don’t worry about overlap or level of detail • Don’t discuss activity wordings or other details • Don’t make any judgements • Write everything down • Then study the list and group activities into a few major categories with common characteristics. • If appropriate group activities under a smaller number of tasks • Consider each category you have created and use the top-down WBS approach to determine any additional activities you may have overlooked.

13. Displaying Work Breakdown Structures • Three different formats are usually used • Organization-chart format: • Effectively portrays an overview of your project and the hierarchical relationships of different activities and tasks. • Outline format • Subactivities and tasks are indented • Bubble format • The bubble in the center represents your project • Lines from the center bubble lead to activities • Lines from activities lead to tasks

14. Prepare Report Prepare Draft Report Review Draft Report Prepare Final Report Write Final Report Print Final Report Review Final Report Review Draft Report Prepare Report Print Final Report Review Draft Report Write Final Report Prepare Report 1.0 Prepare draft report 2.0 Review draft report 3.0 Prepare final report 3.1 Write final report 3.2 Print final report Org-Chart Format Outline Format Bubble Format

15. Best format for displaying WBS? • Org-chart format: • Often good for a “bird view” of the project (executive summaries,...) • Less effective for displaying large numbers of activities • Outline format: • Easier to read and understand if WBS contains many activities • Bubble format: • Effective for supporting the brainstorming process • Not so good for displaying work breakdown structures to audiences who are not familiar with the project. • Use bubble format to develop the WBS, then turn it into Org-Chart or outline format. • In large projects: • Use a combination of org-chart and outline formats: • Display activities in org-chart format, • Display subactivities and tasks in outline format.

16. Heuristics for developing high quality WBS • Involve the people who will be doing the work in the development of the WBS • In particular involve the developers • Review and include information from work breakdown structures that were developed for similar projects • Use a project template if possible • Use more than one WBS approach • Do project component and functional approach simultaneously • This allows you often to identify overlooked activities • Make assumptions regarding uncertain activities • Identify risky activities • These are often the activities that whose times are hard to estimate • Keep your current work breakdown structure currentUpdate your WBS regularly

17. Heuristic: Use Templates • Try to derive the WBS from a template, either an existing one or one that you start developing with this project. • A template reflects the cumulative experience gained from doing numerous projects of a particular type. • Using templates can save you time and improve your accuracy • When developing templates, develop them for frequently performed tasks (reviews, meetings, …). “Checklists” • Develop and modify your WBS templates from previous projects that worked, not from plans that looked good. • Use templates as starting points, not as ending points • Continually update your templates to reflect the experience gained from performing different projects.

18. Heuristic: Develop always more than one WBS • Consider to create more several different hierarchies with different categories for your work breakdown structure. • Having two or more different perspectives helps you identify activities you may overlook. • Good starting point are the following hierarchies: • Entity-oriented decomposition • Activity-oriented decomposition • Example: You are running your first object-oriented project. • Develop a WBS based on the project documents • Develop a WBS based on the software process activities

19. WBS Based on Project Documents (Entity-oriented) <<Name>> Project Problem Statement Project Agreement RAD SDD - Write Introduction - Write Requirements - Write Constraints - ... - Write Requirements - Write Constraints - Write Acceptance Criteria - Promise delivery date - Write Introduction - Describe Functional Model - Describe Object Model - Describe Dynamic Model ... - Write Design Goals - Write Hardware Software mapping -Write boundary conditions - Write Data Management - Write Open Issues ...

20. WBS Based on Software Process (Activity-oriented) <<Name>> Project Project Initiation Planning Analysis Design - Establish guidelines - Formulate requirements with client - Establish scenarios - Write project agreement - Determine WBS - Determine dependencies between tasks - Write SPMP - Assign teams to subsystems - Establish project calendar - Brainstorm on application domain objects - Develop class diagram - Partition objects into boundary, entity and control objects - Develop use cases - Develop Models - Write code - Present problems to coach - Give status reports - Write RAD - Write SDD - Write ODD Question: Which activities mentioned in the WBS based on Project documents is left out in the WBS based on Software Process?

21. Heuristic: Identifying Risky activities • When you identify activities for a work breakdown structure, you can also identify the risks in your project. • Risks are usually associated with “unknown information”. • Unknown information comes in two flavors • A known unknown: Information that you don’t have but someone else does. • Find out who has the information and determine what the information is. (Interviews, Phone calls, tasks analysis) • An unknown unknown: Information that you don’t have because it does not yet exist. • Develop contingency plans for each of these risks. • These contingency plans need be followed when you find out the information does not exist.

22. Choose a single WBS format • Writing the WBS in different formats is good, because it allows you to identify activities that you may have overlooked • However, after you identify these activities add them to either WBS • Choose a single WBS format to be used in the SPMP and for your project: • Nothing confuses people fast than trying to use two different work breakdown structures to describe the same project.

23. How Detailed should the WBS be? • Sometimes the activities are not clear at all, especially in software projects: • Unclear requirements and/or changing requirements • Dependency on technology enablers that appear or are promised to appear after project kickoff • Simultaneous development of hardware and software (“concurrent engineering”) • A project plan, especially for an innovative software project, should not address details beyond 3 months. • Even for the first 3 months project activities might not all be detailable, for example when the requirements are unclear or change or introduction of technology enablers is expected. • How should we describe a WBS for a longer project?

24. Doing a WBS for Long-Term Projects • When developing a work breakdown structure for a long-term project (longer than 3 months), introduce at least two phases • Phase 1 (3 months): Plan your WBS in detail • Here list all activities that take two weeks or less to complete • Phase 2, Phase 3, … (n-months) Plan the WBS for these phases in less and less detail • Here list activities that you estimate will take between one and two months • At the end of phase 1, revise the phase 2 activities to the two week level for the next 3 months. • Modify any future activities as necessary based on the results of your first three months work. • Continue to revise the SPMP this way throughout the project. (SPMP as an “evolving” document)

25. Outline • Work breakdown structure • What is it? • Building a work breakdown structure • Project scheduling • Dependency diagrams • Estimating task durations • Project organization • Types of organizations • Communications infrastructure • Software Project Management Plan (SPMP) • Overview of project control activities

26. From the WBS to the Dependency Diagram • The work breakdown structure does not show any temporal dependence among the activities/tasks • Can we excavate before getting the permit? • How much time does the whole project need if I know the individual times? • What can be done in parallel? • Are there any critical actitivites, that can slow down the project significantly? • Temporal dependencies are shown in the dependency diagram • Nodes are activities • Lines represent temporal dependencies

27. Dependency Diagrams (Overview) • Dependency diagrams consist of 3 elements • Event (also called milestone): A significant occurrence in the life of a project. • Activity: Work required to move from one event to the next. • Span time ( also called duration or elapsed time): The actualcalendar time required to complete an activity. • Span time parameters: people’s availability, parallelizability of the activity, availability of nonpersonnel resources, …. • Dependency Diagram are drawn as a connected graph of nodes and arrows. • 2 commonly used diagram notations to display dependency diagrams: • 1) Activity-on-the-arrow (Mealy automaton) • 2) Activity-in-the-node (Moore automaton)

28. Why Dependency Diagrams? • Example: • You are assigned a project consisting of 10 activities which take one week each to be completed. • How long does the project take? • When projects have more than 15-20 activities, one cannot to compute the schedule in the head any more. • Dependency Diagrams are a formal notation to help in the construction and analysis of complex schedules

29. B A t Event (Milestone or Deliverable) Event (Milestone or Deliverable) System Design RAD SDD T1 = 4 weeks 1) Activity-on-the-arrow Diagram Notation Activity Span Time

30. PERT • PERT is an activity-on-the-arrow notation • PERT = Program Evaluation and Review Technique • Developed in the 50s to plan the Polaris weapon system in the USA. • PERT allows to assign optimistic, pessimistic and most likely estimates for the span times of each activity. • You can then compute the probability to determine the likelihood that overall project duration will fall within specified limits.

31. A tA = 0 B tB = 0 C tC = 0 Event (Milestone or Deliverable) Event (Milestone or Deliverable) System Design t = 2 weeks RAD available t = 0 SDD available t = 0 2) Activity-in-the-node Diagram Notation Activity A Node is either an event or an activity. Distinction: Events have span time 0 Milestone boxes are often highlighted by double-lines

32. Activity 1 t1 = 5 Start t = 0 End t = 0 Activity5 5= 2 Example of an Activity-in -the -Node Diagram Activity 2 t2 = 1 Activity 3 t3 = 1 Activity 4 t4 = 3

33. What do we do with these diagrams? • Compute the project duration • Determine activities that are critical to ensure a timely delivery • Analyse the diagrams • to find ways to shorten the project duration • To find ways to do activities in parallel • 2 techniques are used • Forward pass (determine critical paths) • Backward pass (determine slack time)

34. Definitions: Critical Path and Slack Time • Critical path: • A sequence of activities that take the longest time to complete • The length of the critical path(s) defines how long your project will take to complete. • Noncritical path: • A sequence of activities that you can delay and still finish the project in the shortest time possible. • Slack time: • The maximum amount of time that you can delay an activity and still finish your project in the shortest time possible.

35. Activity 1 t1 = 5 Activity 1 t1 = 5 Start t = 0 Start t = 0 End t = 0 End t = 0 Activity5 5= 2 Activity5 t5 = 2 Critical path in bold face Example of a critical path Activity 2 t2 = 1 Activity 3 t3 = 1 Activity 4 t4 = 3

36. Definitions: Start and Finish Dates • Earliest start date: • The earliest date you can start an activity • Earliest finish date: • The earliest date you can finish an activity • Latest start date: • The latest date you can start an activity and still finish the project in the shortest time. • Latest finish date: • The latest date you can finish an activity and still finish the project in the shortest time.

37. 2 Ways to Analyze Dependency Diagrams • Forward pass: Goal is the determination of critical paths • Compute earliest start and finish dates for each activity • Start at the beginning of the project and determine how fast you can complete the activites along each path until you reach the final project milestone. • Backward pass: Goal the determination of slack times • Compute latest start and finish dates activity • Start at the end of your project, figure out for each activity how late it can be started so that you still finish the project at the earliest possible date. • To compute start and finish times, we apply 2 rules • Rule 1: After a node is finished, we can proceed to the next node(s) that is reachable via a transition from the current node. • Rule 2: To start a node all nodes must be complete from which transitions to that node are possible.

38. Activity 2 t2 = 1 Activity 1 t1 = 5 Start t = 0 End t = 0 Activity 3 tA = 1 Activity 4 tA = 3 Activity5 t5 = 2 Forward Path Example Activity 2 t2 = 1 Activity Earliest Start(ES) Earliest Finish(EF) Project Duration = 7 Activity 3 t3 = 1 Activity 4 t4 = 3 A1 Start of week 1 End of week 5 A2 Start of week 6 End of week 6 A3 Start of week 1 End of week 1 A4 Start of week 2 End of week 4 A5 Start of week 6 End of week 7

39. Activity 2 t2 = 1 Activity 1 t1 = 5 Start t = 0 End t = 0 A1 End of week 5 Activity 3 tA = 1 Activity 4 tA = 3 Activity5 t5 = 2 A4 End of week 5 Backward Path Example Activity 2 t2 = 1 Activity Latest Start(LS) Latest Finish(LF) Project Duration = 7 Activity 3 t3 = 1 Activity 4 t4 = 3 Start of week 1 A2 End of week 7 Start of week 7 A3 End of week 2 Start of week 2 Start of week 3 A5 End of week 7 Start of week 6

40. Activity 2 t2 = 1 Activity 1 t1 = 5 Start t = 0 End t = 0 Activity 2 t2 = 1 Activity 3 tA = 1 Activity 4 tA = 3 Activity5 t5 = 2 Activity A1 A2 A3 A4 A5 Slack time 0 1 1 1 0 Activity 4 t4 = 3 Computation of slack times • Slack time ST of an activity A: • STA = LSA - ESA • Subtract the earliest start date from the latest start date for each activity Example: STA4 = 3 - 2 = 1 Slack times on the same path influence each other. Example: When Activity 3 is delayed by one week, activity 4 slack time becomes zero weeks.

41. Path types in dependency graphs • Critical path: Any path in a dependency diagram, in which all activities have zero slack time. • Noncritical path: Any path with at least one activity that has a nonzero slack time. • Overcritical path: A path with at least one activity that has a negative slack time. • Overcritical paths should be considered as serious warnings: Your plan contains unreal time estimates • Any dependency diagram with no fixed intermediate milestones has at least one critical path. • A project schedule with fixed intermediate milestones might have no critical path • Example: The analysis review must be done 1 month after project start, the estimated time for all activities before the review is 3 weeks.

42. Frequently used formats for dependency graphs • Milestone View (“Key-Events report”): • A table that lists milestones and the dates on which you plan to reach them. • Activities View: • A table that lists the activities and the dates on which you plan to start and end them • Gantt chart View: • A graphical illustrating on a timeline when each activity will start, be performed and end. • Combined Gantt Chart and Milestone View: • The Gantt Chart contains activities as well as milestones.

43. Key-Events Report (example) Date Milestone August 26 Project Kickoff (with Client) October 16 Analysis Review October 26 System Design Review November 7 Internal Object Design Review November 20 Project Review (with Client) Nov 26 Internal Project Review Dec 11 Acceptance Test (with Client) Good for introduction of SPMP and high executive briefings

44. Activities View DateProject Phases Jul 17-Aug 23 Preplanning Phase Aug 26 - Sep 24 Project Planning Sep 11-Oct 8 Requirements Analysis Oct 9 - Oct 26 System Design Oct 28-Nov 7 Object Design Nov 8 - Nov 20 Implementation & Unit Testing Nov 22 - Dec 4 System Integration Testing Dec 4 - Dec 10 System Testing Dec 11- Dec 18 Post-Mortem Phase Good during developer meetings

45. Gantt Chart Activity 1 Activity 2 Activity 3 Activity 4 Activity 5 0 1 2 3 4 5 6 7 Time (in weeks after start) Easy to read

46. Project Start Design Review Project Finish with milestones Gantt Chart Activity 1 Activity 2 Activity 3 Activity 4 Activity 5 0 1 2 3 4 5 6 7 Time (in weeks after start) • Good for reviews.

47. Person-Centered View To determine people‘s load Activity-Centered View To identify teams working together on the same tasks Two Types of Gantt Charts Joe A1 A2 A3 A1 Joe, Toby Mary Joe A2 Toby A1 A3 A3 Clara, Toby, Joe Clara A3 Time Time Choose one view, stay with it. Usually base the view on the WBS structure Managing Experienced Teams: Person-centered view Managing Beginners: Activity oriented view

48. Tools support for Establishing Schedules • Tool support for • Graphical user interface for entering activity data • Automatic computation of critical paths • Multiple views (PERT, Gantt, table views) and switching between these views • Many products available. Examples • Fast Track (http://www.aecsoft.com) • Main view: Gantt Charts • Microsoft Project • PERT Charts, Gantt Charts, combined Milestone/Gantt Charts • Tool use and training beyond the scope of this class

49. How to develop an Initial Project Schedule • Identify all your activities (reuse a template if possible) • Identify intermediate and final dates that must be met • Assign milestones to these dates • Identify all activities and milestones outside your project that may affect your project’s schedule • Identify “depends on” relationships between all these identified activities • Draw a dependency diagram for all identified activities and relationships • Analyze the diagram to determine critical paths and slack times of noncritical paths. • Example: Establish a schedule for system integration testing

50. Finding the appropriate task size is problematic Todo lists from previous projects During initial planning a task is necessarily large You may not know how to decompose the problem into tasks at first Each software development activitity identifies more tasks and modifies existing ones Tasks must be decomposed into sizes that allow monitoring Work package usually corresponds to well defined work assignment for one worker for a week or a month. Depends on nature of work and how well task is understood. Determining Task Sizes