Status reporting states where the project is in relation to the business goals, project plan, and implementation
schedule. The quality of the implemented functionality to date is also tracked but may not be required as a status
item, yet it might be very useful in decision making. There are different perspectives of status reporting in a
software development project: the internal and external perspectives, as detailed on the next sections.
Internal Perspective
This perspective is the development team's view of the project state. As the team moves through an iteration, weekly or
daily status meetings allow the team to identify the functionality implemented. This perspective provides the lowest
level of status reporting and tracking. The cumulative amount of implemented functionality provides a trend of project
performance. Visually representing a cumulative amount shows a development team where they are in relation to the total
amount of functionality needed implemented by the end of the project with the appropriate level of quality, that is, a
successful project to the development team.
Presenting this in a burndown chart quickly provides the team a view of their progress. Seeing the trend promotes
discussion among the development team to identify corrective action and gain commitment on the recommendations for
improving project performance. The following charts represent a project in the third iteration with an overall length
of eight iterations. Chart A depicts how much functionality has been implemented to date from the total functionality
that was to be implemented at the beginning of the project. Chart B adds a trend line to show that if the team
continues to perform at the continued rate they should be confident they will successfully complete their project and
implement all functionality, potentially earlier than the scheduled eight iterations. There was significant improvement
between iteration two and three. This improvement could mean either of two things: the most difficult and complex
functionality had been implemented by iteration 3 or the team took the action to make changes resulting in improved
project performance.
Chart A - Functionality implemented throughout the iterations
Chart B - Trend of functionality implemented throughout iterations
Chart C represents a project that appears in bad shape. However, appearances may prove deceiving. This could also be
representative of a project that expected to take at least four iterations to implement the most difficult, complex
functionality. In that case, iteration five would see a significant improvement. Or, this project may have attempted to
take corrective actions in the second iteration but either they were ineffective or additional roadblocks appeared.
The development team members need to share their progress and identify issues they are facing, resulting in a list that
is frequently reviewed to insure timely closure of individual issues. A growing list of action items with no
resolutions indicates an unhealthy project environment. If project teams do not make progress with the implementation
of functionality, it might imply projects destined to exceed budget and schedule. Decision makers need to be careful
not to jump to conclusions too soon. In the example, work performed in iteration 4 and beyond could be less complex.
That being the case, it would be expected that productivity would drastically increase in iteration 4. This level of
information should be reflected in the project plan.
Chart C - A project potentially in bad shape
External Perspective
This perspective provides business stakeholders (department heads, directors, etc.) outside of the project development
team with visibility into the state of the project. This visibility is necessary in order to gauge performance towards
the achievement of business goals and the achievement of planned payback schedule or Return on Investment (ROI). The
informational elements providing this external perspective of the state of the project are:
-
The cumulative amount of functionality that has been implemented.
-
The amount of functionality yet to be implemented.
-
The amount of budget that has been consumed.
-
The amount of schedule that has been consumed.
-
Key issues affecting project performance.
-
Recommendations for project improvement.
Providing management with a view into the amount of functionality implemented enables decision makers of the program or
portfolio with an understanding of project performance. From a business point of view, a successful project will:
-
Perform to plan.
-
Provide the requested business functionality.
-
Achieve the planned payback or ROI.
The need for this visibility provides decision makers with timely information necessary to either:
-
Allow the project to continue.
-
Help improve the state of the project through reduction in scope and its ramifications to the business goals.
-
Introduce a project-level change request to increase the budget and extend the schedule.
-
Cancel the project.
Presenting a visual representation of the budget consumed, for example, with a trend line over three iterations (burn
rate) quickly points out whether or not a project is healthy, as shown in Chart D. However, budget consumption by
itself needs to be viewed in light of the amount of functionality that has been implemented to date. Chart E represents
the display of both budget consumption and the amount of functionality implemented.
Chart D - Trend of budget consumed (burn rate) throughout the iterations
Chart E - Budget consumption and amount of functionality implemented
Charting the budget expenditures in this manner quickly informs the business stakeholders, without much dialog, that:
-
Budget is being consumed at a much faster rate than estimated
-
At the current rate of consumption, the originally allocated budget will not be sufficient to complete the
implementation of the remaining functionality
In addition to visual representations, key issues affecting the project - along with recommendations for improving the
state of the project - need to be presented.
Some organizations set aside special meetings with the business stakeholders for project managers to quickly present
project status. Providing visual representations reduces the need for excessive dialog, thus reducing the amount of
time required for the presentations.
Presenting status information in a dashboard significantly cuts down the amount of time anyone needs to devote to
status meetings with business stakeholders. These status meetings may only be necessary for projects that need to
address questions like:
-
What is the cause for exceeding the burn rate?
-
What is the cause for not developing the expected functionality according to plan?
-
Is the project creating too much risk for the business?
-
What are the plans for getting back on track?
-
How close to the original estimates will the project deliver?
-
What useful functionality can be delivered to the business if scope is reduced?
-
What payback will be received with scope reduction?
-
Will the business begin realizing the reduced payback sooner?
|