Best Practices
IEEE Software, Vol. 14, No. 5, September/October 1997
Tool Support for Project Tracking
Once you’ve planned a project, you track it to make sure that
it’s following the plan—that it’s meeting its schedule, cost, and quality
targets. Another word for tracking is "visibility"— insight into the
project’s 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
don’t track a project, you can’t 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
there’s still time to do something about them. If a project isn’t tracked, it
can’t be controlled. And if it isn’t being controlled, it’s 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 isn’t 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 form—documents, 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 project’s version
control system ever want to work again on projects that don’t.
Home Sweet Home Pages. The
core indicators of a project’s 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
stakeholders—possibly including upper managers and customers—can easily access
current information about the project without knowing how to use the project’s
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 experience—the friction caused by the project’s sponsors not being able
to obtain timely information about the project’s 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 project’s defect tracking system,
separately from the project’s 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 they’ve 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 project’s 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
management—preferably, it should be directly accessible from the project’s home
page.
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 project’s version
control system and made accessible via the project’s 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 shouldn’t be burdened with maintaining a detailed task list. More
important, the project manager shouldn’t 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 manager’s assistant should review the project’s progress. This review should
include several activities:
- Collecting summary data from the project planning and defect tracking
tools
- 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
updated manually
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
Project Tracking
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 BoardProject Planning
Software Development Plan
Quality Assurance Plan
Detailed Software Construction Plans
Technical Work Products
Requirements Specification
Top-Level Design Document
Detailed Design Documents
Project Coding Standard
Project Deliverables
Current version of the software
Deployment Document or Cutover Handbook
Release Checklist |
Editor: Steve McConnell, Construx Software, 11820 Northup
Way
#E200, Bellevue, WA 98005.
E-mail: steve.mcconnell@construx.com - WWW: http://www.construx.com/stevemcc/
