MSD - Project Planning

• Quality
• Schedule
• Scope
• Budget

Stakeholders measure projects by how well they are executed within the project constraints or baselines. A project baseline is an approved plan for a portion of a project. It is used to compare actual performance to planned performance and to determine if project performance is within acceptable guidelines.

• • Cost plan: Creating budget / offer.
• • Time plan: Define activities, deadlines and milestones.
• • Employee plan: Nomination of people and their working time.
• • Organization plan: Agreement of team structure, nomination of responsible persons.
• • Quality plan: Compilation of documents, tools and methods to ensure quality.
• • Project monitor plan: Agreement of actions to control the project and if needed how to change the plans.
• • Configuration management plan: Agreement of actions to control changes in documents, code or data (or any other resources).
• • Education plan: Definition of education for internal (project team) and external people (users, operating stuff).
• • Risk management plan: Agreement of actions to avoid or mitigate risks.

1. Arrange agreement: Define the project scope with a high level time schedule, point in time of devliverables, definition of mile stones.
2. Breakdown requirements: Breakdown the requirements into work packages according to the defined deliverables, create WBS (work breakdown structure). Recommended time for one work package is 4-6 weeks.
3. Estimate effort: Estimate effort for each package based on a value which could be measured. For software components, this could be LOC (lines of code). The LOC value could be used to get the amount of time needed for that component.
4. Define resources: Assign people to activities with respect of their availability, qualification (education) and demand. The best way to do that is the usage of a model with roles and responsibilities.
5. Analyse risks: Identify and prioritize potential risks and possible actions.
6. Define schedule: Description of all work packages and their time dependencies. When is the final point in time to deliver a package, are there any dependencies to other packages? This is typically done with a gantt chart or network diagram.

• • Planning: only plan for the next iteration, version. Not more!
• • Responsibility will be taken over, not assigned
• • Estimates: the responsible persons define the effort and duration
• • Priorities define the order

• • MVP: Minimal viable product. How should the problem be solved to bring additional value. What is to much, what is not enough?
• • Priority: Which tasks should be executed first?
• • Release: Which pieces should be part in the next release?
• • Delivery: Which timeframe is available to be successful?

• • Effort: how long will it take to implement a specific feature?
• • Consequences: what are the consequences for a taken approach?
• • Process: what is the structure for the work and the team?
• • Planning: when will the features be delivered

• • Software-Cost: software, licenses
• • Hardware-Cost: infrastructure (own hardware, cloud-based systems)
• • Personal-Cost: Salary, Expenses

• • Size: Lines of code, classes, methods
• • Complexity: Dependency between the modules, is it possible to build modules?, HW/SW environment
• • Experience: Number of similar executed projects
• • Reliability: error rate, system stability