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.
How it should go (e.g., waterfall model)
How it often goes
Software Project Management Plan
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.
Functions, Tasks, Activities
Functions (also known as Umbrella activities)
Quality Assurance (includes Verification and Validation)
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
Includes the acceptance criteria for the work products (deliverables) produced by the task.
Examples of Tasks
Unit test class “Foo”
Test subsystem “Bla”
Write user manual
Write meeting minutes and post them
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)
Examples of Activities
Develop Requirements model
Develop Analysis Model
Develop Architecture (aka System Design model)
Activities during requirements:
Define Use Case model
Design preliminary User Interface
Example of Hierchical Organization: Chief Programmer Team Chief Programmer Librarian Administration Tester Junior Programmer Assistant Chief Programmer Senior Programmer
Another Project Organization: Egoless Programming Team (Weinberg) Analyst Designer Librarian Tester Programmer
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
Observations on Management Structures
Do not work well with iterative and incremental software development process
Manager is not necessarily always right
Cut down on bureaucracy reduces development time
Decisions are expected to be made at each level
Hard to manage
Projects with high degree of certainty, stability, uniformity and repetition.
Requires little communication
Role definitions are clear
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
Project with degree of uncertainty
Open communication needed among members
Roles are defined on project basis
Requirements change during development
New technology develops during project
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
6 members are going to work on delivering the detailed design (the whole team checks the work before it is posted for evaluation) .
Possible Mappings of ToDos to People
Ideal but often not worth to be called a project
Each project member assumes several roles ("hats")
Danger of overcommittment
Need for load balancing
Some people don't have significant roles
Losing touch with project
Management Objectives and Priorities
Philosophy, goals and priorities
Assumptions, Dependencies, Constraints
Identifying, assessing, tracking, contingencies for risks
Monitoring and Controlling Mechanisms
Reporting mechanisms and formats, information flows, reviews
Needed skills (what?, how much?, when?)
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