Status and health reporting of a project are paramount at all times, earlier the better in order to ascertain that a project is on track.
When stakeholders have full visibility of the efforts on a project and the results of that project then they are more able to have confidence that the project is on track.
The converse of this is a project that is not healthy but organizational pressures cause overly optimistic status reporting which masks the issues that need to be addressed. Management should look for transparency and accept that all may not be well but ensure that care is taken to address the issue at hand. An unrealistic deadline cannot be able more realistic by throwing additional resources at it.
When project health is not as it should be it’s important to identify the resources that are effective, and seek to identify those that have a negative impact on productivity and address this issue accordingly.
The full suite of tools in Visual Studio Team System when used properly can ease the burden of status reporting and provide transparency as to the health of the project. The Scrum for Team System can provide several useful metrics which can help ascertain the health of the project.
First and foremost the sprint burn down chart should be used as an early warning indicator that productivity is not as it should be. There are 2 reasons for a flat lining burn down chart. No status from developers or no developer progress. Either of these when it happens is easily address.
The build health reports can provide status as to the quality of the software being produced. Lack of good builds, coupled with poor unit test results should raise alarm bells as to the quality of the software. Stakeholders should expect to see a good amount of early testing and for this to continue as the project develops. These tests should be able to provide assurance as changes are made to the software throughout its development.
An additional report that can be useful is the code churn report. This describes to the view the amount of lines of code that have been changed in the time period specified. If on a larger project this does not tail of it’s reasonable to assume that there are large amounts of new development going on late in the day. This means that large portions of the solution have not either been written or is in a large state of flux which is not good late in the day as it would suggest that defect counts aren’t going to tail off.
Transparency of all these aspects should allow key decision makers to make early decisions around scope or delivery dates which will allow expectations to be managed and avoid situations where teams not set up for success.
Posts
