Chapter 11, Project Management - PowerPoint PPT Presentation

Loading...

PPT – Chapter 11, Project Management PowerPoint presentation | free to download - id: 82cf2b-NTI2O



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Chapter 11, Project Management

Description:

Title: Lecture for Chapter 11, Project Management Subject: Object-Oriented Software Engineering Author: Bernd Bruegge & Allen Dutoit Last modified by – PowerPoint PPT presentation

Number of Views:53
Avg rating:3.0/5.0

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: Chapter 11, Project Management


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
  • Reference
  • BrueggeDutoit, Chapter 12
  • http//notesbruegge.in.tum.de/PAID2/schedule/Proje
    ctManagement011599.pdf
  • What is not covered in this lecture?
  • Communication Management, Meeting Management
  • Bruegge Dutoit, Chapter 4
  • http//notesbruegge.in.tum.de/PAID2/schedule/Proje
    ctCommunication112598.pdf
  • 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 cant 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.

5
How it should go
6
How it often goes
7
Software Project Management Plan
  • Software Project
  • 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.

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)
11
(No Transcript)
12
Project Functions, Activities and Tasks
13
Functions
  • Activity or set of activities that span the
    duration of the project

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
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
Activities
pProject

Major unit of work with precise dates

Consists of smaller activities or tasks
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
    whos in charge

27
Process Model
  • Shows relationships among
  • 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
Logbook
Architecture
HCI
Maintenance
Web Master
Vehicle
Documentation
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
  • 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 projects 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
Chief Executive
First Level Manager (Front-Line Manager)
Project Members
Basis of organization Complicated information
and control flow across hierarchical boundaries
36
Example of Hierchical OrganizationChief
Programmer Team
Chief Programmer
Assistant Chief Programmer
Librarian
Senior Programmer
Administration
Tester
Junior Programmer
37
Another Project Organization Egoless
Programming Team (Weinberg)
Analyst
Tester
Programmer
Librarian
Designer
38
Project-Based Project Organization
Project Leader
Coaches
Subsystem Team
Subsystem Team
Subsystem Team
Team Members
A
B
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-Withare
    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

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

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 managerNo
    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)
  • http//cascade1.se.cs.cmu.edu/
    15-413/homePagesTeams/UserInterface/www/index.htm

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 ?

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

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

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

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
  • Activity 2.1 Site preparation
  • Task 2.1.1 Surveying
  • Task 2.1.2 Obtaining permits
  • Task 2.1.3 Excavating
  • Task 2.1.4 Obtaining materials

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

67
Activity Graph for Activity Building a House
68
PERT Chart Example for "Building a House"
69
Slack Time and Critical Path
  • Slack Time
  • 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.

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
  • http//cascade1.se.cs.cmu.edu/15-413/courseDocs/sp
    mpF96.html
  • JAMES project
  • http//cascade1.se.cs.cmu.edu/JAMES/J_courseDocs/S
    PMP/SPMP1.0.html

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
  • Dont look too far into the future
  • Avoid micro management of details
  • Dont be surprise if current project management
    tools dont 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
About PowerShow.com