1. Chapter 11, Project Management

2. Outline Concepts and terminology
Purpose of Software Project Management Plans
Structure of a Project Management Plan
Project responsibilities
Team structures
Project planning
Work breakdown structure
Communication Management
Dependencies
Schedule
Project Management Tools

3. What is not covered in this lecture?
Reference:
Bruegge&Dutoit, Chapter 12
What is not covered in this lecture?
Communication Management, Meeting Management
Bruegge & Dutoit, Chapter 4
Cost estimation
Reference: Software engineering economics, Barry Boehm, Prentice Hall 1981

4. 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.
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

5. How it should go

6. How it often goes

7. 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.
Companion document to requirements analysis document: Changes in either may imply changes in the other document.
SPMP may be part of project agreement.
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.

8. Project Agreement Document written for a client that defines:
the scope, duration, cost and deliverables for the project.
the exact items, quantities, delivery dates, delivery location.
Can be a contract, a statement of work, a business plan, or a project charter.
Client: Individual or organization that specifies the requirements and accepts the project deliverables.
Deliverables (= Work Products that will be delivered to the client):
Documents
Demonstrations of function
Demonstration of nonfunctional requirements
Demonstrations of subsystems

9. Project Agreement vs Problem Statement

10. 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

11. Installation
Steady state
Termination
Client acceptance test
Postmortem
Project agreement
Project replanning
Status monitoring
Risk management
Project kickoff

12. 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

13. Functions
Activity or set of activities that span the duration of the project
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. Functions
Examples:
Project management
Configuration Management
Documentation
Quality Control (Verification and validation)
Training
Question: Is system integration a project function?
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

15. Tasks • Smallest unit of work subject to management
p:Project
f1:Function
f2:Function
a1:Activity
a2:Activity
a2.1:Activity
a2.2:Activity
t1:Task
t2:Task
t3:Task
• Smallest unit of work subject to management
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)
• Small enough for adequate planning and tracking
• Large enough to avoid micro management

16. Tasks Smallest unit of management accountability
Atomic unit of planning and tracking
Finite duration, need resources, produce tangible result (documents, 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.

17. Task Sizes Finding the appropriate task size is problematic
Todo lists from previous projects
During initial planning a task is necessarily large
You may not know how to decompose the problem into tasks at first
Each software development activity identifies more tasks and modifies existing ones
Tasks must be decomposed into sizes that allow monitoring
Work package usually corresponds to well defined work assignment for one worker for a week or a month.
Depends on nature of work and how well task is understood.

18. Examples of Tasks Unit test class “Foo” Test subsystem “Bla”
Write user manual
Write meeting minutes and post them
Write a memo on NT vs Unix
Schedule the code review
Develop the project plan
Related tasks are grouped into hierarchical sets of functions and activities.
Action item

19. Action Item
Definition: A task assigned to a person that has to be done within a week or less
Action items
Appear on the agenda in the Status Section (See lecture on communication)
Cover: What?, Who?, When?
Example of action items:
Florian unit tests class “Foo” by next week
Marcus develops a project plan before the next meeting
Bob posts the next agenda for the Simulation team meeting before Sep 10, 12noon.
The VIP team develops the project plan by Sep 18

20. • Culminates in project milestone.
Activities
f1:Function
p:Project
f2:Function
a1:Activity
a2:Activity
• Major unit of work
with precise dates
a2.1:Activity
a2.2:Activity
• Consists of smaller
activities or tasks
t1:Task
t2:Task
t3:Task
• Culminates in project
milestone.

21. 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)

22. Examples of Activities
Major Activities:
Planning
Requirements Elicitation
Requirements Analysis
System Design
Object Design
Implementation
System Testing
Delivery
Activities during requirements analysis:
Refine scenarios
Define Use Case model
Define object model
Define dynamic model
Design User Interface

23. Structure of a Software Project Management Plan
Front Matter
1. Introduction
2. Project Organization
3. Managerial Process
4. Technical Process
5. Work Elements, Schedule, Budget
Optional Inclusions

24. SPMP Part 0: Front Matter
Title Page
Revision sheet (update history)
Preface: Scope and purpose
Tables of contents, figures, tables

25. SPMP Part 1: Introduction
1.1 Project Overview
Executive summary: description of project, product summary
1.2 Project Deliverables
All items to be delivered, including delivery dates and location
1.3 Evolution of the SPMP
Plans for anticipated and unanticipated change
1.4 Reference Materials
Complete list of materials referenced in SPMP
1.5 Definitions and Acronyms

