Project management

v 8 September 1994

TUM

Lecture Notes on
Project Management

Bernd Bruegge
Technische Universität München
Lehrstuhl für Angewandte Softwaretechnik

14 July 1998

Bernd Bruegge Component-Based Software Engineering 12

Odds and Ends I

v Book on CBSE Homepage
w See Post by Allen Duoit on July 13
u Chapter 1, Introduction
u Chapter 3, Software Lifecycle
u Chapter 5, Project Communication
u Chapter 6, Requirements Elicitation
u Chapter 7, Requirements Analysis
u Chapter 9, Design Rationale
w Chapters available on August 15:
u Chapter 8 System Design
u Chapter 4 Project Management


Odds and Ends II

v Lecture Today:
w Finish System Design
w Project Management (No reading available yet)
v Lecture on Wednesday:
w Communication & Meeting Management
u Reading: Bruegge-Dutoit Ch 5
v Lecture next Tuesday:
w Software Lifecycle
u Reading: Bruegge-Dutoit Ch 3


Outline of Lecture

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


Laws of Project Management
v Projects progress quickly until they are 90%
complete. Then they remain at 90% complete forever.

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

v If project content is allowed to change freely, the rate
of change will exceed the rate of progress.

v Project teams detest progress reporting because it
manifests their lack of progress.


How it should go

Requirements
Analysis

Design

Implementation

System Testing

Delivery and Installation


How it often goes

Requirements
Analysis

D
E
L
A
Y
Vaporware


Software Project Management Plan
v Software Project:
w All technical and managerial activities required to
deliver the deliverables to the client.
w A software project has a specific duration, consumes
resources and produces work products.
w Management categories to complete a software project:
u Tasks, Activities, Functions

v Software Project Management Plan:
w The controlling document for a software project.
w Specifies the technical and managerial approaches to
develop the software product.
w Companion document to requirements analysis
document: Changes in either may imply changes in the
other document.
w SPMP may be part of project agreement.

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


Project Agreement vs Problem Statement

Client Manager Project Team
(Sponsor)

Problem
Statement Software Project
Management Plan
Project
Agreement


Project: Functions, Activities and Tasks

Function
Project
Function

Activity Activity Activity


Task Task Task Task


Functions
v Activity or set of activities that span the duration of the
project

Function
Project
Function



Task Task Task Task


Functions

v Examples:
w Project management
w Configuration Management
w Documentation
w Quality Control (Verification and validation)
w Training

v Question: Is system integration a project function?

v 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


Tasks
Function
Project
Function

• Smallest unit
Activity Activity Activity of work subject
to management
• Small enough for
adequate planning
Task Task Task Task
and tracking
• Large enough
to avoid micro
management

Tasks
v Smallest unit of management accountability
w Atomic unit of planning and tracking
w Finite duration, need resources, produce tangible result
(documents, code)
v Specification of a task: Work package
w Name, description of work to be done
w Preconditions for starting, duration, required resources
w Work product to be produced, acceptance criteria for it
w Risk involved
v Completion criteria
w Includes the acceptance criteria for the work products
(deliverables) produced by the task.


Task Sizes

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


Examples of Tasks

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


Action Item

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


Activities

Function
Project
Function

Activity Activity Activity • Major unit of work
with precise dates
• Consists of smaller
activities or tasks
Task Task Task Task
• Culminates in project
milestone.

Activities

v Major unit of work v Activitites may be
v Culminates in major grouped into larger
project milestone: activities:
w Internal checkpoint should w Establishes hierarchical
not be externally visible structure for project
(phase, step, ...)
w Scheduled event used to
measure progress w Allows separation of
concerns
v Milestone often produces w Precedence relations often
baseline: exist among activities
w formally reviewed work (PERT Chart)
product
w under change control (change
requires formal procedures)


Examples of Activities

v Major Activities: v Activities during
w Planning requirements analysis:
w Requirements w Refine scenarios
Analysis w Define Use Case
w System Design model
w Object Design w Define object model
w Implementation w Define dynamic
model
w System Testing
w Design User Interface
w Delivery


Structure of a Software Project Management Plan

v 0. Front Matter
v 1. Introduction
v 2. Project Organization
v 3. Managerial Process
v 4. Technical Process
v 5. Work Elements, Schedule, Budget
v Optional Inclusions


SPMP Part 0: Front Matter

v TitlePage
v Revision sheet (update history)
v Preface: Scope and purpose
v Tables of contents, figures, tables


SPMP Part 1: Introduction

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

SPMP Part 2: Project Organization

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


Process Model

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


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


