Chapter 14: Project Management

Outline Overview Concepts Activities Tasks and activities Work products, packages, and roles Work breakdown structure Task model Skill matrix Organizations Visualizing organization structures Spectrum of organizational structures Software Project Management Plan Activities Planning the project Organizing the project Controlling the project Terminating the project

Outline Work breakdown structure Project scheduling 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

Work package vs Work product Definitions from the IEEE Standard Work Package: A specification for the work to be accomplished in an activity or task Work Product: Any tangible item that results from a project function, activity or task. Project Baseline: A work product that has been formally reviewed and agreed upon. A project baseline can only be changed through a formal change procedure Project Deliverable: A work product to be delivered to the client

How can we model a work product? What is a tangible item? Requirements Analysis Document Software Project Management Plan Agenda, Minutes How do we model Tangible Items?

Work products are related to Activities How do we model this?

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?

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.

Activities 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

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

Estimates for establishing WBS Establishing an WBS in terms of percentage of total effort: Small project (7 person-month): at least 7% or 0.5 PM Medium project (300 person-month): at least 1% or 3 PMs Large project (7000 person-month): at least 0.2 % or 15 PMs (From Barry Boehm, Software Economics)

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

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

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.

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

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.

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.

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

Prepare Report 1.0 Prepare draft report 2.0 Review draft report Final Report Write Print 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 Review Draft Report Prepare Report Final Report Print Write Bubble Format

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.

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 current Update your WBS regularly

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.

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

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

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?

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.

Risk Management Examples Risk: Members in key roles leave the project. Contingency Plan? Roles are assigned to somebody else. Functionality of the system is renegotiated with the client. Risk: The project is falling behind schedule. Extra project meetings are scheduled. Risk: Team 1 cannot provide functions needed by team 2. The liaisons of both teams get together to solve this problem Risk: The SPOT computer will not be available. We will use an IPAQ instead.

Risk Management Examples ctd Risk: The selection of the DBMS takes too much time Contingency Plan? The Database team uses a bridge pattern and provides a test stub to be used by the other teams for data access while the selection process goes on. Risk: The customer is not available for discussing and reviewing the user interface during development. Make the design decisions that we feel are appropriate Risk: No suitable wireless library can be found. The wireless team develops its own library

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.

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?

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)

Outline Work breakdown structure Project scheduling 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

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

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 actual calendar 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)

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

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

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.

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

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

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)

Definitions: Critical Path and Slack Time 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.

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

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.

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.

Forward Path Example Activity Earliest Start(ES) Earliest Finish(EF) End Activity5 t5 = 2 Activity 2 t2 = 1 Project Duration = 7 Activity 3 t3 = 1 Activity 4 t4 = 3 Activity Earliest Start(ES) Earliest Finish(EF) 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

Backward Path Example Activity Latest Start(LS) Latest Finish(LF) End Activity5 t5 = 2 Activity 2 t2 = 1 Project Duration = 7 Activity 3 t3 = 1 Activity 4 t4 = 3 Activity Latest Start(LS) Latest Finish(LF) A1 End of week 5 A4 End of week 5 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

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. Activity 3 tA = 1 Activity 4 tA = 3 Activity 2 t2 = 1 Start t = 0 Activity 1 t1 = 5 End Activity5 t5 = 2 t4 = 3 Activity A1 A2 A3 A4 A5 Slack time 1

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.

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.

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

Activities View Date Project 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

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

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

Two Types of Gantt Charts Person-Centered View To determine people‘s load Activity-Centered View To identify teams working together on the same tasks Joe A1 A2 A3 A1 Joe, Toby Mary A2 Joe 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

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

What do we cover now? How to develop an initial project schedule How to shorten the project duration Mistakes made during preparation of schedules The danger of fudge factors How to identify when a project goes off-track (actual project does not match the project plan). How to become a good software project manager

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

Developing a Schedule for Integration Testing Five Steps: 1. Start with System Decomposition 2. Determine your Integration Testing Strategy 3. Determine the Dependency Diagram (UML Activity Diagram) 4. Add Time Estimates 5. Visualize the activities on a time scale: Gantt Chart See Bruegge&Dutoit 2003, Chapter 9 Testing

1. Start with System Decomposition

2. Determine Your Integration Testing Strategy Types of integration testing strategies We choose sandwich testing. Why? It allows many parallel testing activities, possibly shortening testing time Sandwich testing requires 3 layers Reformulate the system decomposition into 3 layers if necessary Identification of the 3 layers and their components in our example Top layer: A Target layer: B, C, D Bottom layer: E, F, G

Sandwich Testing Sandwich testing combines parallel top-down and bottom-up integration testing Top-down testing tests the top layer incrementally with the components of the target layer Bottom-up testing tests the bottom layer incrementally with the components of the target layer Modified sandwich testing is more thorough Individual layer tests Top layer test with stubs for target layer Target layer test with drivers and stubs replacing top and bottom layers Bottom layer test with a driver for the target layer Combined layer tests Top layer access the target layer Target layer accesses bottom layer

