8 Project Plan

SoberIT
Software Business and Engineering Institute

T-76.5612 Software Project Management

8: Project Plan & Starting and Ending a
Project

Tuomas Niinimäki
Software Process Research Group
SoberIT
Helsinki University of Technology

HELSINKI UNIVERSITY OF TECHNOLOGY

SoberIT

The Uses of the Project Plan
  The project plan is often the most important project document
  The primary purpose of a project plan is to
  document planning assumptions and decisions
  facilitate communication among shareholders
  document approved scope, cost and schedule baselines
  In the beginning of the project
  writing a project plan requires to agree on and consider many
important matters
  the project plan is used to communicate information to
different stakeholders
  During the project, project plan is used for
  checking what was agreed on
  communicating project info e.g. to new project members

SoberIT

The Users of the Project Plan
  Project plan is a tool to deliver information about the project to
stakeholders
  same information to everybody
  a common understanding about the project

  All project stakeholders, e.g.
  project manager
  project board
  team leaders
  customer(s)
  project team members
  subcontractor(s)

SoberIT

The Needed Level of Detail
  Length and the level of detail of the project plan depends e.g. on
  the purpose of the plan
  project type and size
  the number of participants
  whether the company has documented processes and
practices that can be used and only referenced in the plan

  The project plan should be manageable, not too extensive
  All important information should be included
  No software development project is so small that project plan
would not be needed


SoberIT

Templates for a Project Plan
  Most companies have their own templates
  Many good suggestions can be found (e.g. IEEE standard)
  All titles mentioned in project plan templates should not be used
in all projects
  They are just models for general projects
  Some chapters can be left out and other included when
needed
  You can modify a suitable project plan template for your project,
e.g. depending on
  the project type (product vs. customer specific system)
  use of partners or subcontractors
  size of your project


SoberIT

Links to Other Documents
  If the company has   In the plan you could include,
documented, e.g., useful e.g., information about
processes, practices and   how to apply the
methods, etc. then all these documented processes,
should not be copied to practices and methods in
project plan, but instead only this project, if needed
referenced   name the roles and
  Add the name of the responsible persons to
document different tasks mentioned
  Add a link to place where in documented processes,
to find the document practices and methods
  Problem: linked
documents are not read.
Add short summary?


SoberIT

Practical Information
  Project plan should include also practical information that is
useful for team members in executing the project, e.g.
  Working practices that are agreed to be used in the project, such
as
  management practices
  working methods
  reporting practices
  communication practices
  change management
  Roles and responsibilities of
  different organizations
  team members


SoberIT

Confidential Information
  If the problem is that project plan contains budget information
and therefore cannot be delivered to all parties, e.g., team
members or subcontractors
  remove budget info from a working version and deliver
  Create a separate document for confidential issues and
include a link to it


SoberIT

Steps for Doing a Project Plan
  Accepting the project plan
  e.g. project board
  Deliver the project plan to all involved and inform
  The project plan can and should be updated, at least the most
important changes
  version history
  decide who can do / approve changes, e.g.
  project board


SoberIT

Steps for Doing a Project Plan
  Project manager is often responsible for writing the project plan
  Involve your team members in planning to motivate and commit
them
  either involve them in planning and writing
  or invite them to comment and discuss about the first version
of the plan


SoberIT

The Contents of a Project Plan (1/2)
1. Project overview 3. Project partitioning
  background   process model
  purpose, scope, objectives   project milestones
  assumptions, constraints   project phases /cycles
  deliverables   release plan
  customer responsibilities 4. Work plan
  schedule and budget
summary   work activities
  evolution of the plan   schedule
  references   resource allocation
  definitions 5. Technical plan
2. Project organization   methods, tools, techniques
  external interfaces   infrastructure
  internal structure
  roles and responsibilities

SoberIT

The Contents of a Project Plan (2/2)
6. Support processes 9. Control plan
  Staff training   project management
practices
  Quality assurance, reviews,
testing   reporting
  Configuration / version
  requirements, schedule,
quality, budget control
management
  change procedure
  Documentation
  metrics collection
7. Partnering / subcontracting
10. Risk management
8. Communication plan 11. Project closeout
  internal communication   acceptance plan and criteria
practices   close out plan
  informing 12. Budget


SoberIT