Clients, Managers and Consultants

Management
Malcolm Bauer
Bernd Bruegge
Allen Dutoit
Brian Cavalier
Sam Perman Consultants
Isabel Torres-Yebra Klaus Eitzenberger
Client Alfonso Guerrero- Galan Manfred Mueller
Dieter Hege Juergen Bortolazzi,
Brigitte Pihulak Claus Czymmek

Infrastructure Team
Stephan Schoenig (CMU)
Joyce Johnstone (CMU)
Andreas Doerner (DB)
Arno Schmackpfeffer (DB)


Development and Cross-functional Teams
Logbook Team Maintenance Vehicle Team Travel Team
Aaron Wald Team Andrew Wang Ann Sluzhevsky
Arjun Cholkar Hoda Bin Zhou
Herbert Stiel
Aveek Datta Moustapha Christopher
Michael Poole Darren Mauro Jaewoo You Chiappa
MichaelScheinholtz Joel Slovacek Ognjen Gordon Cheng
Steve Sprang Martinovic John Doe
Nathaniel Woods
Vincent Mak Paul Stadler Kalyana Prattipati
Pradip Hari Yenni Kwek Tze Bin Loh Michael Samuel
Uhyon Chung William Ferry

VIP Team HCI Team Web Master Team Configuration
Darren Mauro Mgt Team
Christopher
Lumb Gordon Cheng Uhyon Chang Michael Poole
Eric Farng Idan Waisman (Logbook) (Logbook)
Idan Waisman Paul Stadler Darren Mauro
Steve Sprang Aveek Datta
Li-Lun Cheng (Maintenance) (Maintenance)
Patrick Toole Tze Bin Loh
Yenni Kwek Tze Bin Loh William Ferry
Phillip Ezolt (Simulation)
Venkatesh (Simulation)
Natarajan Kalyana Prattipati Chris Chiappa
(Travel) (Travel)
Eric Farng (VIP)

Project Responsibilities

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


Project Management: Hierarchical Project
Organization

Chief Executive

Team Leaders

Project Members

Basis of organization:
Hierarchical information flow across corporate boundaries


Example of Hierchical Organization:
Chief Programmer Team

Chief Programmer

Assistant
Chief Programmer

Senior Programmer Librarian Administration Tester

Junior Programmer


Another Project Organization:
Egoless Programming Team(Weinberg)

Analyst

Tester Programmer

Designer Librarian


Project-Based Project Organization

Project
Leader

Team
Leaders
Subsystem Team Subsystem Team Subsystem Team

Team
Members

Basis of organization:
Nonlinear information flow across dynamically formed units

Observations on Management Structures
v Egoless structures don't work well
w "Ownership" is important

v Hierarchical information flow does not work
well with iterative and incremental software
development process
w Manager is not necessarily always right

v Project-based structures
w Cut down on bureaucracy reduces development time
w Decisions are expected to be made at each level
w Hard to manage


Hierarchical Structure

v Projects with high degree of certainty,
stability, uniformity and repetition.
wRequires little communication
wRole definitions are clear
v When?
wThe more people on the project, the more
need for a formal structure
wCustomer might insist that the test team be
independent from the design team
wProject manager insists on a previously
successful structure

Project-Based Structure

v Project with degree of uncertainty
wOpen communication needed among
members
wRoles are defined on project basis
v When?
wRequirements change during development
wNew technology develops during project


Assigning Responsibilities To People

Project To Do List
Role 1
Person A
• Item 1 Item 1
• Item 2 Item 2
Item 9 Role 1
• Item 3
• Item 4 Role 2 Role 2
Item 4
• Item 5
Item 5
• Item 6 Item 7
Person B
• Item 7
• Item 8
Role 3
• Item 9
Item 3 Role 3
Item 6
Item 8


Possible Mappings of ToDos to People

v One-to-One
w Ideal but often not worth to be called a project
v Many-to-Few
w Each project member assumes several roles ("hats")
w Danger of overcommittment
w Need for load balancing
v Many-to-"Too-Many"
w Some people don't have significant roles
w Bystanders
w Loosing touch with project


Project Roles: Coach

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


Project Role: Group leader

v Responsible for intra-group communication
(Meeting Management: Primary Facilitator)
w Run the weekly project meeting
w Post agenda before meeting
w Define and keep track of action items (who, what,
when)
w Measure progress (Enforce milestones)
w Deliver work packages for the tasks to the project
management
w Present problems and status of team to project manager
v The group leader has to be rotated among members
of the team.

