Project Management
Download as PPT, PDF0 likes689 views
The document discusses several key concepts in project management: 1) Projects often remain 90% complete for a long time as completion approaches, and things that can go wrong often do. 2) Software project management plans specify the technical and managerial approaches to develop software and include functions, tasks, activities, and a hierarchical structure. 3) Project structures can be hierarchical or project-based; project-based structures reduce bureaucracy but can be harder to manage.
Project Management
- 2. Laws of Project Management Projects progress quickly until they are 90% complete. Then they remain at 90% complete forever. 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. If project content is allowed to change freely, the rate of change will exceed the rate of progress. Project teams detest progress reporting because it manifests their lack of progress.
- 3. How it should go (e.g., waterfall model)
- 4. How it often goes
- 5. Software Project Management Plan Software Project: All technical and managerial activities required to deliver the deliverables to the client. A software project has a specific duration, consumes resources and produces work products . Management categories to complete a software project: Tasks, Activities, Functions Software Project Management Plan: The controlling document for a software project. Specifies the technical and managerial approaches to develop the software product.
- 6. Functions, Tasks, Activities Functions (also known as Umbrella activities) Project Management Configuration Management Documentation Quality Assurance (includes Verification and Validation) Traceability Training …
- 7. Tasks Smallest unit of management accountability Atomic unit of planning and tracking Finite duration, need resources, produce tangible result (documents, model, 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.
- 8. Examples of Tasks Unit test class “Foo” Test subsystem “Bla” Write user manual Write meeting minutes and post them …
- 9. 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 baseline: formally reviewed work product under change control (change requires formal procedures) Activities may be grouped into larger activities: Establishes hierarchical structure for project (phase, step, ...) Allows separation of concerns Precedence relations often exist among activities (PERT Chart)
- 10. Examples of Activities Major Activities: Develop Requirements model Develop Analysis Model Develop Architecture (aka System Design model) … Activities during requirements: Define scenarios Identify stakeholders Define Use Case model Design preliminary User Interface
- 11. Example of Hierchical Organization: Chief Programmer Team Chief Programmer Librarian Administration Tester Junior Programmer Assistant Chief Programmer Senior Programmer
- 12. Another Project Organization: Egoless Programming Team (Weinberg) Analyst Designer Librarian Tester Programmer
- 13. 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
- 14. Observations on Management Structures Hierarchical structures Do not work well with iterative and incremental software development process Manager is not necessarily always right Project-based structures Cut down on bureaucracy reduces development time Decisions are expected to be made at each level Hard to manage
- 15. Hierarchical Structure 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
- 16. Project-Based Structure 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
- 17. Your Project-Based Structure Get together in your group and discuss options for your team organization and structure Subteams for functions, activities, tasks? Team lead? Subteam leads or co-ordinators? Question: Discuss the advantages and disadvantages of these: For a team of 6 members 3 members are going to work on delivering the detailed design (they check their work before submitting it to the team) and correct problems 3 team members are assigned to independently review the detailed design and identify defects Or 6 members are going to work on delivering the detailed design (the whole team checks the work before it is posted for evaluation) .
- 18. Possible Mappings of ToDos to People One-to-One Ideal but often not worth to be called a project Many-to-Few Each project member assumes several roles ("hats") Danger of overcommittment Need for load balancing Many-to-"Too-Many" Some people don't have significant roles Bystanders Losing touch with project
- 19. Managerial Processes Management Objectives and Priorities Philosophy, goals and priorities Assumptions, Dependencies, Constraints External factors Risk Management Identifying, assessing, tracking, contingencies for risks Monitoring and Controlling Mechanisms Reporting mechanisms and formats, information flows, reviews Staffing Plan Needed skills (what?, how much?, when?)
- 20. Project Management Heuristics Make sure to be able to revise or dump a project plan Complex system development is a nonlinear activity If project goals are unclear and complex use team-based project management. In this case Avoid GANTT charts and PERT charts for projects with changing requirements Don’t look too far into the future Avoid micro management of details Don’t be surprise if current project management tools don’t work: They were designed for projects with clear goals and fixed organizational structures
Editor's Notes
- #3: 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
- #6: 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.
- #12: 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!!
- #14: 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
- #16: 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.