3. Determine the Dependency Diagram (Sandwich Testing , UML Activity Diagram) Target layer components: B, C, D

Dependency Diagram for a Modified Sandwich Testing Strategy

4. Add Time Estimates (PERT Chart)

5. Visualize your Schedule (Gantt Chart View )

What do we cover now? How to develop an initial project schedule How to shorten the project duration Mistakes made during preparation of schedules The danger of fudge factors How to identify when a project goes off-track (actual project does not match the project plan). How to become a better software project manager

Determining Task Sizes 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.

How to reduce the planned project time Recheck the original span time estimates Ask other experts to check the estimates Has the development environment changed? (batch vs interactive systems, desktop vs laptop development) Hire more experienced personnel to perform the activities Trade-off: Experts work fast, but cost more Consider different strategies to perform the activities Consider to Buy a work product instead of building it (Trade-off: Buy-vs-build) Consider extern subcontractor instead of performing the work work internally Try to find parallelizable activites on the critical path Continue coding while waiting for the results of a review Risky activity, portions of the work may have to be redone. Develop an entirely new strategy to solve the problem

Typical Mistakes when Developing Schedules The “Backing in” Mistake Using Fudge Factors

The “Backing in” Mistake Definition “Backing In”: You start at the last milestone of the project and work your way back toward the starting milestone, while estimating durations that will add up to the amount of the available time Problems with Backing in: You probably miss activities because your focus is on meeting the time constraints rather than identifying the required work Your span time estimates are based on what you allow activites to take, not what they actually require The order in which you propose activities may not be the most effective one. Instead, start with computing all the required times and then try to shorten the project duration

Using Fudge Factors Parkinson formulated this law for project completion: Work tends to expand to fill the time allotted for it. Fudge factor: A fudge factor is the extra amount of time you add to your best estimate of span time “just to be safe”. Example: Many software companies double their span time estimates. Don’t use fudge factors because of Parkinson’s law. If an activity takes 2 weeks, but you add a 50% fudge factor, chances are almost zero that it will be done in less then 3 weeks.

Heuristics for dealing with time 1. First Set the Project Start Time => Determines the planned project time Determine the critical path(s) 2. Then try to reduce the planned project time If you want to get your project done in less time, you need to consider ways to shorten the aggregate time it takes to complete the critical path. Avoid fudge factors

How to become a better project manager Don’t assume anything Take the time to find out the facts. Use assumptions only as a last resort. With every assumption comes a risk that you are wrong. Communicate clearly with your people. Being vague does not get your more leeway, it just increases the chances for misunderstanding. Acknowledge good performance Tell the person, the person’s boss, team members, peers. View your people as allies not as adversaries Focus on common goals, not on individual agendas. Make people comfortable by encouraging brainstorming and creative thinking Be a manager and a leader Deal with people as well as to deliverables, processes and systems. Create a sense of vision and excitement.

Outline Work breakdown structure Project scheduling 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

Organization Definition Organization: A set of organizational units and their different relationships with each other. Organizational units can be organized according to many different categories, for example by function or by project type. Typical examples of organizational units: Functional organization: Research, Development, Marketing, Sales Project organization: Project 1, Project 2, …. A organization usually has 3 different types of relationships between organizational units. Reporting structure: To report status information Decision structure: To propagating decisions Communication structure: To exchange of information

Roadmap for the lecture We will first discuss different organization forms. Functional organization Project organization Matrix organization Then we talk about the different roles played by people in these organizations Project manager, team member, upper management, …. Then we discuss relationships between the roles Hierarchical organizations Nonhierarchical organizations

Functional Organization Definition: In a functional organization participants are grouped into so-called departments, each of which addresses a function. Examples of departments: Traditional businesses: Research, development, production, sales, finance. In software companies the departments correspond to the activities in the software process: Analysis, design, integration, testing departments. Key properties: Projects are usually pipelined through the departments of a functional organization. The project starts in research, then it moves to development, then it moves to production, …. Only a few participants are involved in the complete project. Separate departments often address the same cross-functional needs (Examples: configuration management, IT infrastructure)

Example of a Functional Organization Executive Office Finance Production Sales Marketing Region1 Region1 Region1 Region1 Region2 Region2 Region2 Region2 IT IT IT IT Line organization of a „traditional business“

Properties of Functional Organizations Advantages: Members of a department have a good understanding of the functional area they support. Departments don‘t compete with another to get the support of their support teams Disadvantages: Because each department has its own support team, different work procedures and reporting systems are the rule. It is difficult to make major investments in equipment and facilities. Example: Two departments with a budget of 50,000 Euro each need a printer that costs 100,000 Euro. Both need only 50% of the maximum capacity. Neither department can buy it, because they don‘t have sufficient funds. High chance for overlap or duplication of work among departments

