Project Management Issues
This section summarizes the project management issues for this iteration. First, we need to check the schedule against reality, and then we update the list of defects before we implement the new features.
6.4.1 Schedule Issues
Unfortunately, one of the developers has decided to leave the project to take on a new assignment. This is certainly bad news, and the project schedule is in serious danger. We discuss the possible options for reacting to this change. Table 6.4 lists some possible options along with some of their advantages and disadvantages.
|
Option |
Advantage |
Disadvantage |
|---|---|---|
|
Hire an additional, new developer. |
The work load for each developer on the project stays the same. The schedule might not need to change. |
Mentoring a new developer takes away valuable time from the senior developers. Especially in complex projects, the mentoring can take a lot of time. Therefore, the schedule might still slip. |
|
Let the schedule slip |
If the project is not time-critical, this option allows us to deliver all the functionality without losing time to interview, hire, and mentor a new developer. In addition, the defined risk buffers can be used to make up for some of the time. |
The product will be released late. |
|
Reduce the scope of the project |
Features that are not highly important to the customer can be rescheduled for a future release, and the product is delivered on time. |
Not all features are delivered..Therefore, the schedule of the final release might slip or some functionality might not be delivered. |
The following key points are identified to help us decide on a recovery plan:
- The project is already in the construction phase.
- Domain knowledge is very important.
- Risk buffers were defined to help recover in situations like this.
- The project is time-critical to the customer in order to open the new online market.
Based on this information and discussions with the project team and the customer, the decision is made to proceed with the current project team; the schedule will slip at most by one week if it becomes necessary to use all the risk buffers. In addition, project management agrees to compensate the developers for any overtime that might be necessary to deliver the product on time. Figure 6.6 shows the resulting new project schedule.
Figure 6.6. New Project Schedule
So far, we haven't had to cut any of the features to finish the project on time. The way we resolved the schedule problems due to this unforeseen circumstancein close collaboration between the project team and the customeris usually a successful recovery method. This approach depends heavily on the trust and open communication of all involved parties. The project team must commit to the new schedule, management must honor the need for the developers to work overtime to achieve the tough deadlines, and the customer must be assured that the new schedule is realistic and achievable.
Only if this trusting relationship has been built will a successful recovery be possible. In many projects this does not happen, and the resulting risks are not discussed with the customer early enough. Instead, at the very end of the project the delay becomes obvious, and the only recovery methods at that point are to slip the schedule or cut features and quality (reduce testing). Resorting to less or no testing is often taken as a resolution for schedule problems. In this project, though, quality is of high importance, and we did not consider it an option to take away time from testing to make the deadlines. (In the long run it is generally not a good policy to cut quality in order to make the schedule, even though it happens very often in projects and seems to help in the short term.)
6.4.2 Reported Defects
After the first, unofficial release of the project was delivered to the customer, some defects were reported. The defects were reviewed, assigned to developers, and scheduled for fixing in a specific release. None of the defects requires major rework. Therefore, this work is not reflected in the schedule.
For defects that require rework of more than half a day, the time it takes to fix them should be reflected in the schedule. Smaller rework packages, such as the ones described in this chapter, were already calculated in the original development time as part of the added judge time. Therefore, no extra schedule update is necessary for them. Figure 6.7 shows the new defect tracking sheet.
Figure 6.7. New Defect Tracking Sheet
Now that the planning is complete, it is time to implement the required features.