CS 5150 Software Engineering Lecture 6 Project Management
CS Administrivia Quizzes posted Feasibility study/plan due in a little over a week
CS Classic Project Management Example: OS 360 The OS for the IBM 360 was 2 years late Q: How does a project get 2 years behind schedule? A: One day at a time! Fred Brooks Jr, The Mythical Man Month
CS “The Mythical Man Month” Adding more people to work on a task helps up to a point, then becomes counter- productive Adding people adds coordination overhead Some activities work best in a single mind Some tasks cannot be accelerated beyond some limit In software, productivity varies A LOT between developers Some studies found that the most productive are 5x faster than the “just adequate”
CS The Goal of Project Management Give the team the best chance to finish a project on time on budget etc Provide visibility into how well things are going according to plan
CS The Central Tension in Project Management Clients (or managers, or whoever) want to know: What will the functionality be? When will it be available? What will it cost? Examples: For products, marketing needs to how to sell the software For embedded systems, other teams need to coordinate development
CS The Central Tension in Project Management BUT: Every software project is a special snowflake Time and cost estimates are notoriously inaccurate Almost always something changes about the specifications during development
CS Typical Project Planning Experience Some big projects (e.g. product releases) some smaller project (e.g. “phase 1” contracts) For smaller projects, just create rough time estimates and judge whether they’re reasonable For larger projects, detailed planning with labor estimates and task dependencies Still usually off by quite a bit Unanticipated tasks Unanticipated work on planned tasks Unanticipated schedule conflicts Unanticipated life conflicts
CS Conventional Software Project Management The scope of the project is defined early Development is divided into tasks and milestones Time and resource estimates are made Estimates are combined to create a schedule/plan Progress relative to the plan is monitored, perhaps weekly The plan is modified as inaccuracies in the estimates become evident
CS Agile Project Management Planning is divided into high level release forecasting and low level detail planning Release planning is a best guess of what can be achieved in a sequence of time-boxes (sprints) For each time-box, small teams do detailed planning Release plan is updated to reflect sprint results Clients and developers share ownership of the release plan and choice of sprints
CS Universal Aspects of Project Management Planning 5150: Rough plan for feasibility study More detailed plan for each milestone Progress tracking Regular comparison of plan and reality Update the plan! Occasional reassessment of project management processes
CS Generating Time Estimates Developers are usually pretty good at estimating times for tasks within their areas of expertise, but... Even so, little things get in the way The difference between “almost done” and “completely done” Unplanned technology churn There is always something that is a little bit different
CS Team-based Estimation Developers themselves usually produce the best estimates within a small time window Teams can commit to the outcome of a sprint Still useful to have a local schedule/plan Different teams work at dramatically different rates Reminder: 5150 is about 1 sprint’s worth of development time
CS Start-up Time Recruiting, tying up loose ends from previous projects Acquiring and setting up equipment Learning about new domains and frameworks Getting the ball rolling with clients/other collaborators Can be months for large projects
CS Methods for Task-Based Project Planning Critical path method, Gantt charts, etc Build a work plan from task data/estimates Display plan in graphical and tabular forms Software support Spreadsheets/databases for recording estimates and results Fancier software for calculating estimates and generating reports
CS Task-Based Project Planning Terminology Task/activity A part of a project that takes work/time Event The completion of a group of activities Dependency Constraints imposed on one activity by another Resource Staff time, equipment or other item required for a task
CS Task-Based Project Planning Terminology Deliverable Any work product that is provided to clients or users (software, documentation, etc) Milestone A set of tasks, usually associated with a target date
CS A Simple Gantt Chart (made with Microsoft Excel)
CS Gantt Charts Most useful for small projects or pieces of larger projects Horizontal axis is time Each row is a task: (planned) start time, portion complete, (projected) completion time Progress can be tracked by drawing a vertical line at the current date
CS A More Complex Gantt Chart (Made with SmartDraw)
CS Alternative Visualization: Activity Graph
CS Activity Graph Background PERT Program Evaluation and Review Technique introduced by the U.S. Navy in 1957 to support the development of its Polaris submarine missile program. PERT/Time Activity graph with three time estimates (shortest, most probable, longest) on each activity to compute schedules. PERT/Cost Added scheduling of resources (e.g., facilities, skilled people, etc.)
CS Critical Path Method Uses and activity graph with a single time estimate for each task A standard method for managing large construction projects On big projects, activity graphs with 10,000+ tasks are common
CS Step 1: Time Estimates
CS Step 2: Earliest Dates
CS Step 3: Latest Dates
CS Step 4: Slack
CS Step 5: Critical Path
CS Feedback One of the latest trends in project management: evidence-based scheduling Developers generate estimates for all their tasks and record the actual time taken A learning algorithm adapts to each developer’s estimation strengths and weaknesses over time