Project Organization In a project organization participants are grouped into projects, each of which has a problem to be solved within time and budget. Key properties: Teams are assembled for a project as it is created. Each project has a project leader. All participants are involved in the complete project. Teams are disassembled when the project terminates

Properties of Project Organizations Advantages Very responsive to new project requests (because the project is newly established and can be tailored around the problem) New people can be hired/selected who are very familiar with the problem or who have special capabilities. There is no waste of staff workload Disadvantages: Teams cannot be assembled rapidly. Often it is difficult to manage the staffing/hiring process. Because there are “no predefined lines”, roles and responsibilities need to be defined at the beginning of the project

Participants of Project A Participants of Project B Matrix Organization In a matrix organization, participants from different departments of the functional organizastion are assigned to work on projects as they are created. The project manager and team members may be assigned to the project for <= 100 % of their time Executive Office Finance Production Sales Marketing Project A Participants of Project A Project B Participants of Project B Project C

Properties of Matrix Organizations Advantages: Teams for projects can be assembled rapidly Scarce expertise can be applied to different projects as needed Consistent work and reporting procedures can be used for projects of the same type. Disadvantages: Team members usually are not familiar with each Team member have different working styles Team members must get used to each other

New Challenges in Matrix Organizations Team members must respond to two different bosses with different focus: Focus of the functional manager: Assignments to different projects, performance appraisal Focus of the project manager: Work assignments, project team support Team members working on multiple projects have competing demands for their time Team members working on more than one project have even more project members to report to Some people who have claim on the team member’s time may be at similar levels in the organization’s hierarchy Multiple work procedures and reporting systems are used by different team members Development of common procedures needs to be addressed at project kickoff time

When to use a Functional Organization Projects with high degree of certainty, stability, uniformity and repetition. Requires little communication Role definitions are clear When? The more people on the project, the more need for a formal structure Customer might insist that the test team be independent from the design team Project manager insists on a previously successful structure We are using several heuristics that have worked well in previous project courses. Give the size of this project, it does not necessarily mean that they are successful in this project.

When to Use a Project or Matrix Organization Project with degree of uncertainty Open communication needed among members Roles are defined on project basis When? Requirements change during development New technology develops during project

Metamodel for Organizations Functional Organization Project Organization Matrix Organization

Key Roles in Organizations Project Manager: The person ultimately responsible for the successful completion of the project Project Team Member: Participants who are responsible for performing individual activities and tasks (in a project or matrix organization) Functional Manager: The team member‘s supervisor in the department (in a functional organization) Upper management: People in charge of the departments or projects In the following we focus only on roles in project and matrix organizations

Relationships between Roles Organizations can have many different types of associations between roles The three most important associations for project organizations are: Reporting, decision making and communicating Reporting association: Used for reporting status information Decision association Used for propagating decisions Communication association Used for exchanging information needed for decisions (e.g., requirements, design models, issues).

An Organization with a Reporting and Decision Structure The developers make local decisions and reports them via a status report to the leader (team leader, project manager) The team leader, who has a local overview of the subsystem, can override these decisions. She reports them to the project manager. The project manager, who has a global view of the project, can virtually override any decision.

An Organization with Distinct Reporting, Decision and Communication Structures Developers communicate with each other without having to communicate with the team leader or project leader. Developers make local decisions and report them to the leader The team leader, who has a local overview of the subsystem, can override these decisions. She reports them to the project manager. The project manager, who has a global view of the project, can virtually override any decision.

Hierarchical Organization Often also called centralized organization. Examples: Military, church, traditional businesses. Key property: The organization has a tree structure. Decisions are made at the root and communicated to the leaf nodes. The decision association is also used for reporting and communication. Advantages: Centralized control over project selection One set of management and reporting procedures for all project participants across all projects Established working relationships among people Clearly established lines of authority to set priorities and resolved conflicts Authority to pressure people to honor their action items Clearly defined career path

Hierarchical Project Organization Control Flow Information Flow Chief Executive First Level Manager (“Front-Line Manager”) Project Members A B A wants to talk to B: Complicated Information Flow B wants to make sure A does a certain change: Complicated Controlflow Basis of organization: Complicated information and control flow across hierarchical boundaries

Example of a Hierarchical Organization: Chief Programmer Team [Brooks 1995] Assistant Chief Programmer Totally hierarchical Talk about the roles: Chief the main dictator, assistant joined the company 2 years ago... Batch oriented When talking abou the libriarian, play somebody who is pushing a shopping cart at the Giant Eagle: Dispatching the lineprinter printouts to the various offices!! Senior Programmer Librarian Administration Tester Junior Programmer

