Teaching slides Chapter 11

Chapter 11: software project execution and conflict management Contents Project execution & conflict management in Waterfall projects : Using slacks in project plans : Using milestones in project plans : Project team conflicts Project execution & conflict management in Agile projects : Burn-down charts : Unknown project metrics : Project team conflict

Chapter 11: software project execution and conflict management Software project execution & conflict management in Waterfall projects Waterfall model is plan driven. The complete project is planned before it is executed. Using Critical Path Method (CPM) the project schedule is drawn. When project execution starts, the project is tracked using tools like Gantt chart. Of all the tasks on the project, the critical tasks must be tracked carefully. If any of the critical tasks get delayed, the project will be delayed. To ensure any critical task does not get delayed, an idle time period can be added after each critical task. If any of these tasks get delayed then the idle time can provide a buffer and so the project will not be delayed. This idle time period is known as a slack.

Chapter 11: software project execution and conflict management Software project execution & conflict management in Waterfall projects

Chapter 11: software project execution and conflict management Software project execution & conflict management in Waterfall projects The other measure to track software projects having Waterfall model is to have milestones placed in project schedule. When we travel on a road, the milestones on the side of road provide information as to how much we have traveled and how much more we need to travel. Milestones on a project do exactly the same thing. When we reach to a milestone on a project, we known how much project work we have completed and how much more project work needs to be completed. Milestones should never be placed on non critical tasks. Even if these tasks get delayed, it will not result in project delays. So placing milestones on non critical tasks are useless. Milestones should always be placed on critical tasks. So if any delays occur on these tasks, the project team knows that project has slipped and thus can take appropriate measures to ensure the project will not get delayed further.

Chapter 11: software project execution and conflict management Software project execution & conflict management in Waterfall projects

Chapter 11: software project execution and conflict management Software project execution & conflict management in Waterfall projects The project manager on all Waterfall projects is responsible for everything. If any conflict arise on the project then the project manager should take appropriate measures. Project team members may have their own ambitions. These ambitions may result in conflicts on the project. The best way to deal with such conflicts is to have a self appraisal system. The project team member should provide inputs as to where he/she stands and the project manager may provide inputs as to what is the reality. The project team member may thus realize the mistake and the conflict can be sorted out.

Chapter 11: software project execution and conflict management Software project execution & conflict management in Agile projects Agile software engineering methodology was developed to avoid risks which were part of plan driven software engineering methodology. The customer sits on project site to ensure there are no communication gaps. Software is developed incrementally over small iterations (Sprints) to ensure that the software product can be taken to the market as early as possible. Still some problems may be encountered on Agile projects. One good way to measure Sprint progress is to use burn-down charts. A burn-down chart depicts how many story points are implemented on the Sprint and how many story points still need to be implemented at a specific time when a Sprint execution is happening. A burn-down chart depicts if all story points will be implemented in the Sprint or not. A burn-down chart also depicts speed (velocity) of the project team.

Chapter 11: software project execution and conflict management Software project execution & conflict management in Agile projects

Chapter 11: software project execution and conflict management Software project execution & conflict management in Agile projects One risk associated with Agile projects is that the project team is self managed. Each team member will assign project work himself/herself and will create plan for the project work which he/she will do in the Sprint. If project team members are not confident of the project work they will be doing then it may pose serious risk. The other challenge for self managed project team is that in the beginning of the project, productivity of a team member is not known. So many delays in a Sprint can occur.

Chapter 11: software project execution and conflict management Software project execution & conflict management in Agile projects If a conflict occurs on an Agile project then it is first tried to resolved by the project team itself. Since there are no project managers on Agile projects; serious conflicts are handled by a project coach. A project coach works on an Agile project part time. Whenever some serious conflict occurs on the project, the project coach analyzes the conflict and finds a solution so that the conflict is resolved. There are 5 levels of conflict defined for Agile projects. Level 1 conflict is the mildest conflict. At this level , the project team can itself resolve the conflict. In case, the conflict could not be resolved then it will move to become Level 2 conflict. At level 5, a conflict is severest. A Level 5 conflict, can not be resolved even by a project coach. So any conflict should be resolved when it is at Level 4.