1. T-76.4115/5115 Software Development Project I/II Project Planning Jari Vanhanen Ohjelmistoliiketoiminnan ja –tuotannon laboratorio Software Business and Engineering Institute (SoberIT)

2. A story of four people... This is a story about four people named Everybody, Somebody, Anybody and Nobody. There was an important job to be done and Everybody was sure that Somebody would do it. Anybody could have done it, but Nobody did it. Somebody got angry about that, because it was Everybody’s job. Everybody thought Anybody would do it, and Nobody realised that Everybody wouldn’t do it. It ended up so that Everybody blamed Somebody when Nobody did what Anybody could have done.

3. Is project planning difficult?  Yes, probably, but it should provide answers to fairly simple questions: - Why? - What? - When? - Who? - Where? - How? - How much? - Assuming? Goals Work Products and Milestones Responsibilities, Coordination Risks, Beliefs, Priorities Resources Approach, Practices, Tools

4. The project planning iteration  Requirements definition  crucial for project planning  lecture on Tu 4.10.  topics  project's business goals  main domain concepts  user groups  functional and non functional requirements  use cases  only shortly, detailed analysis later  Project planning  see the next slides  The first practical arrangements  schedule customer meetings  do iteration planning  start time reporting  find out hw&sw needs  make contracts (IPR, NDA)  create project web pages  schedule mentor meeting(s)

5. Project plan  Planning is more important than document its results  but documenting is needed in this kind of a project  Project plan  ”contract” with the customer  communication  basis for tracking and control  keep up-to-date  Mandatory template  you can skip irrelevant sections with an explanation  Content of the project plan 1. Introduction 2. Stakeholders and staffing 3. Goals and end criteria 4. Resources and budget 5. Work practices and tools 6. Phasing 7. Risk log

6. 1. Introduction 1.1 Overview of the project  a brief overview of the system to be developed  motivation for its development  environment where it will be used 1.2 Terminology  you can also create a project level terminology document

7. 2. Stakeholders and staffing  Customer  Tech. advisor  3 rd parties  Project group and its roles  sub groups?  Mentor  Draw an organization chart showing the relationships between stakeholders  Contact information  emails, phones, web pages, wiki etc.

8. 3. Goals and end criteria  Explore and prioritize the goals for each stakeholder  Define verification criteria  Resolve conflicts  Form a project objective that everyone commits to  manage the expectation level of the customer  Goals and priorities change  keep them up-to-date!  document changes (and reasons)  After final delivery the project is evaluated against these goals 3.1 Goals of the customer  core functions and properties of the system  work practices, schedule, documentation 3.2 Goals of the project group 3.3 Personal learning goals 3.4 Project abort and end criteria

9. 4. Resources and budget 4.1 Personnel  x hours/person  effort distribution between iterations  how many hours by whom  depends on roles  allocated vs. max. available vs. required?  absences 4.2 Materials  hardware and software resources  other materials (books etc.)  limitations in availability 4.3 Budget  theoretical costs for work effort

10. 5. Work practices and tools  Prepare the infrastructure  Plan which practices and tools you will use and how  communication, team work, all sw development activities  Document practices shortly  communicate the project members how to follow them  overview to customer and mentor  what, why, when, who  make sure they get adopted  Update these during the project  collect and report experiences 5.1 Practices  5.1.1 Practice X 5.2 QA Plan  5.2.1 project level  5.2.2 iteration level 5.3 Tools  summary of all tools used 5.4 Standards  any mandatory standards?

11. 6. Phasing  Schedule must be based on process framework  add internal milestones  Plan the tentative goals and deliverables for all the iterations with the customer  Each iteration plan is refined during iteration planning  make PP iteration plan immediately 6.1 Schedule 6.2-6.4 Iteration plans  goals  deliverables  tasks

12. 7. Risk log  Document the most important risks in the risk log  Keep the risk log up-to-date  See the Risk Management practice 7. Risk log  risk, effects, controlling actions, responsible

13. Hints  Arrange a kick-off  Get to know each other  Discuss and agree on roles and responsibilities  Find out about each other’s commitments and personal interests  Agree on your team’s goals  Agree on practices and practicalities  It is a group effort!  Start work immediately in the beginning of iterations  more calendar time to react to unexpected situations  Test unfamiliar technologies and tools early to minimize risks

14. Hints  Spy on others to get ideas  Projects from previous years/this year  give a reference, if you copy some ideas/materials  Try one-day group sessions  work together as a “team”  peer pressure as booster for productivity  problems can be addressed immediately  prepare well (e.g. hw+sw)  food and beverages

15. Hints  Do not expect that the customer knows exactly what she wants and is able to communicate it clearly  Manage customer’s expectations  present realistic plans

16. After the PP iteration you should  know what you are going to develop and why  requirements document  first version  stakeholder goals  know who will participate in doing what  roles and responsibilities  tentative resource allocations  have decided which practices are used in the project  have identified the risks associated with the project  have agreed on the rights to the project outcome