26. SPMP Part 2: Project Organization
2.1 Process Model
Relationships among project elements
2.2 Organizational Structure
Internal management, organization chart
2.3 Organizational Interfaces
Relations with other entities
2.4 Project Responsibilities
Major functions and activities; nature of each; who’s in charge

27. Process Model Shows relationships among Visualization of process model
Functions, activities, tasks
Milestones
Baselines
Reviews
Work breakdown structure
Project deliverables
Sign-offs
Visualization of process model
Project Management Aids
MS Project (Microsoft)
MAC Project (Claris)
EasyTrak (Planning Control International)

28. Example of an Organization Chart
Client
Management
Consultants
Cross-functional Teams
Development Teams
Architecture
Logbook
HCI
Maintenance
Web Master
Documentation
Vehicle
Configuration Mgt
Travel
VIP
Infrastructure Team

29. Project Roles Planner Analyst Designer Programmer Tester Maintainer
Trainer
Document Editor
Web Master
Configuration Manager
Group leader
Liaison
Minute Taker
Project Manager

30. Project Roles Management roles Development roles
Organization and execution of the project within constraints. Examples: project manager, team leader.
Development roles
Specification, design and construction of subsystems. Examples: Analyst, system architect, implementor.
Cross functional roles
Coordination of more than one team. Example: API Engineer, configuration manager, tester
Consultant roles
Support in areas where the project participants lack expertise. Examples: End user, client, application domain specialist ( problem domain), technical consultant (solution domain).
Promoter roles
Promote change through an organization.

31. Promoter Roles
Promoters are self appointed individuals who identify themselves with the outcome of the project.
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.
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.

32. Power Promoter Also called executive champion
Pushes the change through the existing organizational hierarchy.
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.
Tasks:
constantly identify difficulties, resolve issues, and communicate with the project members, especially with the developers.
Example at project level: Project Manager.
Example at corporate level: Chief Executive Officer (CEO).

33. Knowledge Promoter Also called the technologist,
Promotes change arising in the application domain or the solution domain. Usually associated with the power promoter.
Tasks: Acquire information iteratively, understand the benefits and limitations of new technologies, and argue its adoption with the other developers.
Example at project level: System architect.
Reports to project manager
Does not have any direct subordinate in the reporting hierarchy
Has final say over all technical decisions in the system.
Example at corporate level: Chief Technical Officer (CTO).