Contents of a Project Plan (IEEE Standard for
Software Project Management Plans, Std 1058-1998)
Title page 1.2 Evolution of the plan
Signature page 2. References
Change history 3. Definitions
Preface 4. Project organization
Table of contents 4.1 External interfaces
List of figures 4.2 Internal structure
List of tables 4.3 Roles and responsibilities
1. Overview 5. Managerial process plans
1.1 Project summary 5.1 Start-up plan
1.1.1 Purpose, scope, objectives 5.1.1 Estimation plan
1.1.2 Assumptions and constraints 5.1.2 Staffing plan
1.1.3 Project deliverables 5.1.3 Resource acquisition plan
1.1.4 Schedule and budget 5.1.4 Project staff training plan
summary 5.2 Work plan
5.2.1 Work activities

SoberIT

Contents of a Project Plan (IEEE Standard for
Software Project Management Plans, Std 1058-1998) Cont.
5.2.2 Schedule allocation 6.2 Methods, tools, and techniques
5.2.3 Resource allocation 6.3 Infrastructure plan
5.2.4 Budget allocation 6.4 Product acceptance plan
5.3 Control plan 7. Supporting process plans
5.3.1 Requirements control plan 7.1 Configuration management
5.3.2 Schedule control plan plan
5.3.3 Budget control plan 7.2 Verification and validation plan
5.3.4 Quality control plan 7.3 Documentation plan
5.3.5 Reporting plan 7.4 Quality assurance plan
5.3.6 Metrics collection plan 7.5 Reviews and audits
5.4. Risk management plan 7.6 Problem resolution plan
5.5 Closeout plan 7.7 Subcontractor management
6. Technical process plans plan
7.8 Process improvement plan
6.1 Process model
8. Additional plans
HELSINKI UNIVERSITY OF TECHNOLOGY Annexes
Index

SoberIT

The Contents of a Project Plan
1. Project overview
2. Project organization
3. Project partitioning
4. Work plan
5. Technical plan
6. Support processes
7. Partnering / subcontracting
8. Communication plan
9. Control plan
10. Risk management
11. Project closeout
12. Project budget

SoberIT

1. Project Overview
  Background
  Why was this project initiated?
  What has happened before?
  Purpose, scope, objectives
  Primary and secondary purposes
  Scope: what is included in the project and WHAT IS NOT
  Assumptions, constraints
  Initial assumptions that has been made
  Constraints for the plan
  Evolution of the plan
  How the plan is updated?
  How updated plans are delivered?
  Definitions
  Terms and acronyms used in the project plan

SoberIT

1. Project Overview
  Deliverables
  The most important deliverables
  Customer responsibilities:
  Summary of what internal/external customer should do
  Schedule and budget summary
  Top level summary
  NB: use automation to keep this synchronized with the more detailed
budget (e.g. in Chapter 12)
  References
  List of documents referenced in the project plan and place where
they can be found


SoberIT

2. Project Organization
  Internal structure
  Internal structure of the project organization
  Interface among the units of the software development team
  Interfaces with entities that provide support processes, e.g. quality
assurance
  E.g. organization charts and diagrams
  Lines of authority, responsibility, communication
  External interfaces
  Organizational boundaries between the project and external entities
  E.g. customer, subcontractors, other organizations interacting with
the project
  Use, e.g., organization chart, diagrams
  Roles and responsibilities
  Major work activities and organizations / organizational units /
persons responsible for them

SoberIT

3. Project Partitioning
  Process model
  Methods and models used in implementing the project (e.g.
incremental, waterfall)
  Project milestones
  Contents and schedule for the major project milestones
  Project phases /cycles
  The major project phases
  The main work activities included in each phase
  Release plan
  Internal / external releases and their contents


SoberIT

4. Work Plan
  Work activities
  Specifies various work activities performed in the project
  Work break down structure
  Relationships among work activities

  The level of decomposition depends on information available
  Detail level of work breakdown depends also on the size of the
project
  Project plan should be readable and usable
  For a large project, it doesn’t make sense to have detailed work
breakdown
  Large projects should be divided into subprojects


SoberIT

4. Work Plan
  Schedule
  Scheduling relationships among work activities, time-sequencing
  Milestones
  Milestone charts, activity lists, Gantt charts, critical path networks,
activity networks

  Take different stakeholders into account!
  Project team milestones: e.g. design ready, implementation of X
ready
  Customer milestones: e.g. feature freeze, user manual ready, ready
for acceptance testing, ready for deployment
  Management / financial milestones: e.g. go-live, responsibility
handout, billing schedule?
  Other stakeholders: …

SoberIT

4. Work Plan
  Resource allocation
  Resources allocated to each major work activity in the project work
