Issue: Vol. 14, No. 5, September/October 1997 | PDF

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.

Project Home Page Contents

  • Project Tracking
    • Percent of Schedule Used (Actual)
    • Percent of Resources Used (Actual & Planned)
    • Percent of Defects Found (Actual & Planned)
    • Graphs of Actual vs. Planned Resources & Defects
    • Current Task List
    • Current Defect List
    • Top 10 Risks List
    • Anonymous Feedback Bulletin Board
  • Project 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 Software
    • Deployment Document or Cutover Handbook
    • Release Checklist

Editor: Steve McConnell, Construx Software  |  More articles