34. Process Promoter
The process promoter has intimate knowledge of the projects processes and procedures.
The process promoter is in constant interaction with the power promoter to get consensus on the overall goals.
Tasks: Bridge between the power and knowledge promoters, who often do not speak or understand the same language.
Example at project level: Development lead. Responsible for the administrative aspects of a project, including planning, milestones definition, budgeting and communication infrastructure.
Example at corporate level: Chief Information Officer (CIO

35. Project Management: Hierarchical Project Organization
Information Flow
Control Flow
Chief Executive
First Level Manager
(“Front-Line Manager”)
Project Members A B
A wants to talk to B: Complicated Information Flow
A wants to make sure B does a certain change: Complicated Controlflow
Basis of organization:
Complicated information and control flow
across hierarchical boundaries

36. Example of Hierchical Organization: Chief Programmer Team
Assistant
Chief Programmer
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!!
Senior Programmer
Librarian
Administration
Tester
Junior Programmer

37. Another Project Organization: Egoless Programming Team (Weinberg)
Analyst
Tester
Programmer
Designer
Librarian

38. Project-Based Project Organization
Leader
Coaches
Subsystem Team
Subsystem Team
Subsystem Team
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 A B
Team
Members
A wants to talk to B: Communication Flow
A wants to make sure B does a certain change: Decision Flow
Basis of organization:
Nonlinear information flow across dynamically formed units

39. Associations in organizational structures
Reporting association:
Used for reporting status information
Decision association
Used for propagating decisions
Communication association
Used for exchanging information needed for decisions (e.g., requirements, design models, issues).

40. Observations on Management Structures
Hierarchical structures
“Reports”, “Decides” and “Communicates-With” all mapped on the same association
Do not work well with iterative and incremental software development process
Manager is not necessarily always right
Project-based structures
“Reports”, “Decides” and “Communicates-With”are different associations
Cut down on bureaucracy reduces development time
Decisions are expected to be made at each level
Hard to manage

41. 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
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.

42. 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

43. Assigning Responsibilities To People
Team A
“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
Person A
Role 1
Role 2
Item 4
Item 5
Item 7
Role 2
Person B
Role 3
Item 3
Item 6
Item 8
Role 3

44. 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
Loosing touch with project

45. Team Formation Top level Design
“Rough” Subsystem Decomposition (before requirements analysis)
Done during Predevelopment phase
Team Formation done after Top Level Design
Heuristics:
One team for each subsystem
One cross-functional task per team
5-7 members per team
Be prepared to iterate the team formation after system design when the subsystem decomposition is baselined

46. Project Roles: Coach Listen to gripes from individual teams
Review weekly team reports
Attend weekly project meetings
Schedule and prepare meetings with client
Insist that guidelines are followed
Assign presentations (in-class project meetings, client review, client acceptance test)
Resolve conflicts if they cannot be resolved otherwise

47. Project Role: Group leader
Responsible for intra-group communication (Meeting Management: Primary Facilitator)
Run the weekly project meeting
Post agenda before meeting
Define and keep track of action items (who, what, when)
Measure progress (Enforce milestones)
Deliver work packages for the tasks to the project management
Present problems and status of team to project manager
The group leader has to be rotated among members of the team.
Role switching: Used to work well for smaller groups. We still encourage switching of group leaders, but now for smaller times

48. Group Leader: Create an Agenda
Purpose of Meeting
Desired Outcome
Information Sharing
Information Processing
Meeting Critique
Action Items
(Check Previous
Meeting)
Issues
(Check Previous
Meeting & BBoards)

49. Project Role: Liaison Responsible for inter-group communication
Make available public definitions of subsystem developed by the team to the architecture teams (ensure consistency, etc)
Coordinate tasks spanning more than one group with other teams
Responsible for team negotiations
Examples: API Engineer, Configuration manager

50. Project Role: Planner
Plans and tracks the activities of an individual team and has the following responsibilities.
Define project plan for team:
PERT chart, resource table and GANTT chart showing work packages
Enter project plan into project management tool
Make project plan available to management
Report team status to project manager No explicit planner in PAID. Responsibilities assumed by coaches

51. Project Role: Document Editor
Collect, proofread and distribute team documentation
Submit team documentation to architecture team
Collect agendas
Take minutes at meetings

52. Web Master Maintain team home page Keep track of meeting history
Keep track of design rationale

53. Web Master: Publish Meeting Information on Team Homepage
Must contain Agenda, minutes, action items and issues
Possibilities:
One HTML document per meeting, with anchors (maintained by one role)
Separate HTML documents for Agenda, Minutes, etc (maintained by several roles)
/homePagesTeams/UserInterface/www/index.htm
Date
9/9/96
Agenda
Minutes
Action Items
Issues
9/16/96

54. SPMP Part 3: Managerial Processes
3.1 Management Objectives and Priorities
Philosophy, goals and priorities
3.2 Assumptions, Dependencies, Constraints
External factors
3.3 Risk Management
Identifying, assessing, tracking, contingencies for risks
3.4 Monitoring and Controlling Mechanisms
Reporting mechanisms and formats, information flows, reviews
3.5 Staffing Plan
Needed skills (what?, how much?, when?)

55. Examples of Assumptions
There are enough cycles on the development machines
Security will not be addressed
There are no bugs in Together-J, the CASE Tool recommended for the project
A demonstration of the Starnetwork system will be given by the client

56. Examples of Dependencies
The database team depends on the EPC database provided by DaimlerChrysler
The automatic code generation facility in the CASE tool depends on JDK. The current release of Together-J supports only JDK 1.1.6

57. Examples of Constraints
The length of the project is 3 months. limited amount of time to build the system
The project consists of beginners. It will take time to learn how to use the tools
Not every project member is always up-to-date with respect to the project status
The use of UML and a CASE tool is required
Any new code must be written in Java
The system must use Java JDK 1.1.6

58. Risk Management Risk: Members in key roles drop the course.
Contingency: Roles are assigned to somebody else. Functionality of the system is renegotiated with the client.
Risk: The project is falling behind schedule.
Contingency: Extra project meetings are scheduled.
Risk: One subsystem does not provide the functionality needed by another subsystem.
Contingency: ?
Risk: Ibutton runs only under JDK 1.2
Contingency: ?
Contingency when subsystems do not function properly? The liaisons of both teams get together to solve this problem
Contigency when database takes too much time: The Database group defines a wrapper to be used by the other groups for limited form of data access while the search goes on.
Contingency when client is not available. Use bboards, make decisions after keeping a record that client is not answering.

59. SPMP Part 4: Technical Process
4.1 Methods, Tools and Techniques
Computing system, development method, team structure, etc.
Standards, guidelines, policies.
4.2 Software Documentation
Documentation plan, including milestones, reviews and baselines.
4.3 Project Support Functions
Plans for functions (quality assurance, configuration management).

60. SPMP Part 5: Work Elements
5.1 Work Packages (Work breakdown structure)
Project decomposed into tasks; definitions of tasks
5.2 Dependencies
Precedence relations among functions, activities and tasks
5.3 Resource Requirements
Estimates for resources such as personnel, computer time, special hardware, support software.
5.4 Budget and Resource Allocation
Connect costs to functions, activities and tasks.
5.5 Schedule
Deadlines, accounting for dependencies, required milestones
Each work package has to be uniquely defined. Identification may be based on a numbering scheme and/or descriptive titles. A diagram depicting the workbreak down structure into activities, subactivities and tasks my be used to depict hierarchical relationships among work packages.
A work product is any tangible item that results from a project function, activity or task. Sometimes we call a work product also artifact.
Deliverables are those work products that are to be delivered to the customer. The quantities, delivery dates and delivery locations are specified in the project agreement.

61. Creating Work Packages
Work Breakdown Structure (WBS) (Section 5.1)
Break up project into activities (phases, steps) and tasks.
The work breakdown structure does not show the interdependence of the tasks
The identification of the work breakdown structure is an instance of object identification and associating these objects
Let's cover in a little bit more detail the work elements
First we begin by working to understand what the customer and users want. We list all the items that the customer expects to see during the development of the project. These items are called deliverables and can included anything the customer wants demonstrated or delivered as part of the project agreement.
Note that the Workbreakdown structure is very much like a to-do list. It is useful to use a word processor that allows an outline feature, or a project management tool to start with a to-do list. Listing all the to-dos and ordering them into a hierarchical relationship (Task A consists of the subtasks A1, A2, ...) is the first activity of producing a project plan.
The next step in the formulation of a project plan is to identify any dependencies between activities, tasks or functions. Note that dependency is another relation different from the “consists of” relation. Dependency is a relation between two tasks, activities or functions that denotes “must be preceded by”. If task A depends on another task B , in general it means that task B has to precede task A, otherwise task A cannot start or cannot get done.

62. WBS Trade-offs Work breakdown structure influences cost and schedule
Thresholds for establishing WBS in terms of percentage of total effort:
Small project (7 person-month): at least 7% or 0.5 PM
Medium project (300 person-month): at least 1% or 3 PMs
Large project (7000 person-month): at least 0.2 % or 15 PMs
Determination of work breakdown structure is incremental and iterative

63. Dependencies and Schedule (SPMP Section 5.2 + 5.5)
An important temporal relation: “must be preceded by”
Dependency graphs show dependencies of the tasks (hierarchical and temporal)
Activity Graph:
Nodes of the graph are the project milestones
Lines linking the nodes represent the tasks involved
Schedule Chart (MS-Project):
Nodes are tasks and milestones
Lines represent temporal dependencies
Estimate the duration of each task
Label dependency graph with the estimates

64. Project Management Tools for Work Packages
Visualization Aids for Project Presentation
Graphs (Schedule), Trees (WBS)
Tables (Resources)
Task Timeline
Gantt Charts: Shows project activities and tasks in parallel. Enables the project manager to understand which tasks can be performed concurrently.
Schedule Chart (PERT Chart)
Cornerstone in many project management tools
Graphically shows dependencies of tasks and milestones
PERT: Program Evaluation and Review Technique
A PERT chart assumes normal distribution of tasks durations
Useful for Critical Path Analysis
CPM: Critical Path Method
“Measure” for the complexity of the project

65. Project: Building a House
Activity 1: Landscaping the lot
Task 1.1: Clearing and grubbing
Task 1.2: Seeding the Turf
Task 1.3: Planting shrubs and trees
Activity 2: Building the House
Activity 2.1 : Site preparation
Activity 2.2: Building the exterior
Activity 2.3: Finishing the interior
Task 2.1.1: Surveying
Task 2.1.2: Obtaining permits
Task 2.1.3: Excavating
Task 2.1.4: Obtaining materials
Let us take a look at an example of how to construct a project plan. We will be using a simple problem, namely building a house. If the lot has never been landscaped, then we can immediately identify two activities: Landscaping and Building the house. Note that even though I call them activities, initially I might not know how difficult or how long these tasks are and I could start with them as tasks. However, if I immediately know subtasks for these activities, I must call them activities. We view the Landscaping activity as an aggregration of three tasks: Clearing and grubbing, seeding and planting shrubs. Each of these activities can be defined as a work package in the sense of the IEEE standard: We can define the product (or deliverable): A clean lawn, the staffing requirements (landscaping company), the resources to be used (lawnmower, shovel) and the acceptance criteria for the work product (lot must be leveled), and the responsible person (group leader).

66. Activity 2: Building a House, ctd
Activity 2.2: Building the exterior
Task 2.2.1: Foundation
Task 2.2.2: Outside Walls
Task 2.2.3: Exterior plumbing
Task 2.2.4: Exterior electrical work
Task 2.2.5: Exterior siding
Task 2.2.6: Exterior painting
Task 2.2.7: Doors and Fixtures
Task 2.2.8: Roof
Activity 2.3 : Finishing the Interior
Task 2.3.1: Interior plumbing
Task 2.3.2: Interior electrical work
Task 2.3.3: Wallboard
Task 2.3.4: Interior painting
Task 2.3.5: Floor covering
Task 2.3.6: Doors and fixtures
Any task or activity can be described with a set of parameters:
The precursor (set of tasks to started/finished before this task can start)
The duration (Length of time it will take to finish the task)
The due date (for example due to a contractual deadline)
The endpoint (usually a milestone)

67. Activity Graph for Activity “Building a House”
Note the possible parallelism in the activity graph: The Exterior and Interior work can be done in parallel. However, none of these activities can be started before the Outside Wall is complete. Finishing the outside wall in time therefore is an important task.

68. PERT Chart Example for "Building a House"
Start Time
Slack Time
MS Project PERTcy
Chart with Duration of
Activities (Pfleeger 2.3)
Duration
Building a House:
START
8/27/94
Request
Permits 15
Survey
ing 3 12
Excava
tion
9/17/94 10
Legend
8/29/94
Buy
Material
10/1/94
Lay
Founda
10/15/94
Build
Outside
Wall
11/5/94 20
Install
Exterior
Plumbing
12/3/94
Interior
Electrical
12/17/94
12/21/94
Siding
12/31/94 8
Wallboard
1/11/95 9
Paint
1/12/95 5
Roofing
1/19/95
Flooring
1/22/95 18 11
Doors
2/8/95 7 6
FINISH
2/16/95
This is another view of the project plan for building a house. Instead of an activity chart we are using a PERT chart. PERT charting comes from a technique called Program Evaluation and Review Technique, a popular technique for determining critical paths in a project.
A critical path is the minimal amount of time it will take to complete a project, given estimates for the duration of each of the tasks. In addition, the critical path method reveals those tasks or activities that are most critical to completion.
To determine the critical path in a project we have to learn the notion of slack time. For each node in our graph we comput two times: Real (Estimated) time and available time. The estimated time of a task is the time estimated for its completion. The available time is the amount of time available according to the overall schedule. Slack time is the difference between available and estimated (real) time for a task:

69. Slack Time and Critical Path
Available Time - Estimated (“Real”) Time for a task or activity
Or: Latest Start Time - Earliest Start Time
Critical Path
The path in a project plan for which the slack time at each task is zero.
The critical path has no margin for error when performing the tasks (activities) along its route.
Slack time is a measure of how much we can goof off without causing major troubles for the project. If a task has no slack time, it means it has to be done immediately at the indicated start time.
For example, surveying can start on day 1, so its earliest start time is day 1. However, because it takes 15 days to request and receive permits, surveying can begin as late as day 13 and still not hold up the project schedule.

70. How do you become a good project planner?
Establish a project plan
Start with the plan based on your experience with the last project(s)
Keep track of activities and their duration
Determine difference between planned and actual performance
Make sure to do a post-mortem
Lessons learned
Ask developers for feedback
Write a document about what could have been improved

71. Writing the SPMP Example full SPMPs OWL project JAMES project
JAMES project

72. 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

73. Project Management Summary
Get agreement among customers, managers and teams
Problem statement
Software project management plan
Project agreement
Make sure agreement allows for iteration
Organization Structures
SPMP
Project planning
Start with work breakdown structure (WBS)
Identify dependencies and structure: Tasks, activities, functions
Tools and Techniques
GANTT, Dependency graph, Schedule, Critical Path Analysis
Be careful with tools in projects with a lot of change