Group Leader: Create an Agenda
v Purpose of Meeting
v Desired Outcome
v Information Sharing
v Information Processing
v Meeting Critique

Action Items
(Check Previous
Meeting)

Issues
(Check Previous
Meeting & BBoards)


Project Role: Group Liason (Architecture, HCI)

v Responsible for inter-group communication
w Make available public definitions of subsystem
developed by the team to the architecture teams
(ensure consistency, etc)
w Coordinate tasks spanning more than one group
with other teams

v Responsible for team negotiations


Project Role: Planner
v Plans the activities of an individual team and has
the following responsibilities.
v Define project plan for team:
w PERT chart, resource table and GANTT chart showing
work packages
w Enter project plan into MS Project
v Make project plan available to management
v Report group project status to group leader

No explicit planner in JAMES. Responsibilities
assumed by group leaders


Project Role: Document Editor

v Collect,proofread and distribute team
documentation
v Submit team documentation to Architecture
team
v Collect agendas
v Take Minutes at meetings


Web Master

v Maintain team home page
v Keep track of meeting history
v Keep track of design rationale


Web Master:
v Publish Meeting Information on Team Homepage
w Must contain Agenda, minutes, action items and
issues
w Possibilities:
u One HTML document per meeting, with anchors
(maintained by one role)
u Separate HTML documents for Agenda, Minutes, etc
(maintained by several roles)
Date Agenda Minutes Action Items Issues

9/9/96 Agenda Minutes Action Items Issues

9/16/96 Agenda Minutes Action Items Issues


SPMP Part 3: Managerial Processes

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


Examples of Assumptions
v There are enough cycles on the development machines
v Security will not be addressed
v There are no bugs in the CASE Tool recommended for
the project
v A demonstration of the X system will be given by the
client
v The CAD Model of the seat will be made available by the
client


Examples of Dependencies

v The VIP team depends on the vehicle subsystem
provided by the vehicle team

v The automatice code generation facility in the CASE tool
Rose/Java depends on JDK. The current release of
Rose/Java supports only JDK 1.0.2


Examples of Constraints

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


Risk Management

v Risk: Members in key v Risk: One subsystem
roles drop the course. does not provide the
w Contingency: Roles are functionality needed by
assigned to somebody else. another subsystem.
Functionality of the system w Contingency: ?
is renegotiated with the
client.
v Risk: Rose will not
v Risk: The project is support JDK 1.1
falling behind schedule. w Contingency: ?
w Contingency: Extra project
meetings are scheduled.


SPMP Part 4: Technical Process

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


SPMP Part 5: Work Elements

v 5.1 Work Packages (Work breakdown structure)
w Project decomposed into tasks; definitions of tasks
v 5.2 Dependencies
w Precedence relations among functions, activities and tasks
v 5.3 Resource Requirements
w Estimates for resources such as personnel, computer time,
special hardware, support software.
v 5.4 Budget and Resource Allocation
w Connect costs to functions, activities and tasks.
v 5.5 Schedule
w Deadlines, accounting for dependencies, required milestones


Creating Work Packages
v Work Breakdown Structure (WBS) (Section 5.1)
w Break up project into activities (phases, steps) and tasks.
w The work breakdown structure does not show the interdependence
of the tasks

v WBS identification is an instance of object identification


WBS Trade-offs

v Work breakdown structure influences cost and schedule
v Thresholds for establishing WBS in terms of percentage
of total effort:
w Small project (7 person-month): at least 7% or 0.5 PM
w Medium project (300 person-month): at least 1% or 3 PMs
w Large project (7000 person-month): at least 0.2 % or 15 PMs
v Determination of work breakdown structure is
incremental and iterative
Source: Software Engineering
WBS Schedule Economics, Barry W. Boehm
p. 47, Prentice Hall, N.J., 1981

Cost
(Time, $$)


Dependencies and Schedule (Section 5.2 + 5.5)

v An important temporal relation: “must be preceded by”
v Dependency graphs show dependencies of the tasks
(hiercharchical and temporal)
w Activity Graph:
u Nodes of the graph are the project milestones
u Lines linking the nodes represent the tasks involved
w Schedule Chart (MS-Project):
u Nodes are tasks and milestones
u Lines represent temporal dependencies
v Estimate the duration of each task
v Label dependency graph with the estimates


Project Management Tools for Work Packages

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


GANTT Chart Example for OWL Project

8/9/96 9/6/96 10/4/96 11/1/96 11/29/96 12/27/96

Start

Planning Phase

Requirements
Analysis Phase
System Design Phase

Analysis Review

Object Design

Project Review