break down structure
  Number and required skill levels

  Take account all relevant resource types
  Team members
  External resources (IT support, specialists, subcontractors, …)
  Specific software and hardware (e.g. test labs, development servers,
production servers)
  Workplace arrangements (team rooms, office space, meeting rooms,
facilities for code/test/integration camps, …)


SoberIT

5. Technical Plan
  Work practices
  Development methodologies, programming languages, frameworks
  Tools and techniques to be used to specify, design, build, test,
integrate, document, deliver, modify and maintain project work
products
  Technical standards used


SoberIT

5. Technical Plan
  Infrastructure
  Plan to establish and maintain development environment (hardware,
network, software)
  Facilities and resources required to conduct the project
  Office space
  Hardware (Workstations, dev. infrastructure, test/production
servers, …)
  Software tools
  Administrative/support personnel
  …
  Roles and responsibilities for infrastructure
  Who provides and maintains infrastructure?
  How infrastructure is used?

SoberIT

6. Support Processes
  Quality assurance
  Quality goals and metrics
  Reviews, audits, inspections, assessments
  Process monitoring, control and improvement
  Metrics
  Schedule, resources and responsibilities
  Configuration management
  Version management, build management, variation/customization
management
  Methods and tools used


SoberIT

  Documentation
  Documentation required during the project
  Roles and responsibilities
  Documentation process
  Document creation
  Acceptance
  Delivery
  Maintenance and archiving


SoberIT

  Staff training
  Training needed to ensure sufficient skill levels necessary for the
project execution
  Type of training
  Number of personnel trained
  Method of training
  Team building
  Building and maintaining trust and motivation
  Knowledge sharing
  Team outing, workshops, …
  Conflict resolution


SoberIT

7. Partnering / Subcontracting
  Can be left out if partners not involved
  If close cooperation and frequent communication and collaboration with
partner is needed during the project, most of this information can be
included in all related project plan sections, e.g. organization, methods,
communication, etc.

  Subcontractors / partners
  Organizations
  Responsibilities
  Processes, tools methods used
  Project management practices
  Meetings, reporting, teambuilding
  Deliveries
  Support provided

SoberIT

8. Communication Plan
  Plan both project internal and external communication
  Project internal communication plan:
  project team members, closely involved subcontractors
  especially when having several organizations, e.g. internal
departments or subcontractors involved planning project internal
communication is important
  find out communication needs of the project
  plan communication protocol


SoberIT

8. Communication Plan
  Plan both project internal and external communication

  External communication plan:
  Includes especially informing external groups, but also about getting
feedback and decisions
  Involved parties
  Internal departments not directly involved in project, e.g.,
marketing
  Project board and management
  Customer
  Subcontractors / partners
  Meetings, reports, etc.


SoberIT

Writing a Communication Plan
  Communication protocol
  ”All emails will be acknowledged as received within 24 hr”
  ”All phone messages shall be returned within 4 hr”
  Especially important in distributed projects
  Formal communication (e.g. meetings, reports)
  Informal communication (e.g. discussion lists, email)
  Communication media used for different purposes (e.g. when to phone,
when to use email)
  Schedule (e.g. how often and what kind of meetings are arranged)
  Response time (e.g., how fast to answer subcontractor’s questions)
  Responsible persons (e.g., who is responsible to answer questions
coming from subcontractors)
  Decision making rights (e.g., who can decide about changes etc.)
  Informing project team (e.g., about project progress, problems etc.)


SoberIT

9. Control Plan
  Project management practices
  Control procedures at different levels: team internal, control board
  E.g. project team weekly meetings, control board meetings
  Reporting
  Reporting flows and mechanisms
  Reported information
  Metrics collection
  Specifies the metrics collected
  Methods, tools, techniques
  Frequency of collection
  Reporting


SoberIT

9. Control Plan
  Requirements, schedule, quality, budget control
  Measuring the project progress
  Reporting deviations
  Controlling changes
  Change procedure
  What kind of changes can there be?
  How changes are requested?
  How changes can be accepted?


SoberIT

10. Risk Management
  Risk management procedure used during the project
  For identifying, analyzing, prioritizing risk factors
  Assessing risks and mitigation of risk factors
  E.g., reviewing Top-10 Risk list in weekly meetings
  List of the most important risks in a prioritized list
  Actions to react and mitigate these risks
  Actions to be done if risks materialize


SoberIT

11. Project Closeout, 12. Budget
  Project closeout   Budget
  Acceptance plan and criteria
  Close out plan
  Collecting Lessons learned


