4/28/10 31P5 Software Engineering I


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
  • 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
  • 4/28/10 31P5 Software Engineering I

    1. 1. 31P5: Software Engineering I Project Management
    2. 2. Aims <ul><li>Understand the term “project management” </li></ul><ul><li>Organize teams </li></ul><ul><li>Specify project management plans </li></ul><ul><li>Define and retire risks </li></ul><ul><li>Estimate costs very early in the life cycle </li></ul><ul><li>Create high level projects schedules </li></ul><ul><li>Write a Software Project Management Plan </li></ul>
    3. 3. Software Engineering Roadmap Development process - when to do what phase - document: SPMP Management structure - hierarchical, peer,... Risk identification & retirement Plan project Integrate & test system Analyze requirements Design Maintain Test units Implement Corporate practices Development phases Schedule Cost estimate SPMP
    4. 4. The Variables of Project Management <ul><li>Can somewhat vary the following factors. </li></ul><ul><li>1. The total cost of the project, </li></ul><ul><ul><li>e.g., increase expenditures </li></ul></ul><ul><li>2. The capabilities of the product, </li></ul><ul><ul><li>e.g., subtract from a list of features </li></ul></ul><ul><li>3. The quality of the product, </li></ul><ul><ul><li>e.g., increase the mean time between failure </li></ul></ul><ul><li>4. The date on which the job is completed. </li></ul><ul><ul><li>e.g., reduce the schedule by 20% </li></ul></ul><ul><ul><li>e.g., postpone project's completion date one month </li></ul></ul>
    5. 5. Bullseye Figure for Project Variables cost capability duration defect density Target : $70K Target : 30 wks Target : 4 defects/Kloc Target : 100%
    6. 6. Bullseye Figure for Project Variables cost capability duration defect density Target : $70K Actual : 100% Target : 30 wks Target : 4 defects/Kloc this project Actual : 1 defect/Kloc Actual : 20 wks Actual : $90K Target : 100%
    7. 7. Road Map for Project Management 1. Understand project content, scope, & time frame 2. Identify development process ( methods, tools, languages, documentation and support ) 3. Determine organizational structure (organizational elements involved) 4. Identify managerial process (responsibilities of the participants) 6. Develop staffing plan 5. Develop schedule ( times at which the work portions are to be performed ) 7. Begin risk management 8. Identify documents to be produced 9. Begin process itself
    8. 8. 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>
    9. 9. 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>
    10. 10. Project Agreement vs Problem Statement
    11. 11. 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
    12. 12. Installation Steady state Termination Client acceptance test Postmortem Project agreement Project replanning Status monitoring Risk management Project kickoff
    13. 13. 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
    14. 14. 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
    15. 15. 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>
    16. 16. 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
    17. 17. 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>
    18. 18. Task Sizes <ul><li>Finding the appropriate task size is problematic </li></ul><ul><ul><li>To do 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>
    19. 19. 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>
    20. 20. 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>
    21. 21. 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
    22. 22. 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>
    23. 23. 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>
    24. 24. 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>
    25. 25. 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>
    26. 26. 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>
    27. 27. 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>
    28. 28. 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>
    29. 29. 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
    30. 30. 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>
    31. 31. Kinds of people <ul><li>Two people for the same job title may differ in at least one of the following ways: </li></ul><ul><ul><li>ability to perform the work </li></ul></ul><ul><ul><li>interest in the work </li></ul></ul><ul><ul><li>experience with similar applications </li></ul></ul><ul><ul><li>experience with similar tools or languages </li></ul></ul><ul><ul><li>experience with similar techniques </li></ul></ul><ul><ul><li>experience with similar development environment </li></ul></ul><ul><ul><li>training </li></ul></ul><ul><ul><li>ability to communicate with others </li></ul></ul><ul><ul><li>ability to share responsibility with others </li></ul></ul><ul><ul><li>management skills </li></ul></ul><ul><li>Each of these characteristics can affect an individual’s ability to perform productively </li></ul>
    32. 32. Work styles <ul><li>You can think of your preferred work style in terms of two components: </li></ul><ul><ul><li>the way in which your thoughts are communicated and ideas gathered, and </li></ul></ul><ul><ul><li>the degree to which your emotions affect decision making </li></ul></ul><ul><li>When communicating ideas, some people tell others their thoughts, and some ask for suggestions from others before forming an opinion </li></ul><ul><li>Jung (1959) called the former extroverts , and the latter i ntroverts </li></ul><ul><li>Similarly, intuitive people base their decisions on feelings about and emotional reaction to a problem </li></ul><ul><li>Others are rational , deciding primarily by examining the facts and carefully considering options </li></ul>
    33. 33. Work styles <ul><li>Intuitive introverts are creative but apply creativity only after having gathered sufficient information on which to base a decision </li></ul><ul><li>Intuitive extroverts base many decisions on emotional reaction, tending to want to tell others about them rather than ask for input </li></ul><ul><li>Rational introverts avoid emotional decisions but they are willing to take time to consider all possible courses of action </li></ul><ul><li>Rational extroverts tend to assert their ideas and not let gut feeling affect their decision making </li></ul>
    34. 34. INTUITIVE RATIONAL INTROVERT EXTROVERT INTUITIVE INTROVERT: Asks others Acknowledges feelings INTUITIVE EXTROVERT: Tells others Acknowledges feelings RATIONAL INTROVERT: Asks others Decides logically RATIONAL EXTROVERT: Tells others Decides logically
    35. 35. Team dynamics <ul><li>A commonly accepted model of how teams form and become productive is due to Tuckermann and Jensen (1965); this is a 4-stage model: </li></ul><ul><ul><li>forming : the initial stage when the individual groups try to determine the purpose of the group and what role they will play </li></ul></ul><ul><ul><li>storming : a conflict-filled stage in which the individuals try to form a group by resolving differences in goals and perspectives. The individuals struggle for status and power within the team </li></ul></ul><ul><ul><li>norming : having come to a common understanding of the goals and functioning of the team, the conflict disappears and members focus on the work at hand </li></ul></ul><ul><ul><li>performing : the team has developed a clear identity with loyal team members who have a clear understanding of how the team operates and how they will interact as individuals </li></ul></ul>
    36. 36. Two people 1 line of communication Three people Four people Five people 3 lines of communication 6 lines of communication 10 lines of communication n people n(n-1)/2 lines of communication
    37. 37. Optimal Size for Interaction (Approximate) Number of people with whom developer must frequently interact Developer communicates regularly with no one. No communication time lost, but developer is too isolated and has no help. Key: = engineer 3 Effectiveness per developer
    38. 38. Optimal Size for Interaction (Approximate) Number of people with whom developer must frequently interact Developer communicates regularly with eleven people. Communication time outweighs benefits of interaction Developer communicates regularly with no one. No communication time lost, but developer is too isolated and has no help. Key: = engineer Approximate optimal range 3 7 Effectiveness per developer
    39. 39. Peer Organizations for Larger Projects Team of leaders
    40. 40. 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>
    41. 41. 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>
    42. 42. 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>
    43. 43. 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>
    44. 44. 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>
    45. 45. 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 Control flow Information Flow Control Flow
    46. 46. Example of Hierarchical Organization: Chief Programmer Team Chief Programmer Librarian Administration Tester Junior Programmer Assistant Chief Programmer Senior Programmer
    47. 47. Another Project Organization: Egoless Programming Team (Weinberg) Analyst Designer Librarian Tester Programmer
    48. 48. 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
    49. 49. 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>
    50. 50. 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>
    51. 51. 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>
    52. 52. 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>
    53. 53. 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
    54. 54. Possible Mappings of To Dos 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 over-commitment </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>
    55. 55. 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>
    56. 56. 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>
    57. 57. 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>
    58. 58. 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)
    59. 59. 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>
    60. 60. 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>
    61. 61. 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>
    62. 62. 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>
    63. 63. 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>Date 9/9/96 Agenda Minutes Action Items Issues Agenda Minutes Action Items Issues 9/16/96 Agenda Minutes Action Items Issues
    64. 64. 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>
    65. 65. 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>
    66. 66. Summary <ul><li>In this lecture, we have looked at various aspects of project management, team organisation, and project management plans </li></ul><ul><li>We still need to consider the problems associated with risk, cost estimation of a project, project schedules </li></ul>