Implementation & Unit Testing

Object Design Review

System Integration

Internal Project Review

Client Acceptance


Project: Building a House

v Activity 1: Landscaping the lot
w Task 1.1: Clearing and grubbing
w Task 1.2: Seeding the Turf
w Task 1.3: Planting shrubs and trees
v Activity 2: Building the House
w Activity 2.1 : Site preparation
w Activity 2.2: Building the exterior
w Activity 2.3: Finishing the interior
v Activity 2.1 : Site preparation
w Task 2.1.1: Surveying
w Task 2.1.2: Obtaining permits
w Task 2.1.3: Excavating
v Task 2.1.4: Obtaining materials


Activity 2: Building a House, ctd

v Activity 2.2: Building the v Activity 2.3 : Finishing the
exterior Interior
w Task 2.2.1: Foundation w Task 2.3.1: Interior
w Task 2.2.2: Outside Walls plumbing
w Task 2.2.3: Exterior w Task 2.3.2: Interior
plumbing electrical work
w Task 2.2.4: Exterior w Task 2.3.3: Wallboard
electrical work w Task 2.3.4: Interior
w Task 2.2.5: Exterior siding painting
w Task 2.2.6: Exteror painting w Task 2.3.5: Floor covering
w Task 2.2.7: Doors and w Task 2.3.6: Doors and
Fixtures fixtures
w Task 2.2.8: Roof


Activity Graph for Activity “Building a House”
START

Build Outside Wall
Surveying
1.2 1.1
Excavation
1.3
Buy Materials
1.4
Lay Foundation
2.1
Build Outside Wall
Install Exterior Plumbing 2.2
Install Interior Plumbing

2.3 3.1
Install Exterior Electrical Install Interior Electrical
2.4 3.2
Install Exterior Siding Install Wallboard
2.5 3.3
Paint Exterior Install Flooring Paint Interior
2.6 3.4 3.5
Install Exterior Doors Install Rooﬁng
Install Interior Doors
2.7 2.8 3.6

2.6 FINISH

PERT Chart Example for "Building a House"
12/3/94 12/21/94 1/11/95
Install Install Install
Interior Interior Wallboard
Plumbing Electrical
Building a House:
0 0 0 1/22/95
12 15 9 Paint
MS Project PERTcy
Interior
Chart with Duration of
Activities (Pfleeger 2.3) 0 2/8/95
11
1/22/95 Install
Interior
Install Doors
Flooring
0
10/15/94 11/5/94 7
8/27/94 8/27/94 9/17/94 10/1/94 0 2/16/95
Lay Build 18
START Survey Excava Buy 1/19/95 FINISH
Founda Outside
ing tion Material
tion Wall Install
0 Roofing 1/19/95 0
0 12 0 0 0
0 10 10 Install 0
3 15 20 12
9 Exterior
Doors
8/27/94
15
Request 1/12/95
6
Permits Paint
0 Exterior
15 12
5
12/3/94 12/17/94 12/31/94

Install Install Install
Start Time 8/29/94
Exterior Exterior Exterior
Legend Plumbing Electrical Siding

12 12 12
Slack Time 0 8
10 10
Duration 0


Slack Time and Critical Path

v Slack Time
w Available Time - Estimated (“Real”) Time for a task or activity
w Or: Latest Start Time - Earliest Start Time
v Critical Path
w 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.


How do you become a good project planner?

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


Writing the SPMP

v Example of a full SPMP for the OWL project
w http://cascade1.se.cs.cmu.edu/15-413/courseDocs/spmpF96.html


Project Management Heuristics

v Make sure to be able to revise or dump a project plan
w Complex system development is a nonlinear activity
v If project goals are unclear and complex use team-based
project management. In this case
w Avoid perfect GANTT charts and PERT charts
w Don’t look too far into the future
v Avoid micro management of details
v Don’t be surprise if current project management tools
don’t work:
w They were designed for projects with clear goals and fixed
organizational structures


Project Management Summary

v Get agreement among customers, managers and teams
w Problem statement
w Software project management plan
w Project agreement
w Make sure agreement allows for iteration
v Team Structures
v Project planning
w Start with work breakdown structure (WBS)
w Identify dependencies and structure: Tasks, activities, functions
v Tools and Techniques
w GANTT, Dependency graph, Schedule, Critical Path Analysis


Communication Management

v Communication in distributed Teams
v Communication Modes
v Communication Mechanisms
v Scheduled Communications
v Communication workflow
w Example: Distributed Document Review with Lotus Notes


A Communication Example

