Lecture for Chapter 11, Project Management


Published on

Published in: Business, Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • The 90% syndrom is a problem that is particularly symptomatic for the linear waterfall lifecycle Another variant of Murphy's law Free change problem must be dealt with even in an iterative and incremental software lifecycle: time-boxed prototyping Introducing new bugs: This is a significant problem in old systems that did not use encapsulation: Global variables, etc Problem with hierarchical project management
  • Tthe central notion of project management is the software project. It defines the technical and managerial activities to develop a product and deliver it to the client. The central part of the managerial activities is the software project management plan. A project consists of activities, tasks, and functions.
  • Examples of tasks: Selection of a database management system (Database) Selection of a visualization system (Visualization) Selection of a user interface builder (UI) Reading the help bulletin board (TA) Define documentation and coding standards (Architecture)
  • 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!!
  • 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
  • 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.
  • Role switching: Used to work well for smaller groups. We still encourage switching of group leaders, but now for smaller times
  • Contingency when subsystems do not function properly? The liaisons of both teams get together to solve this problem Contigency when database takes too much time: The Database group defines a wrapper to be used by the other groups for limited form of data access while the search goes on. Contingency when client is not available. Use bboards, make decisions after keeping a record that client is not answering.
  • Each work package has to be uniquely defined. Identification may be based on a numbering scheme and/or descriptive titles. A diagram depicting the workbreak down structure into activities, subactivities and tasks my be used to depict hierarchical relationships among work packages. A work product is any tangible item that results from a project function, activity or task. Sometimes we call a work product also artifact. Deliverables are those work products that are to be delivered to the customer. The quantities, delivery dates and delivery locations are specified in the project agreement.
  • Let's cover in a little bit more detail the work elements First we begin by working to understand what the customer and users want. We list all the items that the customer expects to see during the development of the project. These items are called deliverables and can included anything the customer wants demonstrated or delivered as part of the project agreement. Note that the Workbreakdown structure is very much like a to-do list. It is useful to use a word processor that allows an outline feature, or a project management tool to start with a to-do list. Listing all the to-dos and ordering them into a hierarchical relationship (Task A consists of the subtasks A1, A2, ...) is the first activity of producing a project plan. The next step in the formulation of a project plan is to identify any dependencies between activities, tasks or functions. Note that dependency is another relation different from the “consists of” relation. Dependency is a relation between two tasks, activities or functions that denotes “must be preceded by”. If task A depends on another task B , in general it means that task B has to precede task A, otherwise task A cannot start or cannot get done.
  • “ Measure” for the complexity of the project
  • Let us take a look at an example of how to construct a project plan. We will be using a simple problem, namely building a house. If the lot has never been landscaped, then we can immediately identify two activities: Landscaping and Building the house. Note that even though I call them activities, initially I might not know how difficult or how long these tasks are and I could start with them as tasks. However, if I immediately know subtasks for these activities, I must call them activities. We view the Landscaping activity as an aggregration of three tasks: Clearing and grubbing, seeding and planting shrubs. Each of these activities can be defined as a work package in the sense of the IEEE standard: We can define the product (or deliverable): A clean lawn, the staffing requirements (landscaping company), the resources to be used (lawnmower, shovel) and the acceptance criteria for the work product (lot must be leveled), and the responsible person (group leader).
  • Any task or activity can be described with a set of parameters: The precursor (set of tasks to started/finished before this task can start) The duration (Length of time it will take to finish the task) The due date (for example due to a contractual deadline) The endpoint (usually a milestone)
  • Note the possible parallelism in the activity graph: The Exterior and Interior work can be done in parallel. However, none of these activities can be started before the Outside Wall is complete. Finishing the outside wall in time therefore is an important task.
  • This is another view of the project plan for building a house. Instead of an activity chart we are using a PERT chart. PERT charting comes from a technique called Program Evaluation and Review Technique, a popular technique for determining critical paths in a project. A critical path is the minimal amount of time it will take to complete a project, given estimates for the duration of each of the tasks. In addition, the critical path method reveals those tasks or activities that are most critical to completion. To determine the critical path in a project we have to learn the notion of slack time. For each node in our graph we comput two times: Real (Estimated) time and available time. The estimated time of a task is the time estimated for its completion. The available time is the amount of time available according to the overall schedule. Slack time is the difference between available and estimated (real) time for a task:
  • Slack time is a measure of how much we can goof off without causing major troubles for the project. If a task has no slack time, it means it has to be done immediately at the indicated start time. For example, surveying can start on day 1, so its earliest start time is day 1. However, because it takes 15 days to request and receive permits, surveying can begin as late as day 13 and still not hold up the project schedule.
  • Lecture for Chapter 11, Project Management

    1. 1. Chapter 11, Project Management
    2. 2. Outline <ul><li>Concepts and terminology </li></ul><ul><li>Purpose of Software Project Management Plans </li></ul><ul><li>Structure of a Project Management Plan </li></ul><ul><li>Project responsibilities </li></ul><ul><li>Team structures </li></ul><ul><li>Project planning </li></ul><ul><li>Work breakdown structure </li></ul><ul><li>Communication Management </li></ul><ul><li>Dependencies </li></ul><ul><li>Schedule </li></ul><ul><li>Project Management Tools </li></ul>
    3. 3. <ul><li>Reference: </li></ul><ul><ul><li>Bruegge&Dutoit, Chapter 12 </li></ul></ul><ul><ul><ul><li>http://notesbruegge.in.tum.de/PAID2/schedule/ProjectManagement011599.pdf </li></ul></ul></ul><ul><li>What is not covered in this lecture? </li></ul><ul><ul><li>Communication Management, Meeting Management </li></ul></ul><ul><ul><li>Bruegge & Dutoit, Chapter 4 </li></ul></ul><ul><ul><ul><li>http://notesbruegge.in.tum.de/PAID2/schedule/ProjectCommunication112598.pdf </li></ul></ul></ul><ul><ul><li>Cost estimation </li></ul></ul><ul><ul><ul><li>Reference: Software engineering economics, Barry Boehm, Prentice Hall 1981 </li></ul></ul></ul>
    4. 4. Laws of Project Management <ul><li>Projects progress quickly until they are 90% complete. Then they remain at 90% complete forever. </li></ul><ul><li>When things are going well, something will go wrong. When things just can’t get worse, they will. When things appear to be going better, you have overlooked something. </li></ul><ul><li>If project content is allowed to change freely, the rate of change will exceed the rate of progress. </li></ul><ul><li>Project teams detest progress reporting because it manifests their lack of progress. </li></ul>
    5. 5. How it should go
    6. 6. How it often goes
    7. 7. Software Project Management Plan <ul><li>Software Project: </li></ul><ul><ul><li>All technical and managerial activities required to deliver the deliverables to the client. </li></ul></ul><ul><ul><li>A software project has a specific duration, consumes resources and produces work products . </li></ul></ul><ul><ul><li>Management categories to complete a software project: </li></ul></ul><ul><ul><ul><li>Tasks, Activities, Functions </li></ul></ul></ul><ul><li>Software Project Management Plan: </li></ul><ul><ul><li>The controlling document for a software project. </li></ul></ul><ul><ul><li>Specifies the technical and managerial approaches to develop the software product. </li></ul></ul><ul><ul><li>Companion document to requirements analysis document: Changes in either may imply changes in the other document. </li></ul></ul><ul><ul><li>SPMP may be part of project agreement. </li></ul></ul>
    8. 8. Project Agreement <ul><li>Document written for a client that defines: </li></ul><ul><ul><li>the scope, duration, cost and deliverables for the project. </li></ul></ul><ul><ul><li>the exact items, quantities, delivery dates, delivery location. </li></ul></ul><ul><li>Can be a contract, a statement of work, a business plan, or a project charter. </li></ul><ul><li>Client: Individual or organization that specifies the requirements and accepts the project deliverables. </li></ul><ul><li>Deliverables (= Work Products that will be delivered to the client): </li></ul><ul><ul><li>Documents </li></ul></ul><ul><ul><li>Demonstrations of function </li></ul></ul><ul><ul><li>Demonstration of nonfunctional requirements </li></ul></ul><ul><ul><li>Demonstrations of subsystems </li></ul></ul>
    9. 9. Project Agreement vs Problem Statement
    10. 10. Project Management Activities (continued on next slide) Initiation Project kickoff Team formation Communication infrastructure setup Problem statement definition Initial milestones planning Initial top-level design
    11. 11. Installation Steady state Termination Client acceptance test Postmortem Project agreement Project replanning Status monitoring Risk management Project kickoff
    12. 12. Project: Functions, Activities and Tasks p:Project f1:Function f2:Function a1:Activity a2:Activity a3:Activity a2.1:Activity a2.2:Activity a2.3:Activity t1:Task t2:Task t3:Task t4:Task
    13. 13. Functions <ul><li>Activity or set of activities that span the duration of the project </li></ul>p:Project f1:Function f2:Function a1:Activity a2:Activity a3:Activity a2.1:Activity a2.2:Activity a2.3:Activity t1:Task t2:Task t3:Task t4:Task
    14. 14. Functions <ul><li>Examples: </li></ul><ul><ul><li>Project management </li></ul></ul><ul><ul><li>Configuration Management </li></ul></ul><ul><ul><li>Documentation </li></ul></ul><ul><ul><li>Quality Control (Verification and validation) </li></ul></ul><ul><ul><li>Training </li></ul></ul><ul><li>Question: Is system integration a project function? </li></ul><ul><li>Mapping of terms: Project Functions in the IEEE 1058 standard are called Integral processes in the IEEE 1074 standard. We call them cross-development processes </li></ul>
    15. 15. Tasks • Smallest unit of work subject to management • Small enough for adequate planning and tracking • Large enough to avoid micro management p:Project f1:Function f2:Function a1:Activity a2:Activity a2.1:Activity a2.2:Activity t1:Task t2:Task t3:Task
    16. 16. Tasks <ul><li>Smallest unit of management accountability </li></ul><ul><ul><li>Atomic unit of planning and tracking </li></ul></ul><ul><ul><li>Finite duration, need resources, produce tangible result (documents, code) </li></ul></ul><ul><li>Specification of a task: Work package </li></ul><ul><ul><li>Name, description of work to be done </li></ul></ul><ul><ul><li>Preconditions for starting, duration, required resources </li></ul></ul><ul><ul><li>Work product to be produced, acceptance criteria for it </li></ul></ul><ul><ul><li>Risk involved </li></ul></ul><ul><li>Completion criteria </li></ul><ul><ul><li>Includes the acceptance criteria for the work products (deliverables) produced by the task. </li></ul></ul>
    17. 17. Task Sizes <ul><li>Finding the appropriate task size is problematic </li></ul><ul><ul><li>Todo lists from previous projects </li></ul></ul><ul><ul><li>During initial planning a task is necessarily large </li></ul></ul><ul><ul><li>You may not know how to decompose the problem into tasks at first </li></ul></ul><ul><ul><li>Each software development activity identifies more tasks and modifies existing ones </li></ul></ul><ul><li>Tasks must be decomposed into sizes that allow monitoring </li></ul><ul><ul><li>Work package usually corresponds to well defined work assignment for one worker for a week or a month. </li></ul></ul><ul><ul><li>Depends on nature of work and how well task is understood. </li></ul></ul>
    18. 18. Examples of Tasks <ul><li>Unit test class “Foo” </li></ul><ul><li>Test subsystem “Bla” </li></ul><ul><li>Write user manual </li></ul><ul><li>Write meeting minutes and post them </li></ul><ul><li>Write a memo on NT vs Unix </li></ul><ul><li>Schedule the code review </li></ul><ul><li>Develop the project plan </li></ul><ul><li>Related tasks are grouped into hierarchical sets of functions and activities. </li></ul><ul><li>Action item </li></ul>
    19. 19. Action Item <ul><li>Definition: A task assigned to a person that has to be done within a week or less </li></ul><ul><li>Action items </li></ul><ul><ul><li>Appear on the agenda in the Status Section (See lecture on communication) </li></ul></ul><ul><ul><li>Cover: What?, Who?, When? </li></ul></ul><ul><li>Example of action items: </li></ul><ul><ul><li>Florian unit tests class “Foo” by next week </li></ul></ul><ul><ul><li>Marcus develops a project plan before the next meeting </li></ul></ul><ul><ul><li>Bob posts the next agenda for the Simulation team meeting before Sep 10, 12noon. </li></ul></ul><ul><ul><li>The VIP team develops the project plan by Sep 18 </li></ul></ul>
    20. 20. Activities • Major unit of work with precise dates • Culminates in project milestone. • Consists of smaller activities or tasks p:Project f1:Function f2:Function a1:Activity a2:Activity a2.1:Activity a2.2:Activity t1:Task t2:Task t3:Task
    21. 21. Activities <ul><li>Major unit of work </li></ul><ul><li>Culminates in major project milestone: </li></ul><ul><ul><li>Internal checkpoint should not be externally visible </li></ul></ul><ul><ul><li>Scheduled event used to measure progress </li></ul></ul><ul><li>Milestone often produces baseline: </li></ul><ul><ul><li>formally reviewed work product </li></ul></ul><ul><ul><li>under change control (change requires formal procedures) </li></ul></ul><ul><li>Activities may be grouped into larger activities: </li></ul><ul><ul><li>Establishes hierarchical structure for project (phase, step, ...) </li></ul></ul><ul><ul><li>Allows separation of concerns </li></ul></ul><ul><ul><li>Precedence relations often exist among activities (PERT Chart) </li></ul></ul>
    22. 22. Examples of Activities <ul><li>Major Activities: </li></ul><ul><ul><li>Planning </li></ul></ul><ul><ul><li>Requirements Elicitation </li></ul></ul><ul><ul><li>Requirements Analysis </li></ul></ul><ul><ul><li>System Design </li></ul></ul><ul><ul><li>Object Design </li></ul></ul><ul><ul><li>Implementation </li></ul></ul><ul><ul><li>System Testing </li></ul></ul><ul><ul><li>Delivery </li></ul></ul><ul><li>Activities during requirements analysis: </li></ul><ul><ul><li>Refine scenarios </li></ul></ul><ul><ul><li>Define Use Case model </li></ul></ul><ul><ul><li>Define object model </li></ul></ul><ul><ul><li>Define dynamic model </li></ul></ul><ul><ul><li>Design User Interface </li></ul></ul>
    23. 23. Structure of a Software Project Management Plan <ul><li>Front Matter </li></ul><ul><li>1. Introduction </li></ul><ul><li>2. Project Organization </li></ul><ul><li>3. Managerial Process </li></ul><ul><li>4. Technical Process </li></ul><ul><li>5. Work Elements, Schedule, Budget </li></ul><ul><li>Optional Inclusions </li></ul>
    24. 24. SPMP Part 0: Front Matter <ul><li>Title Page </li></ul><ul><li>Revision sheet (update history) </li></ul><ul><li>Preface: Scope and purpose </li></ul><ul><li>Tables of contents, figures, tables </li></ul>
    25. 25. SPMP Part 1: Introduction <ul><li>1.1 Project Overview </li></ul><ul><ul><li>Executive summary: description of project, product summary </li></ul></ul><ul><li>1.2 Project Deliverables </li></ul><ul><ul><li>All items to be delivered, including delivery dates and location </li></ul></ul><ul><li>1.3 Evolution of the SPMP </li></ul><ul><ul><li>Plans for anticipated and unanticipated change </li></ul></ul><ul><li>1.4 Reference Materials </li></ul><ul><ul><li>Complete list of materials referenced in SPMP </li></ul></ul><ul><li>1.5 Definitions and Acronyms </li></ul>
    26. 26. SPMP Part 2: Project Organization <ul><li>2.1 Process Model </li></ul><ul><ul><li>Relationships among project elements </li></ul></ul><ul><li>2.2 Organizational Structure </li></ul><ul><ul><li>Internal management, organization chart </li></ul></ul><ul><li>2.3 Organizational Interfaces </li></ul><ul><ul><li>Relations with other entities </li></ul></ul><ul><li>2.4 Project Responsibilities </li></ul><ul><ul><li>Major functions and activities; nature of each; who’s in charge </li></ul></ul>
    27. 27. Process Model <ul><li>Shows relationships among </li></ul><ul><ul><li>Functions, activities, tasks </li></ul></ul><ul><ul><li>Milestones </li></ul></ul><ul><ul><li>Baselines </li></ul></ul><ul><ul><li>Reviews </li></ul></ul><ul><ul><li>Work breakdown structure </li></ul></ul><ul><ul><li>Project deliverables </li></ul></ul><ul><ul><li>Sign-offs </li></ul></ul><ul><li>Visualization of process model </li></ul><ul><li>Project Management Aids </li></ul><ul><ul><li>MS Project (Microsoft) </li></ul></ul><ul><ul><li>MAC Project (Claris) </li></ul></ul><ul><ul><li>EasyTrak (Planning Control International) </li></ul></ul>
    28. 28. Example of an Organization Chart Client Management Consultants Cross-functional Teams Logbook Maintenance Vehicle Travel VIP Development Teams Infrastructure Team Architecture HCI Web Master Documentation Configuration Mgt
    29. 29. Project Roles <ul><li>Planner </li></ul><ul><li>Analyst </li></ul><ul><li>Designer </li></ul><ul><li>Programmer </li></ul><ul><li>Tester </li></ul><ul><li>Maintainer </li></ul><ul><li>Trainer </li></ul><ul><li>Document Editor </li></ul><ul><li>Web Master </li></ul><ul><li>Configuration Manager </li></ul><ul><li>Group leader </li></ul><ul><li>Liaison </li></ul><ul><li>Minute Taker </li></ul><ul><li>Project Manager </li></ul>
    30. 30. Project Roles <ul><li>Management roles </li></ul><ul><ul><li>Organization and execution of the project within constraints. Examples: project manager, team leader. </li></ul></ul><ul><li>Development roles </li></ul><ul><ul><li>Specification, design and construction of subsystems. Examples: Analyst, system architect, implementor. </li></ul></ul><ul><li>Cross functional roles </li></ul><ul><ul><li>Coordination of more than one team. Example: API Engineer, configuration manager, tester </li></ul></ul><ul><li>Consultant roles </li></ul><ul><ul><li>Support in areas where the project participants lack expertise. Examples: End user, client, application domain specialist ( problem domain), technical consultant (solution domain). </li></ul></ul><ul><li>Promoter roles </li></ul><ul><ul><li>Promote change through an organization. </li></ul></ul>
    31. 31. Promoter Roles <ul><li>Promoters are self appointed individuals who identify themselves with the outcome of the project. </li></ul><ul><li>They are member of the corporate organization and may not necessarily be directly involved with the project. Instead, they are interfaces to the rest of the corporate organization. </li></ul><ul><li>Because of the power, knowledge of technology, or familiarity with the project’s processes, they are able to promote and push specific changes through the organization. </li></ul>
    32. 32. Power Promoter <ul><li>Also called executive champion </li></ul><ul><li>Pushes the change through the existing organizational hierarchy. </li></ul><ul><ul><li>not necessarily at the top of the organization, but must have protection from top level management, otherwise project opponents might be able to prevent the success of the project. </li></ul></ul><ul><li>Tasks: </li></ul><ul><ul><li>constantly identify difficulties, resolve issues, and communicate with the project members, especially with the developers. </li></ul></ul><ul><li>Example at project level: Project Manager. </li></ul><ul><li>Example at corporate level: Chief Executive Officer (CEO). </li></ul>
    33. 33. Knowledge Promoter <ul><li>Also called the technologist, </li></ul><ul><li>Promotes change arising in the application domain or the solution domain. Usually associated with the power promoter. </li></ul><ul><li>Tasks: Acquire information iteratively, understand the benefits and limitations of new technologies, and argue its adoption with the other developers. </li></ul><ul><li>Example at project level: System architect. </li></ul><ul><ul><li>Reports to project manager </li></ul></ul><ul><ul><li>Does not have any direct subordinate in the reporting hierarchy </li></ul></ul><ul><ul><li>Has final say over all technical decisions in the system. </li></ul></ul><ul><li>Example at corporate level: Chief Technical Officer (CTO). </li></ul>
    34. 34. Process Promoter <ul><li>The process promoter has intimate knowledge of the projects processes and procedures. </li></ul><ul><li>The process promoter is in constant interaction with the power promoter to get consensus on the overall goals. </li></ul><ul><li>Tasks: Bridge between the power and knowledge promoters, who often do not speak or understand the same language. </li></ul><ul><li>Example at project level: Development lead. Responsible for the administrative aspects of a project, including planning, milestones definition, budgeting and communication infrastructure. </li></ul><ul><li>Example at corporate level: Chief Information Officer (CIO </li></ul>
    35. 35. Project Management: Hierarchical Project Organization Chief Executive First Level Manager (“Front-Line Manager”) Project Members Basis of organization: Complicated information and control flow across hierarchical boundaries A B A wants to talk to B: Complicated Information Flow A wants to make sure B does a certain change: Complicated Controlflow Information Flow Control Flow
    36. 36. Example of Hierchical Organization: Chief Programmer Team Chief Programmer Librarian Administration Tester Junior Programmer Assistant Chief Programmer Senior Programmer
    37. 37. Another Project Organization: Egoless Programming Team (Weinberg) Analyst Designer Librarian Tester Programmer
    38. 38. Project-Based Project Organization Project Leader Coaches Team Members Basis of organization: Nonlinear information flow across dynamically formed units Subsystem Team Subsystem Team Subsystem Team A B A wants to talk to B: Communication Flow A wants to make sure B does a certain change: Decision Flow
    39. 39. Associations in organizational structures <ul><li>Reporting association: </li></ul><ul><ul><li>Used for reporting status information </li></ul></ul><ul><li>Decision association </li></ul><ul><ul><li>Used for propagating decisions </li></ul></ul><ul><li>Communication association </li></ul><ul><ul><li>Used for exchanging information needed for decisions (e.g., requirements, design models, issues). </li></ul></ul>
    40. 40. Observations on Management Structures <ul><li>Hierarchical structures </li></ul><ul><ul><li>“ Reports”, “Decides” and “Communicates-With” all mapped on the same association </li></ul></ul><ul><ul><li>Do not work well with iterative and incremental software development process </li></ul></ul><ul><ul><li>Manager is not necessarily always right </li></ul></ul><ul><li>Project-based structures </li></ul><ul><ul><li>“ Reports”, “Decides” and “Communicates-With”are different associations </li></ul></ul><ul><ul><li>Cut down on bureaucracy reduces development time </li></ul></ul><ul><ul><li>Decisions are expected to be made at each level </li></ul></ul><ul><ul><li>Hard to manage </li></ul></ul>
    41. 41. Hierarchical Structure <ul><li>Projects with high degree of certainty, stability, uniformity and repetition. </li></ul><ul><ul><li>Requires little communication </li></ul></ul><ul><ul><li>Role definitions are clear </li></ul></ul><ul><li>When? </li></ul><ul><ul><li>The more people on the project, the more need for a formal structure </li></ul></ul><ul><ul><li>Customer might insist that the test team be independent from the design team </li></ul></ul><ul><ul><li>Project manager insists on a previously successful structure </li></ul></ul>
    42. 42. Project-Based Structure <ul><li>Project with degree of uncertainty </li></ul><ul><ul><li>Open communication needed among members </li></ul></ul><ul><ul><li>Roles are defined on project basis </li></ul></ul><ul><li>When? </li></ul><ul><ul><li>Requirements change during development </li></ul></ul><ul><ul><li>New technology develops during project </li></ul></ul>
    43. 43. Assigning Responsibilities To People “ To Do” List for the Project • Item 1 • Item 2 • Item 3 • Item 4 • Item 5 • Item 6 • Item 7 • Item 8 • Item 9 Item 1 Item 2 Item 9 Role 1 Item 4 Item 5 Item 7 Role 2 Item 3 Item 6 Item 8 Role 3 Person A Role 1 Role 2 Person B Role 3 Team A
    44. 44. Possible Mappings of ToDos to People <ul><li>One-to-One </li></ul><ul><ul><li>Ideal but often not worth to be called a project </li></ul></ul><ul><li>Many-to-Few </li></ul><ul><ul><li>Each project member assumes several roles (&quot;hats&quot;) </li></ul></ul><ul><ul><li>Danger of overcommittment </li></ul></ul><ul><ul><li>Need for load balancing </li></ul></ul><ul><li>Many-to-&quot;Too-Many&quot; </li></ul><ul><ul><li>Some people don't have significant roles </li></ul></ul><ul><ul><li>Bystanders </li></ul></ul><ul><ul><li>Loosing touch with project </li></ul></ul>
    45. 45. Team Formation <ul><li>Top level Design </li></ul><ul><ul><li>“ Rough” Subsystem Decomposition (before requirements analysis) </li></ul></ul><ul><ul><li>Done during Predevelopment phase </li></ul></ul><ul><li>Team Formation done after Top Level Design </li></ul><ul><li>Heuristics: </li></ul><ul><ul><li>One team for each subsystem </li></ul></ul><ul><ul><li>One cross-functional task per team </li></ul></ul><ul><ul><li>5-7 members per team </li></ul></ul><ul><li>Be prepared to iterate the team formation after system design when the subsystem decomposition is baselined </li></ul>
    46. 46. Project Roles: Coach <ul><li>Listen to gripes from individual teams </li></ul><ul><li>Review weekly team reports </li></ul><ul><li>Attend weekly project meetings </li></ul><ul><li>Schedule and prepare meetings with client </li></ul><ul><li>Insist that guidelines are followed </li></ul><ul><li>Assign presentations (in-class project meetings, client review, client acceptance test) </li></ul><ul><li>Resolve conflicts if they cannot be resolved otherwise </li></ul>
    47. 47. Project Role: Group leader <ul><li>Responsible for intra-group communication (Meeting Management: Primary Facilitator) </li></ul><ul><ul><li>Run the weekly project meeting </li></ul></ul><ul><ul><li>Post agenda before meeting </li></ul></ul><ul><ul><li>Define and keep track of action items (who, what, when) </li></ul></ul><ul><ul><li>Measure progress (Enforce milestones) </li></ul></ul><ul><ul><li>Deliver work packages for the tasks to the project management </li></ul></ul><ul><ul><li>Present problems and status of team to project manager </li></ul></ul><ul><li>The group leader has to be rotated among members of the team. </li></ul>
    48. 48. Group Leader: Create an Agenda <ul><li>Purpose of Meeting </li></ul><ul><li>Desired Outcome </li></ul><ul><li>Information Sharing </li></ul><ul><li>Information Processing </li></ul><ul><li>Meeting Critique </li></ul>Action Items (Check Previous Meeting) Issues (Check Previous Meeting & BBoards)
    49. 49. Project Role: Liaison <ul><li>Responsible for inter-group communication </li></ul><ul><ul><li>Make available public definitions of subsystem developed by the team to the architecture teams (ensure consistency, etc) </li></ul></ul><ul><ul><li>Coordinate tasks spanning more than one group with other teams </li></ul></ul><ul><li>Responsible for team negotiations </li></ul><ul><li>Examples: API Engineer, Configuration manager </li></ul>
    50. 50. Project Role: Planner <ul><li>Plans and tracks the activities of an individual team and has the following responsibilities. </li></ul><ul><li>Define project plan for team: </li></ul><ul><ul><li>PERT chart, resource table and GANTT chart showing work packages </li></ul></ul><ul><ul><li>Enter project plan into project management tool </li></ul></ul><ul><li>Make project plan available to management </li></ul><ul><li>Report team status to project manager No explicit planner in PAID. Responsibilities assumed by coaches </li></ul>
    51. 51. Project Role: Document Editor <ul><li>Collect, proofread and distribute team documentation </li></ul><ul><li>Submit team documentation to architecture team </li></ul><ul><li>Collect agendas </li></ul><ul><li>Take minutes at meetings </li></ul>
    52. 52. Web Master <ul><li>Maintain team home page </li></ul><ul><li>Keep track of meeting history </li></ul><ul><li>Keep track of design rationale </li></ul>
    53. 53. Web Master: <ul><li>Publish Meeting Information on Team Homepage </li></ul><ul><ul><li>Must contain Agenda, minutes, action items and issues </li></ul></ul><ul><ul><li>Possibilities: </li></ul></ul><ul><ul><ul><li>One HTML document per meeting, with anchors (maintained by one role) </li></ul></ul></ul><ul><ul><ul><li>Separate HTML documents for Agenda, Minutes, etc (maintained by several roles) </li></ul></ul></ul><ul><li>http://cascade1.se.cs.cmu.edu/ 15-413/homePagesTeams/UserInterface/www/index.htm </li></ul>Date 9/9/96 Agenda Minutes Action Items Issues Agenda Minutes Action Items Issues 9/16/96 Agenda Minutes Action Items Issues
    54. 54. SPMP Part 3: Managerial Processes <ul><li>3.1 Management Objectives and Priorities </li></ul><ul><ul><li>Philosophy, goals and priorities </li></ul></ul><ul><li>3.2 Assumptions, Dependencies, Constraints </li></ul><ul><ul><li>External factors </li></ul></ul><ul><li>3.3 Risk Management </li></ul><ul><ul><li>Identifying, assessing, tracking, contingencies for risks </li></ul></ul><ul><li>3.4 Monitoring and Controlling Mechanisms </li></ul><ul><ul><li>Reporting mechanisms and formats, information flows, reviews </li></ul></ul><ul><li>3.5 Staffing Plan </li></ul><ul><ul><li>Needed skills (what?, how much?, when?) </li></ul></ul>
    55. 55. Examples of Assumptions <ul><li>There are enough cycles on the development machines </li></ul><ul><li>Security will not be addressed </li></ul><ul><li>There are no bugs in Together-J, the CASE Tool recommended for the project </li></ul><ul><li>A demonstration of the Starnetwork system will be given by the client </li></ul>
    56. 56. Examples of Dependencies <ul><li>The database team depends on the EPC database provided by DaimlerChrysler </li></ul><ul><li>The automatic code generation facility in the CASE tool depends on JDK. The current release of Together-J supports only JDK 1.1.6 </li></ul>
    57. 57. Examples of Constraints <ul><li>The length of the project is 3 months. limited amount of time to build the system </li></ul><ul><li>The project consists of beginners. It will take time to learn how to use the tools </li></ul><ul><li>Not every project member is always up-to-date with respect to the project status </li></ul><ul><li>The use of UML and a CASE tool is required </li></ul><ul><li>Any new code must be written in Java </li></ul><ul><li>The system must use Java JDK 1.1.6 </li></ul>
    58. 58. Risk Management <ul><li>Risk: Members in key roles drop the course. </li></ul><ul><ul><li>Contingency: Roles are assigned to somebody else. Functionality of the system is renegotiated with the client. </li></ul></ul><ul><li>Risk: The project is falling behind schedule. </li></ul><ul><ul><li>Contingency : Extra project meetings are scheduled. </li></ul></ul><ul><li>Risk: One subsystem does not provide the functionality needed by another subsystem. </li></ul><ul><ul><li>Contingency: ? </li></ul></ul><ul><li>Risk: Ibutton runs only under JDK 1.2 </li></ul><ul><ul><li>Contingency: ? </li></ul></ul>
    59. 59. SPMP Part 4: Technical Process <ul><li>4.1 Methods, Tools and Techniques </li></ul><ul><ul><li>Computing system, development method, team structure, etc. </li></ul></ul><ul><ul><li>Standards, guidelines, policies. </li></ul></ul><ul><li>4.2 Software Documentation </li></ul><ul><ul><li>Documentation plan, including milestones, reviews and baselines. </li></ul></ul><ul><li>4.3 Project Support Functions </li></ul><ul><ul><li>Plans for functions (quality assurance, configuration management). </li></ul></ul>
    60. 60. SPMP Part 5: Work Elements <ul><li>5.1 Work Packages (Work breakdown structure) </li></ul><ul><ul><li>Project decomposed into tasks; definitions of tasks </li></ul></ul><ul><li>5.2 Dependencies </li></ul><ul><ul><li>Precedence relations among functions, activities and tasks </li></ul></ul><ul><li>5.3 Resource Requirements </li></ul><ul><ul><li>Estimates for resources such as personnel, computer time, special hardware, support software. </li></ul></ul><ul><li>5.4 Budget and Resource Allocation </li></ul><ul><ul><li>Connect costs to functions, activities and tasks. </li></ul></ul><ul><li>5.5 Schedule </li></ul><ul><ul><li>Deadlines, accounting for dependencies, required milestones </li></ul></ul>
    61. 61. Creating Work Packages <ul><li>Work Breakdown Structure (WBS) (Section 5.1) </li></ul><ul><ul><li>Break up project into activities (phases, steps) and tasks. </li></ul></ul><ul><ul><li>The work breakdown structure does not show the interdependence of the tasks </li></ul></ul><ul><li>The identification of the work breakdown structure is an instance of object identification and associating these objects </li></ul>
    62. 62. WBS Trade-offs <ul><li>Work breakdown structure influences cost and schedule </li></ul><ul><li>Thresholds for establishing WBS in terms of percentage of total effort: </li></ul><ul><ul><li>Small project (7 person-month): at least 7% or 0.5 PM </li></ul></ul><ul><ul><li>Medium project (300 person-month): at least 1% or 3 PMs </li></ul></ul><ul><ul><li>Large project (7000 person-month): at least 0.2 % or 15 PMs </li></ul></ul><ul><li>Determination of work breakdown structure is incremental and iterative </li></ul>
    63. 63. Dependencies and Schedule (SPMP Section 5.2 + 5.5) <ul><li>An important temporal relation: “must be preceded by” </li></ul><ul><li>Dependency graphs show dependencies of the tasks (hierarchical and temporal) </li></ul><ul><ul><li>Activity Graph: </li></ul></ul><ul><ul><ul><li>Nodes of the graph are the project milestones </li></ul></ul></ul><ul><ul><ul><li>Lines linking the nodes represent the tasks involved </li></ul></ul></ul><ul><ul><li>Schedule Chart (MS-Project): </li></ul></ul><ul><ul><ul><li>Nodes are tasks and milestones </li></ul></ul></ul><ul><ul><ul><li>Lines represent temporal dependencies </li></ul></ul></ul><ul><li>Estimate the duration of each task </li></ul><ul><li>Label dependency graph with the estimates </li></ul>
    64. 64. Project Management Tools for Work Packages <ul><li>Visualization Aids for Project Presentation </li></ul><ul><ul><li>Graphs (Schedule), Trees (WBS) </li></ul></ul><ul><ul><li>Tables (Resources) </li></ul></ul><ul><li>Task Timeline </li></ul><ul><ul><li>Gantt Charts: Shows project activities and tasks in parallel. Enables the project manager to understand which tasks can be performed concurrently. </li></ul></ul><ul><li>Schedule Chart (PERT Chart) </li></ul><ul><ul><li>Cornerstone in many project management tools </li></ul></ul><ul><ul><li>Graphically shows dependencies of tasks and milestones </li></ul></ul><ul><ul><ul><li>PERT: Program Evaluation and Review Technique </li></ul></ul></ul><ul><ul><ul><ul><li>A PERT chart assumes normal distribution of tasks durations </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Useful for Critical Path Analysis </li></ul></ul></ul></ul><ul><ul><ul><li>CPM: Critical Path Method </li></ul></ul></ul>
    65. 65. Project: Building a House <ul><li>Activity 1: Landscaping the lot </li></ul><ul><ul><li>Task 1.1: Clearing and grubbing </li></ul></ul><ul><ul><li>Task 1.2: Seeding the Turf </li></ul></ul><ul><ul><li>Task 1.3: Planting shrubs and trees </li></ul></ul><ul><li>Activity 2: Building the House </li></ul><ul><ul><li>Activity 2.1 : Site preparation </li></ul></ul><ul><ul><li>Activity 2.2: Building the exterior </li></ul></ul><ul><ul><li>Activity 2.3: Finishing the interior </li></ul></ul><ul><li>Activity 2.1 : Site preparation </li></ul><ul><ul><li>Task 2.1.1: Surveying </li></ul></ul><ul><ul><li>Task 2.1.2: Obtaining permits </li></ul></ul><ul><ul><li>Task 2.1.3: Excavating </li></ul></ul><ul><li>Task 2.1.4: Obtaining materials </li></ul>
    66. 66. Activity 2: Building a House, ctd <ul><li>Activity 2.2: Building the exterior </li></ul><ul><ul><li>Task 2.2.1: Foundation </li></ul></ul><ul><ul><li>Task 2.2.2: Outside Walls </li></ul></ul><ul><ul><li>Task 2.2.3: Exterior plumbing </li></ul></ul><ul><ul><li>Task 2.2.4: Exterior electrical work </li></ul></ul><ul><ul><li>Task 2.2.5: Exterior siding </li></ul></ul><ul><ul><li>Task 2.2.6: Exterior painting </li></ul></ul><ul><ul><li>Task 2.2.7: Doors and Fixtures </li></ul></ul><ul><ul><li>Task 2.2.8: Roof </li></ul></ul><ul><li>Activity 2.3 : Finishing the Interior </li></ul><ul><ul><li>Task 2.3.1: Interior plumbing </li></ul></ul><ul><ul><li>Task 2.3.2: Interior electrical work </li></ul></ul><ul><ul><li>Task 2.3.3: Wallboard </li></ul></ul><ul><ul><li>Task 2.3.4: Interior painting </li></ul></ul><ul><ul><li>Task 2.3.5: Floor covering </li></ul></ul><ul><ul><li>Task 2.3.6: Doors and fixtures </li></ul></ul>
    67. 67. Activity Graph for Activity “Building a House”
    68. 68. PERT Chart Example for &quot;Building a House&quot; Start Time Slack Time MS Project PERTcy Chart with Duration of Activities (Pfleeger 2.3) Duration Building a House: START 8/27/94 0 0 Request Permits 8/27/94 15 0 Survey ing 8/27/94 3 12 Excava tion 9/17/94 10 0 Legend 8/29/94 0 0 Buy Material 10/1/94 10 0 Lay Founda tion 10/15/94 15 0 Build Outside Wall 11/5/94 20 0 Install Exterior Plumbing 12/3/94 10 12 Install Interior Plumbing 12/3/94 12 0 Install Exterior Electrical 12/17/94 10 12 Install Interior Electrical 12/21/94 15 0 Install Exterior Siding 12/31/94 8 12 Install Wallboard 1/11/95 9 0 Paint Exterior 1/12/95 5 12 Install Roofing 1/19/95 9 12 Install Flooring 1/22/95 18 0 Paint Interior 1/22/95 11 0 Install Interior Doors 2/8/95 7 0 Install Exterior Doors 1/19/95 6 15 FINISH 2/16/95 0 0
    69. 69. Slack Time and Critical Path <ul><li>Slack Time </li></ul><ul><ul><li>Available Time - Estimated (“Real”) Time for a task or activity </li></ul></ul><ul><ul><li>Or: Latest Start Time - Earliest Start Time </li></ul></ul><ul><li>Critical Path </li></ul><ul><ul><li>The path in a project plan for which the slack time at each task is zero. </li></ul></ul><ul><li>The critical path has no margin for error when performing the tasks (activities) along its route. </li></ul>
    70. 70. How do you become a good project planner? <ul><li>Establish a project plan </li></ul><ul><ul><li>Start with the plan based on your experience with the last project(s) </li></ul></ul><ul><li>Keep track of activities and their duration </li></ul><ul><li>Determine difference between planned and actual performance </li></ul><ul><li>Make sure to do a post-mortem </li></ul><ul><ul><li>Lessons learned </li></ul></ul><ul><ul><li>Ask developers for feedback </li></ul></ul><ul><ul><li>Write a document about what could have been improved </li></ul></ul>
    71. 71. Writing the SPMP <ul><li>Example full SPMPs </li></ul><ul><li>OWL project </li></ul><ul><ul><li>http://cascade1.se.cs.cmu.edu/15-413/courseDocs/spmpF96.html </li></ul></ul><ul><li>JAMES project </li></ul><ul><ul><li>http://cascade1.se.cs.cmu.edu/JAMES/J_courseDocs/SPMP/SPMP1.0.html </li></ul></ul>
    72. 72. Project Management Heuristics <ul><li>Make sure to be able to revise or dump a project plan </li></ul><ul><ul><li>Complex system development is a nonlinear activity </li></ul></ul><ul><li>If project goals are unclear and complex use team-based project management. In this case </li></ul><ul><ul><li>Avoid GANTT charts and PERT charts for projects with changing requirements </li></ul></ul><ul><ul><li>Don’t look too far into the future </li></ul></ul><ul><li>Avoid micro management of details </li></ul><ul><li>Don’t be surprise if current project management tools don’t work: </li></ul><ul><ul><li>They were designed for projects with clear goals and fixed organizational structures </li></ul></ul>
    73. 73. Project Management Summary <ul><li>Get agreement among customers, managers and teams </li></ul><ul><ul><li>Problem statement </li></ul></ul><ul><ul><li>Software project management plan </li></ul></ul><ul><ul><li>Project agreement </li></ul></ul><ul><ul><li>Make sure agreement allows for iteration </li></ul></ul><ul><li>Organization Structures </li></ul><ul><li>SPMP </li></ul><ul><li>Project planning </li></ul><ul><ul><li>Start with work breakdown structure (WBS) </li></ul></ul><ul><ul><li>Identify dependencies and structure: Tasks, activities, functions </li></ul></ul><ul><li>Tools and Techniques </li></ul><ul><ul><li>GANTT, Dependency graph, Schedule, Critical Path Analysis </li></ul></ul><ul><ul><li>Be careful with tools in projects with a lot of change </li></ul></ul>