SoberIT

Starting a Project


SoberIT

Starting a Project
  Setting up a project requires a lot of work and time
  Often part of the effort neglected which might cause trouble later on
  Fuzzy Front End: “It is in the front end where the organization formulates a
concept of the product to be developed and decides whether or not to invest
resources in the further development of an idea. It is the phase between first
consideration of an opportunity and when it is judged ready to enter the
structured development process”


SoberIT

Starting a Project
  Writing a project plan
  Distribute: distributing a project plan is not enough
  Discuss: involvement and motivation is important
  Written information is not enough (e.g. telling a subcontractor: ”
Here is our process description, that is how we should work in this
project”)
  Informing all involved about
  project objectives
  participants
  responsibilities
  schedule
  processes
  methods, tools, working practices
  communication, etc.

SoberIT

Starting a Project
  Getting everybody to know each other
  Transparency
  Motivation
  Trust
=> Kick-off meeting


SoberIT

Kick-off Meeting
  Kick-off meeting is a project start up meeting, arranged
especially for project team members
  Formal program: information about the project
  Informal program: team building
  Formal program is used to share information and knowledge
  All involved in the project can meet face-to-face and get to know
each others
  Informal program and teambuilding activities are important
part of kick-off meeting
  Team building aspect is especially important for projects, where
  project team has not before worked together
  several organizations, e.g., subcontractors are involved


SoberIT

Starting a Distributed Project (1/3)
  Starting a distributed project requires a lot of effort!!
  Allocate extra time
  Organization
  Choose your partners carefully
  Do not involve too many partners and locations
  Plan how to divide work effectively
  Minimize the need for communication between sites
  Modular product structure
  Sub-project manager or team leader at every site


SoberIT

  What kind of a project?
  Organize the project and choose the collaboration practices
according to the project type
  “The best practices” depend on the context!

  Agree on and inform about
  Project goals
  Participants
  Responsibilities
  Schedule
  Working practices
  Process used
  Tools and methods
  Communication

SoberIT

  Arrange that everybody can find (e.g. from project extranet
page)
  Project plan and other important documents
  Organization chart
  Team-building and trust
  Important to build trust between partners and team members
already in the beginning
  Plan face-to-face meetings (kick-off, trainings, etc.)
  Give faces to all sites
  Seeing good quality work helps to build trust
  Give enough backgroud information
  Customer’s business
  Technology (hands-on training)

SoberIT

Ending a Project


SoberIT

Terminating a Project
  Projects normally end when the tasks are done and the allocated
time is used
  Projects can be also terminated earlier, e.g.
  When a project does not proceed as planned
  Customer requirements or the environment has radically
changed
  Early termination is now more common than earlier
  Milestone reviews can be used as gates for decisions to continue
or end
  Keep motivational factors in mind - terminating a project is a
sensitive issue for team members


SoberIT

Clear Ending
  Projects need a clear ending
  Clear decision
  Formal acceptance of the product of the project by the
sponsor or customer
  E.g., in a review meeting
  The project is accepted and ended
  Comparison against the predetermined acceptance criteria
  No more costs or work on this project after the decision
  Also team members need to know when the project ends
  Arrange, e.g., a project end party when the customer has
accepted the project


SoberIT

Problems
  Some projects never end… they are not projects!
  Maintenance continues
  Maintenance should be clearly separated, e.g., the
development of the next version of the product is a new
project
  Planning of new projects is difficult when earlier projects might
need developers’ attention, e.g., bug fixes
  Some solutions
  E.g., different team for bug fixing
  Multilevel problem solving: customer does not call directly to
developers -> help desk -> person who can solve easier
questions -> developers solve the trickiest problems
  Some percentage of developer’s time is reserved for
maintenance


SoberIT

Lessons Learned
  Lessons learned are collected at the end of the project
  Can include, e.g., problems and mistakes made and solutions
found
  Purpose: to analyze and record problems and solutions learned
to avoid same mistakes or use same successful solutions in
future projects
  Project manager collects with the help of the project team
  Important: Use the information collected!
  E.g., Project managers meet a few times a year and discuss
  Problem: the project manager collects alone, nobody ever reads
and same mistakes occur again and again


SoberIT

Thank you.

Questions?
Tuomas Niinimäki

tuomas.niinimaki@soberit.hut.fi


8 Project Plan

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (18)

Similaire à 8 Project Plan

Similaire à 8 Project Plan (20)

8 Project Plan