PROJECT LOGS

Introduction

The concept of the project log is simple.
This means you have the incentive to find the time to maintain it.
It is powerful enough to be of real value.
So what is a project log ?
Basically it is a set of five overlapping structured documents called logs.
The logs contain similiar types of information but for different reasons.
The information redundancy helps to ensure that you avoid missing anything important.

Design Log

The Design Log provides you with a method of recording design decisions and all the supporting arguments for and against each decision.
Whenever you have one of those eureka moments, a quick browse through the Design Log will remind you that you tried to implement the
idea six months ago and that you found it was not feasible.
The Design Log should contain:

Descriptions of each design issue to be resolved.

All design issues should be documented including the simple ones which do not appear to have any alternative solution.

A list of alternative designs.

Arguments for and against each design.

A detailed description of the chosen design.

It is often the case with Rapid Application Development that this stage is not documented
and if it is, it does not always keep pace with the RAD changes.

Change Log

The Change Log records code changes in enough detail to enable you to undo or recreate each change
The Change Log should contain:
The reason for the change.
A description of the change to each function or method.
If necessary this should include a line-by-line description of the change or the actual before and after code.
The status of the change.
Software Management Systems are often used as a substitute for this but often do not provide
high level details that the Change Log should provide
Is the Change Log cross referenced to the System Log (Installations And Rollouts).

Defect Log

The Defect Log is where all user and developer reported defects are recorded.
The Defects Log should contain:

Details of who reported the defect and when.

A description of the defect including the exact text of any messages produced.

Version Of The Product With The Defect.

What you have done or will do to fix the defect.

The status of the defect.

Can sometimes expand to a catch all in particular encompassing Change and Ideas.
During release cycles that are inperfect there is an enormous temptation to overload the Defect Log
Try to avoid that temptation

Ideas Log

The Ideas Log is where you record random thoughts and ideas about the project as they occur.
The intention is to capture ideas before they fade from memory, not to perform detailed analysis.
To keep things straight forward the Ideas Log should be simple text.
The Ideas Log should contain:

Ideas for new features.

Problems that need to be researched.

Alternatives to the chosen implementation method.

Ideas often get promoted to Changes so ensure there is a cross reference.

Systems Log

The Systems Log defines and describes external factors relating to the project.
Interaction with stakeholders should also be recorded here.
The System Log should contain:

Functional Requirement Changes.

Large changes will probably refer to other documents which are driving the development
but it is particularly important to track the small verbal changes that often occur.

Environmental Changes.

This should include any change such as hardware, operating system, database and so on
that can have an impact on the project.

Installations And Rollouts.

Every time the product is installed or sent to a user during the development process it should be recorded.
Clearly this means that within Installations And Rollouts there should be a list of items
that come from Change, Defects and Ideas for cross reference to explain why a new installation has taken place.

The Logs are really a tool of delegation.
All that is really happening is the scope of the project is delegated to recording information into logs.
This is a useful tool when it is not appropriate to interupt the actual detail of the current task.