Project Monitoring


"Visibility" is the ability to determine a project's true status.  The opposite is a "black hole."

Typically visibility is good at the start when there is lots of customer interaction and several important public documents are created.  Frequently a project goes into a black hole during implementation and integration.

Visibility is important to stakeholders.  They want to make sure they aren't funding a failing project.

A project behind schedule by a known amount is often preferred to a project that is on schedule but without visibility.

Progress Bar phenomenon - people will be patient if they know how long the wait is.
Paint Can Analogy - Miniature milestones with binary quality gates facilitate visibility.


Without miniature milestones a project can degenerate to a "partial implementations" approach, where partially implemented units are allowed into the build.  Other people work off these partial units, adding more partial units.  Frequent integration problems require rework and this can cycle around endlessly. 

The solution is to follow the process shown in the project plan.  Develop a vertical prototype if you need to learn about the technology. Then do a complete high level and detailed design with javadocs and pseudocode down to the module level.  Schedule ALL development tasks, for every task > 15 minutes.  Put all tasks in the action item tracking system.

Change Control

Change control supports visibility by minimizing partial implementations trap.

Each work product goes through an initial development phase without change control, but the goal is to implement the entire unit (not just part of it).  The work product is submitted for review.  It can't pass review if it is incomplete or doesn't meet the QA criteria.   Once approved it is "baselined" and any subsequent changes must follow an explicit process.

Change control procedures vary from single author to change board.  Choose appropriately.

One goal of change control is to assure consistency between all work products. The SRS, designs, System Tests, and completed software should all match.

Change control manager should developer mechanisms to determine non-compliance with change procedures.