v "Two missile electrical boxes manufactured by
different contractors were joined together by a pair of
wires.

Box 1 Pair of Wires Box 2


A Communication Example ctd

v Thanks to a particular thorough preflight check, it was
discovered that the wires had been reversed."

Box 1 Box 2


After the Crash...

v ...
v "The postflight analysis revealed that the contractors
had indeed corrected the reversed wires as instructed."


“In fact, both of them had.”

Box 1 Box 2


Communication is Important

v Communication Mode:
Type of information exchange that has defined
objectives and scope
w Scheduled: Planned Communication
w Event Driven:Unplanned Communication
v Communication Mechanism
Tool or procedure that can be used to transmit or
receive information
w Synchronous: Sender and Receiver are available at the
same time
w Asynchronous: Sender and Receiver are not
communicating at the same time.

Classification of Communication

Communication supports Communication
mode is supported by mechanism

Scheduled Event driven Synchronous Asynchronous

Client review Problem reporting Smoke signals Fax


Scheduled Modes of Communication
v Problem Definition
w Objective: Present Goals & Requirements
(Functional, Nonfunctional) and Constraints
u Problem Statement Presentation (JAMES Example: August 26, 97)

v Project Review: Focus on System Model
w Objective: Assess status and review subsystem
interfaces
u Analysis Review (October 16, 1997)
u Object Design Review (November 11 & 13, 1997)
u Implementation Review (November 25, 1997)

v Client Review: Focus on Requirements
w Objective: Brief Client of Progress, Confirm Changes
in Requirements
u System Design Review (October 23, 1997)

v Walkthrough (Informal)
w Objective: Increase quality of subsystem
w Developer presents to team members Informal, peer-
to-peer
u To be scheduled by each team
v Inspection (Formal)
w Objective: Compliance with (functional and
nonfunctional) requirements
w Developer answers questions from the reviewers
u Client Acceptance Test (December 9, 1997)



v Status Review:
w Objective: Find deviations from schedule and
correct them or identify new issues
w Part of every team meeting (Status)
v Brainstorming:
w Objective: Generate and evaluate large number of
solutions for a problem
w Part of every team meeting (Discussion)


Meeting as Scheduled and Synchronous
Communication
v Purpose of Meeting
w Why do we meet?
v Desired Outcome
w What do we want to achieve?
v Information Sharing
w Action Items
v Information Processing
w Open Issues
Action Items
v Meeting Critique (From previous
meeting)

Issues
(From previous
meetings and
BBoards)


v Release
w The result of each software development activity
u Software Project Management Plan (SPMP)
u Requirements Analysis Document (RAD)
u System Design Document (SDD)
u Object Design Document (ODD)
u Test Manual
u User Manual
v Postmortem Review
w Objective: Describe Lessons Learned
u Final Homework (December 16, 1997)


Event-Driven Modes of Communication

v Request for Clarification
v Change Request
v Resolution of Issue


Synchronous Communication Mechanisms

v Hallway conversation
w Unplanned face-to-face meeting
v Questionaire and structured interviews
v Meeting
w Planned Face-to-Face Meeting, Telephone conversation
v Groupware
w Same time, different location groupware


Asynchronous Communication Mechanisms

v E-Mail
v Newsgroups
v Web
v Lotus Notes


Example of Asynchronous Documentation:
Document Review

v Fill out a review form
v Attach document to be reviewed
v Distribute the review form to reviewers
v Wait for comments from reviewers
v Review comments
v Create action items from selected comments
v Revise document and post the revised version
v Iterate the review cycle

Example:
w “Review of Documents” Database in JAMES Project


Review of
Documents
Database


NewReview Form


Fill out the Review Form

v Select reviewers
v Select the document to be reviewed
v Add comments to reviewers
v Determine deadline


Reviewer Notification
v Selected reviewers get e-mail


Status of Document Review


Reviewers
add their
Comments


Originator Notification


Final Recipient Notification


Document Editor & Web Master Tasks

v Editor reviews comments
v Editor selects reviewed comments
v Web Master posts reviewed document and action items
v Team members complete their action items
v Editor integrates changes
v Editor posts changed document on the review database
for the next review cycle


Accepted Document w/ Action Items


SPMP Action Items


Summary

v Communication Modes vs Communication Mechanisms
v Scheduled Communications
v Asynchronous Communications
v Team review of documents with Lotus Notes


Project management

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (18)

Andere mochten auch

Andere mochten auch (19)

Ähnlich wie Project management

Ähnlich wie Project management (20)

Mehr von Saumya Sahu

Mehr von Saumya Sahu (19)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Project management