During the development of the preceding iteration, members of the project team brought up a new project management issue. During discussions in the regularly scheduled project meetings, some team members said that they did not really know the actual status of the project. In addition, most of the project team members thought that not enough focus was given to monitoring the identified risk items and their mitigations.
Both issues are valid complaints and need to be addressed. Even though both items were monitored by project management, it seems that their tracking is not visible enough to the project team. Therefore, a special meeting is scheduled to discuss the issue and to find an efficient solution that resolves these shortcomings.
It is crucial for the project management to listen to the project team if a lack of communication has been identified. If the project team members do not know what the status of the project is at any given time, how can they be held responsible for finishing the project on time? In addition, for the motivation of the individuals it is important to communicate the overall tasks of the project, its current status, and upcoming work packages. If the project team is not kept in this loop, sooner or later the team will suffer. It is also important to assign tasks for which the developers are held responsible. In addition, it should be clear to all the team members how their individual contributions will help the project to succeed.
It is also important for the team members to have the perspective of knowing about upcoming tasks or projects. In many projects, the communication does not include updating the project team on tasks that might or will come up. In many of these projects, we have found motivational problems simply because team members did not know what their next task would be (or whether there would be one at all) and how their contribution fit into the overall project.
For all these reasons, we think that open and honest professional communication must flow from the top down, and the feedback must flow bottom-up, for a project to succeed. If we look at a concrete project, the truth of this observation becomes obvious. The project management has the information about new or existing projects, customer problems, and so on. This information must be communicated to the developers (perhaps the information can be filtered to take some of the pressure off the project team) so that they can do their tasks and stay motivated. By the same token, to keep the project on track or to improve the process, project management is dependent on feedback from the project team in order to make adjustments if roadblocks are identified.
8.4.1 Improving Project Visibility
The two issues that were brought up by the development team deal with visibility. Even though the project plan is available to everyone on the team, the developers still feel that they do not really know what the current status of the project is. In addition, the status of the project regarding the identified risks is not clear to the team members. At the special meeting called to resolve these issues, they are discussed and ideas are collected on how to improve the situation. After a lively discussion, an agreement is achieved on ways to make the project and risk management more visible.
All requirement keys are written on 3 x 5 index cards. The cards are divided into sections listing the requirement key, the responsible developer's name, the due date, and the completion date. An example is shown in Figure 8.4.
Figure 8.4. Requirements Index Card
These index cards are then posted on a wall that everyone passes by many times a day.
In addition, the wall holds a project plan with the iteration and project deadlines clearly visible. The requirements index cards are pinned to the plan. A developer who has finished a task updates the card by adding the completion date. At the end of an iteration, all index cards that are posted within the timeframe of the iteration are finished and show a completion date. For every iteration that is completed on time, project management rewards the team with a catered lunch. Figure 8.5 shows an example of the posted project plan.
Figure 8.5. Project Plan Showing the Current Status
Posting the project plan makes the project's current status easily visible to the developers, and it also communicates the upcoming requirements. The cards listing the requirements not yet assigned show the team the tasks that remain.
Now we turn our attention to making risk management more visible to the developers. To solve this problem, the development team and project management decided to post a risk management table next to the project plan. This table uses index cards to show each risk, along with its status and mitigation. The green section is used to post risk items that have been monitored. Any risk items that are likely to occur are moved to the yellow state, indicating the need for close monitoring and special attention. If an event identified as a risk is actually coming true, the item is moved to the red status section, which means that immediate action is necessary. Most likely, one of the mitigations is executed, and the risk item will revert to yellow or green status. Figure 8.6 shows a sample risk table.
Figure 8.6. Risk Table
The project team feels that these changes provide enough visibility of the deadlines and the assigned and upcoming tasks. In addition, this solution provides a clear picture of the responsibilities for each task. It also gives the developers an incentive to complete a task: signing it off on the project plan. Furthermore, this approach encourages developers to help each other if it becomes obvious that a task will otherwise be delayed.