Strategic Management of Multiple Projects (aka Project Whispering)
8 Project Plan
1. 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
2. SoberIT
Software Business and Engineering Institute
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
HELSINKI UNIVERSITY OF TECHNOLOGY
3. SoberIT
Software Business and Engineering Institute
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)
HELSINKI UNIVERSITY OF TECHNOLOGY
4. SoberIT
Software Business and Engineering Institute
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
HELSINKI UNIVERSITY OF TECHNOLOGY
5. SoberIT
Software Business and Engineering Institute
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
HELSINKI UNIVERSITY OF TECHNOLOGY
6. SoberIT
Software Business and Engineering Institute
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?
HELSINKI UNIVERSITY OF TECHNOLOGY
7. SoberIT
Software Business and Engineering Institute
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
HELSINKI UNIVERSITY OF TECHNOLOGY
8. SoberIT
Software Business and Engineering Institute
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
HELSINKI UNIVERSITY OF TECHNOLOGY
9. SoberIT
Software Business and Engineering Institute
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
HELSINKI UNIVERSITY OF TECHNOLOGY
10. SoberIT
Software Business and Engineering Institute
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
HELSINKI UNIVERSITY OF TECHNOLOGY
11. SoberIT
Software Business and Engineering Institute
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
HELSINKI UNIVERSITY OF TECHNOLOGY
12. SoberIT
Software Business and Engineering Institute
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
HELSINKI UNIVERSITY OF TECHNOLOGY
13. SoberIT
Software Business and Engineering Institute
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
HELSINKI UNIVERSITY OF TECHNOLOGY
14. SoberIT
Software Business and Engineering Institute
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
15. SoberIT
Software Business and Engineering Institute
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
HELSINKI UNIVERSITY OF TECHNOLOGY
16. SoberIT
Software Business and Engineering Institute
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
HELSINKI UNIVERSITY OF TECHNOLOGY
17. SoberIT
Software Business and Engineering Institute
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
HELSINKI UNIVERSITY OF TECHNOLOGY
18. SoberIT
Software Business and Engineering Institute
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
HELSINKI UNIVERSITY OF TECHNOLOGY
19. SoberIT
Software Business and Engineering Institute
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
HELSINKI UNIVERSITY OF TECHNOLOGY
20. SoberIT
Software Business and Engineering Institute
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
HELSINKI UNIVERSITY OF TECHNOLOGY
21. SoberIT
Software Business and Engineering Institute
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: …
HELSINKI UNIVERSITY OF TECHNOLOGY
22. SoberIT
Software Business and Engineering Institute
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, …)
HELSINKI UNIVERSITY OF TECHNOLOGY
23. SoberIT
Software Business and Engineering Institute
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
HELSINKI UNIVERSITY OF TECHNOLOGY
24. SoberIT
Software Business and Engineering Institute
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?
HELSINKI UNIVERSITY OF TECHNOLOGY
25. SoberIT
Software Business and Engineering Institute
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
HELSINKI UNIVERSITY OF TECHNOLOGY
26. SoberIT
Software Business and Engineering Institute
6. Support Processes
Documentation
Documentation required during the project
Roles and responsibilities
Documentation process
Document creation
Acceptance
Delivery
Maintenance and archiving
HELSINKI UNIVERSITY OF TECHNOLOGY
27. SoberIT
Software Business and Engineering Institute
6. Support Processes
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
HELSINKI UNIVERSITY OF TECHNOLOGY
28. SoberIT
Software Business and Engineering Institute
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
HELSINKI UNIVERSITY OF TECHNOLOGY
29. SoberIT
Software Business and Engineering Institute
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
HELSINKI UNIVERSITY OF TECHNOLOGY
30. SoberIT
Software Business and Engineering Institute
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.
HELSINKI UNIVERSITY OF TECHNOLOGY
31. SoberIT
Software Business and Engineering Institute
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.)
HELSINKI UNIVERSITY OF TECHNOLOGY
32. SoberIT
Software Business and Engineering Institute
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
HELSINKI UNIVERSITY OF TECHNOLOGY
33. SoberIT
Software Business and Engineering Institute
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?
HELSINKI UNIVERSITY OF TECHNOLOGY
34. SoberIT
Software Business and Engineering Institute
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
HELSINKI UNIVERSITY OF TECHNOLOGY
35. SoberIT
Software Business and Engineering Institute
11. Project Closeout, 12. Budget
Project closeout Budget
Acceptance plan and criteria
Close out plan
Collecting Lessons learned
HELSINKI UNIVERSITY OF TECHNOLOGY
37. SoberIT
Software Business and Engineering Institute
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”
HELSINKI UNIVERSITY OF TECHNOLOGY
38. SoberIT
Software Business and Engineering Institute
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.
HELSINKI UNIVERSITY OF TECHNOLOGY
39. SoberIT
Software Business and Engineering Institute
Starting a Project
Getting everybody to know each other
Transparency
Motivation
Trust
=> Kick-off meeting
HELSINKI UNIVERSITY OF TECHNOLOGY
40. SoberIT
Software Business and Engineering Institute
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
HELSINKI UNIVERSITY OF TECHNOLOGY
41. SoberIT
Software Business and Engineering Institute
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
HELSINKI UNIVERSITY OF TECHNOLOGY
42. SoberIT
Software Business and Engineering Institute
Starting a Distributed Project (2/3)
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
HELSINKI UNIVERSITY OF TECHNOLOGY
43. SoberIT
Software Business and Engineering Institute
Starting a Distributed Project (3/3)
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)
HELSINKI UNIVERSITY OF TECHNOLOGY
45. SoberIT
Software Business and Engineering Institute
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
HELSINKI UNIVERSITY OF TECHNOLOGY
46. SoberIT
Software Business and Engineering Institute
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
HELSINKI UNIVERSITY OF TECHNOLOGY
47. SoberIT
Software Business and Engineering Institute
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
HELSINKI UNIVERSITY OF TECHNOLOGY
48. SoberIT
Software Business and Engineering Institute
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
HELSINKI UNIVERSITY OF TECHNOLOGY
49. SoberIT
Software Business and Engineering Institute
Thank you.
Questions?
Tuomas Niinimäki
tuomas.niinimaki@soberit.hut.fi
HELSINKI UNIVERSITY OF TECHNOLOGY