3CS 5150
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
4CS 5150
“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”
5CS 5150
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
6CS 5150
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
7CS 5150
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
8CS 5150
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
9CS 5150
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
10
CS 5150
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
11
CS 5150
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
12
CS 5150
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
13
CS 5150
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
14
CS 5150
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
15
CS 5150
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
16
CS 5150
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
17
CS 5150
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
19
CS 5150
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
22
CS 5150
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.)
23
CS 5150
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
Recommended