IEEE Software, Vol. 14, No. 5, September/October 1997
Tool Support for Project Tracking
Once youve planned a project, you track it to make sure that
its following the planthat its meeting its schedule, cost, and quality
targets. Another word for tracking is "visibility" insight into the
projects progress and status.
Effective project tracking is hard. Capers Jones reports that
"software progress monitoring is so poor that several well-known software disasters
were not anticipated until the very day of expected deployment" ("Patterns of
Large Software Systems: Failure and Success," IEEE Software, March 1995).
After assessing 59 sites between 1987 and 1993, the Software Engineering Institute found
that 75 percent of the sites needed to improve their project tracking and oversight (David
H. Kitson and Stephen Masters. "An Analysis of SEI Software Process Assessment
Results, 1987-1991," Proceedings of the Fifteenth International Conference on
Software Engineering, IEEE Computer Society Press, 1993).
Tracking is a fundamental software management activity. If you
dont track a project, you cant manage it. You have no way of knowing whether
your plans are being carried out or of monitoring risks to your project. Effective
tracking enables you to detect cost, quality, and schedule problems early, while
theres still time to do something about them. If a project isnt tracked, it
cant be controlled. And if it isnt being controlled, its out of control.
The capabilities of modern software tools are coalescing in exciting
ways that make effective project tracking easier than it has been in the past.
Keeping Your Stories Straight
Version control isnt just for source code anymore. In addition to
providing for archival and retrieval of multiple versions of program source code,
networked version control software can help improve visibility and accessibility of other
software project work products. Most version control systems will archive anything that
can be stored in electronic formdocuments, project plans, spreadsheets, design
diagrams, source code, test cases, and so on. Once these work products have been placed
under networked version control, they become publicly available at all times to anyone who
has permission to access the version control system. Any person who needs to examine the
project plans, requirements, designs, coding standards, user interface prototype, or other
work products can retrieve those work products from the version control system. Getting a
current copy of a document does not depend on being able to find the person who
"owns" that document.
Although this might seem to be a minor benefit, on many projects it can
be difficult to get a current copy of the requirements, for example, simply because the
person in charge of the requirements document is on vacation! Few software personnel who
have worked on projects that make materials available through the projects version
control system ever want to work again on projects that dont.
Home Sweet Home Pages. The
core indicators of a projects cost, quality, and schedule status should be made
visible to the entire project team. One way to achieve this objective is to create a
project intranet home page that contains links to general project information including
project planning and tracking information, technical work products, and project
deliverables. Table 1 lists the contents that such a home page could have. A project team
can also expose a similar web page to its clients, though it would typically not want to
allow its client access to all the technically detailed and potentially sensitive
information contained within the home page the project team uses.
When both version control software and a project intranet home page are
used, current status information is only a mouse click away. Code can be embedded in the
project home page to retrieve the latest version of each plan, graph, document, or other
work product automatically. Alternatively, some version control systems can be configured
to post the most recent version of each file to a specified network directory, including
the directory where the home page files reside.
By making these materials available on a web site, project
stakeholderspossibly including upper managers and customerscan easily access
current information about the project without knowing how to use the projects
version control system and without needing to attend a formal status review. Making these
materials available on demand eliminates a significant source of friction that some
projects experiencethe friction caused by the projects sponsors not being able
to obtain timely information about the projects progress.
Are Your Risks Defective? An
effective means of managing risk on a software project is to create a list of the top 10
risks to the project and then review and update that list twice a month or so. This task
can be made easier by entering the risks into the projects defect tracking system,
separately from the projects defects. Defect tracking systems will typically allow
risks to be marked open or closed. They can be assigned to specific project team members
for resolution. They can be prioritized. You can print out lists of risks by priority, by
the amount of time theyve been open, and by person responsible. You can track the
steps taken to resolve a risk, who took the step, and so on. Used in this way, a defect
tracking system can take some of the tedium out of maintaining the risks list.
Who Was That Masked Man? Reporting
good news project-wide and up the management chain seldom creates problems for the
reporter, but reporting bad news can. A project should establish an anonymous problem
reporting and feedback channel that project members can use to report status and risk
information up the management chain. If developers are turning their code over to testing
later than scheduled, a concerned tester can report that. If testers are releasing builds
to documentation that have not been well tested, a concerned technical writer can report
that. If a project manager is exaggerating the projects progress in reports to upper
management, a concerned developer can report that.
One way to support an anonymous reporting channel is to set up an
electronic project bulletin board to which people can post comments anonymously. This
bulletin board should be visible to other project team members and upper
managementpreferably, it should be directly accessible from the projects home
Many Hands Make Light Work. Automated
tools substantially reduce the effort required to track the status of each detailed task.
The list of tasks should be contained in an electronic planning tool such as project
management software or a spreadsheet. It should be stored in the projects version
control system and made accessible via the projects intranet home page, which will
make it publicly available to the whole project team. When a developer or tester completes
a task, he or she should check the task list out from version control, update it to show
that the task is complete, and check it back in.
Streamlined collection of tracking information is one way in which
making management materials publicly available provides obvious benefit to a project. The
project manager shouldnt be burdened with maintaining a detailed task list. More
important, the project manager shouldnt be allowed to become the bottleneck through
which all status information must pass before it can be used by the rest of the project
team and upper management.
Manual Labor. Although current
tools make collecting and distributing project-tracking information easier than ever, some
small amount of manual work is still required. About once a week, the project manager or
the managers assistant should review the projects progress. This review should
include several activities:
- Collecting summary data from the project planning and defect tracking
- Comparing actual tasks completed to the plan
- Comparing actual defects reported to predicted defects
- Comparing actual effort to planned effort
- Reviewing and updating the Top 10 Risks list
- Reviewing and acting upon any feedback obtained through the anonymous
feedback reporting channel
- Updating any information on the project home page that needs to be
This weekly data collection and analysis also lays the foundation for
maintaining a Software Project Log throughout the project and for creating a Software
Project History at the end of the project.
Putting the Pieces Together
Different project stakeholders are sensitive to different issues. When
you expose task status, current risks, current defects, and anonymous problem reports on a
project home page that everyone including testers, developers, project managers, and upper
management can use, you go a long way toward ensuring that project management and upper
management will learn about emerging problems early and have visibility to the information
needed to address them effectively.
Table 1: Project Home Page Contents
Percent of Schedule Used (Actual)
Percent of Resources Used (Actual and Planned)
Percent of Defects Found (Actual and Planned)
Graphs of actual vs. planned resources and defects
Current Task List
Current Defect List
Top 10 Risks List
Anonymous Feedback Bulletin Board
Software Development Plan
Quality Assurance Plan
Detailed Software Construction Plans
Technical Work Products
Top-Level Design Document
Detailed Design Documents
Project Coding Standard
Current version of the software
Deployment Document or Cutover Handbook
Editor: Steve McConnell, Construx Software, 11820 Northup
#E200, Bellevue, WA 98005.
E-mail: email@example.com - WWW: http://www.construx.com/stevemcc/