Disadvantages of Hierarchical Organizations Slow response time The process of evaluating and approving change requests often takes too long because of long reporting/decision lines. Difficult to manage the workload of the people: People are assigned fulltime to the organization, but projects don’t’ come in a smooth stream. Project request might not require the people who are available or their expertise. Unfamiliarity with application or solution domain area People are usually hired for their technical proficiency in a specialty that the organization normally performs. They often have only limited experience, if the problem to be solved is outside of their field of expertise.

Nonhierarchical Organizations Key property: The organization has a general graph structure with different edges for the decision, reporting and communication flows. Decisions can be made at various nodes in the graph.

Nonhierarchical Project Organization Leader Coaches Project-based organizations create bridges within organizations and bridge boundaries outside with customers, suppliers, and competitors. Teams are the foundation unit of these new patterns of interconnection and interdependence. Telecommunications technology is the nervous system that holds these networks together. Groupware is the collaboration support technology that shapes and holds the activity of teams within those networks." Project-based organizations are based on the fct that ever-shifting networks of teams that cross traditional, formerly forbidden boundaries, linking once-competing organizations into ecosystems of cooperation Subsystem Team Subsystem Team Subsystem Team A B Team Members A wants to talk to B: Communication Flow B wants to make sure A does a certain change: Decision Flow Basis of organization: Nonlinear information flow across dynamically formed units

A Nonhierarchical Organization: Egoless Programming [Weinberg 1971] Analyst Tester Programmer Designer Librarian

Observations on Organizational Structures Hierarchical structure “Reports”, “Decides” and “Communicates-With” all mapped on the same association Does not work well with iterative and incremental software development process Manager is not necessarily always right Project-based structures “Reports”, “Decides” and “Communicates-With”are different associations Cuts down on bureaucracy Reduces development time Decisions are expected to be made at each level Hard to manage

Heuristics for Project Managers 1. Create team identity Clarify team vision and working relationships Define team procedures (meeting management, configuration management, system integration strategy) Clarify each participant‘s authority Make sure your team is functioning Be sure only one person is assigned as project manager 2. Create team member buy-in Get commitment to the project goals (tough in matrix environment) Get to know other people‘s style 3. Get support from the environment Get a project champion (for example a power promoter) 4. Develop general procedures for Conflict resolution Communication between teams and project leaders, communication with upper management and for communication with the client

Outline Work breakdown structure Project scheduling 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

IEEE Std 1058: Standard for Software Project Management Plans (SPMP) What it does: Specifies the format and contents of software project management plans. It provides a standard set of abstractions for a project manager or a whole organization to build its set of practices and procedures for developing software project management plans Abstractions: Project, Function, Activities, Tasks What it does not do: It does not specify the procedures or techniques to be used in the development of the plan It does not provide examples .

Software Project Management Plan Template 0. Front Matter 1. Introduction 2. Project Organization 3. Managerial Process 4. Technical Process 5. Work Elements, Schedule, Budget Optional Inclusions

Outline Work breakdown structure Project scheduling 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

Project Control Project management does not end with the creation of the project plan. Project management is responsible for project control during the steady state phase of the project. Project control activities Project tracking Development teams are kept accountable for executing their assigned tasks according to plan. The plan must be evolved as new tasks are uncovered or estimated tasks durations are corrected. Risk monitoring Contingency plans are drawn up as risks become serious threats to the successful completion of the project. Examples include: shifting priorities, reorganizing teams, redefining the problem statement, modifying the project schedule, etc. Quality control Software quality metrics are tracked to ensure that defects are being found. Configuration management

Identifying When a Project Goes Off-Track Determine what went wrong: Why is your project got off track? Behind schedule Overspending of resource budgets Not producing the desired deliverables Identify the Reason(s): You are new on the job, this is your first project, and you made mistakes Key people left the teams or new ones are joining it Key people lost interest or new ones entered the picture The requirements have changed New technology has emerged The business objectives have changed Organizational priorities have shifted (for example after a merger)

Heuristics to get a project back on track Reaffirm your plan Reaffirm your key people Reaffirm your project objectives Reaffirm the activities remaining to be done Reaffirm roles and responsibilities Refocus team direction and commitment Revise estimates, develop a viable schedule Modify your personnel assignments Hold a midproject kickoff session Closely monitor and control performance for the remainder of the project Get practical experience

Summary Software engineering is a problem solving activity Must develop quality software for a complex problem within a limited time while things are changing We need system models (object models, dynamic models, etc.) and management models (WBS, dependency diagrams, issue models, etc.) WBS: Set of activities to do (“use cases”) Dependency diagram: identify dependency relationships between activities Schedule: Dependency diagram with estimates of task durations Development teams may be organized by function or by project Communication infrastructure is also needed for reporting, decision propagation, and exchanging information Project control is the project management role during the steady state portion of the software project.