MSD - Project Planning

• • 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

• Empiric estimation methods
• Algoritmic estimation methods
• Pricing to win
• Pain threshold method
• Parkinson’s Law

Expert judgment: Several experts on the proposed software development techniques and
the application domain are consulted. They each estimate the project cost. These estimates
are compared and discussed. The estimation process iterates until an agreed estimate is
reached.

Delphi method: Delphi technique is quite an old but efficient forecasting method. It follows
an interactive approach which relies on exchange of ideas. The team is composed of a group
of experts in their respective domains, who answers the queries in two or more rounds.
Every time a facilitator provides a summary of the collected ideas, which is revised by the
experts if required. The process of opinion and revaluation goes on until a final consensus
is reached. Delphi technique relies its assumption on the fact that assimilation of ideas from a structured group leads to a productive outcome.

Function Point Analysis: Function Point Analysis is a standardized method used commonly
as an estimation technique in software engineering.
In simple words, FPA is a technique used to measure software requirements based on the
different functions that the requirement can be split into. Each function is assigned with
some points based on the FPA rules and then these points are summarized using the FPA
formula. The final figure shows the total man-hours required to achieve the complete requirement.

Widget Point Analysis: Count the UI (user interface) elements and calculate out of this
number the function points. Only useful for software with user interfaces and not many
algorithmic calculations in the background.

Lines of Code (LOC): Easy measurement method. Dependent on the programming language
and the available libraries.

critical path method

critical path analysis

program evaluation and review technique

Critical Path Method / Critical Path Analysis

The critical path method (CPM), or critical path analysis (CPA), is an algorithm for scheduling a set of project activities. It is commonly used in conjunction with the program evaluation and review technique (PERT). A critical path is determined by identifying the longest stretch of dependent activities and measuring the time required to complete them from start to finish.

Gantt charts

A Gantt chart, or harmonogram, is a type of bar chart that illustrates a project schedule. This chart lists the tasks to be performed on the vertical axis, and time intervals on the horizontal axis. The width of the horizontal bars in the graph shows the duration of each activity. Gantt charts illustrate the start and finish dates of the terminal elements and summary elements of a project. Terminal elements and summary elements constitute the work breakdown structure of the project. Modern Gantt charts also show the dependency relationships between activities.

Change of requirements: Scope variations --> Feedback from customer, stakeholders, product owner

Unrealistic planning: Underestimating project group, inaccruate estimations, problem between developers and client --> leads to increase of timeframe = more expenses

Missing experience: reduced know how, SW/HW are too complex, big data, special req.

Improper infrastructure: Delivery by 3rd party, instable SW/HW

Financial issue: Reorganization, incorrect budget estimation, project scope expansion, cost overruns

Communication issues: Inadequate support, misunderstanding, conflicts

Risk = Likelihood · Severity

Avoidance: Removal of the tasks that contain the risk from the project

Acceptance: Acceptance involves planning the risk into the project

Monitor and prepare: Creating plans for monitoring the triggers that activate the risk, Building action plans that can be immediately mobilized upon occurrence of the risk.

Mitigation:

• Probability of occurance: Take measures to reduce the likelihood of a risk occurring. This is usually a more preferable option than reducing the severity because it’s better not to experience the risk occurrance in the first place.
• Severity: Reduce the impact of the risk on the critical success factors of the project.

Transference: transfer the risk onto another party. Naturally, this will usually require some
form of trade-off (or cost).

(LOC) Number of lines of code

Number of classes, methods, relations

Number of changes in a given time frame

Number of errors in a given time frame

Number of lines in a given time frame

Number of working hours