8 Project Plan

SoberIT Software Business and Engineering Institute

HELSINKI UNIVERSITY OF TECHNOLOGY

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



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



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)



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



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



Links to Other Documents   If the company has

documented, e.g., useful processes, practices and methods, etc. then all these should not be copied to project plan, but instead only referenced   Add the name of the

document   Add a link to place where

to find the document   Problem: linked

documents are not read. Add short summary?

  In the plan you could include, e.g., information about   how to apply the

documented processes, practices and methods in this project, if needed

  name the roles and responsible persons to different tasks mentioned in documented processes, practices and methods



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



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



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



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



The Contents of a Project Plan (1/2) 1. Project overview

  background   purpose, scope, objectives   assumptions, constraints   deliverables   customer responsibilities   schedule and budget

summary   evolution of the plan   references   definitions

2. Project organization   external interfaces   internal structure   roles and responsibilities

3. Project partitioning   process model   project milestones   project phases /cycles   release plan

4. Work plan   work activities   schedule   resource allocation

5. Technical plan   methods, tools, techniques   infrastructure



The Contents of a Project Plan (2/2) 6. Support processes

  Staff training   Quality assurance, reviews,

testing   Configuration / version

management   Documentation

7. Partnering / subcontracting 8. Communication plan

  internal communication practices

  informing

9. Control plan   project management

practices   reporting   requirements, schedule,

quality, budget control   change procedure   metrics collection

10. Risk management 11. Project closeout

  acceptance plan and criteria   close out plan

12. Budget



Contents of a Project Plan (IEEE Standard for Software Project Management Plans, Std 1058-1998) Title page Signature page Change history Preface Table of contents List of figures List of tables 1. Overview 1.1 Project summary

1.1.1 Purpose, scope, objectives 1.1.2 Assumptions and constraints 1.1.3 Project deliverables 1.1.4 Schedule and budget summary

1.2 Evolution of the plan 2. References 3. Definitions 4. Project organization 4.1 External interfaces 4.2 Internal structure 4.3 Roles and responsibilities 5. Managerial process plans 5.1 Start-up plan

5.1.1 Estimation plan 5.1.2 Staffing plan 5.1.3 Resource acquisition plan 5.1.4 Project staff training plan

5.2 Work plan 5.2.1 Work activities



Contents of a Project Plan (IEEE Standard for Software Project Management Plans, Std 1058-1998) Cont. 5.2.2 Schedule allocation 5.2.3 Resource allocation 5.2.4 Budget allocation 5.3 Control plan 5.3.1 Requirements control plan 5.3.2 Schedule control plan 5.3.3 Budget control plan 5.3.4 Quality control plan 5.3.5 Reporting plan 5.3.6 Metrics collection plan 5.4. Risk management plan 5.5 Closeout plan 6. Technical process plans 6.1 Process model

6.2 Methods, tools, and techniques 6.3 Infrastructure plan 6.4 Product acceptance plan 7. Supporting process plans 7.1 Configuration management

plan 7.2 Verification and validation plan 7.3 Documentation plan 7.4 Quality assurance plan 7.5 Reviews and audits 7.6 Problem resolution plan 7.7 Subcontractor management

plan 7.8 Process improvement plan 8. Additional plans Annexes Index



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



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



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



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



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



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



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: …



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, …)



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



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?



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



6. Support Processes   Documentation

  Documentation required during the project   Roles and responsibilities   Documentation process

 Document creation   Acceptance  Delivery  Maintenance and archiving



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



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



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



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.



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



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



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?



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



11. Project Closeout, 12. Budget   Project closeout

  Acceptance plan and criteria   Close out plan   Collecting Lessons learned

  Budget



Starting a Project



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”



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.



Starting a Project   Getting everybody to know each other

  Transparency   Motivation   Trust

=> Kick-off meeting



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



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



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



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)



Ending a Project



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



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



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



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



Thank you.

Questions?

Tuomas Niinimäki

[email protected]

8 Project Plan

Documents

Transcript of 8 Project Plan