8 Project Plan

1,743 views
1,555 views

Published on

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,743
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
70
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

8 Project Plan

  1. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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
  36. 36. SoberIT Software Business and Engineering Institute Starting a Project HELSINKI UNIVERSITY OF TECHNOLOGY
  37. 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. 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. 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. 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. 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. 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. 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
  44. 44. SoberIT Software Business and Engineering Institute Ending a Project HELSINKI UNIVERSITY OF TECHNOLOGY
  45. 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. 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. 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. 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. 49. SoberIT Software Business and Engineering Institute Thank you. Questions? Tuomas Niinimäki tuomas.niinimaki@soberit.hut.fi HELSINKI UNIVERSITY OF TECHNOLOGY

×