Contract Monitoring and Control System

CMCS was a system I wrote back in 1984. It was used and maintained for some six years to manage MoD contracts within a shipbuilding accounting framework. It wasn't perfect, and nor is my memory, but I think it is a worthwhile starting point for discussing the required structure of our project monitoring system.

Data Design

Project Table

project code
project status	Open or Closed
project manager
project desc
customer
department

Stage Table

project code

stage code

stage description

material budget

labour budget

material spend to date

labour spend to date

material estimate to complete

labour estimate to complete

Cardinal Date Table

Project Code

CDP Code

Target date

Estimate date

Actual date

Transaction History

project code

stage code

transaction date

transaction code

transaction details

Technical Description

The system was implemented on a DEC Vax, using RMS and BASIC. The Project, Stage and Cardinal Date files were indexed, the transaction history file was a sequential file.

It was possible to rebuild the indexed files from the transaction history file, as every action within the system had a transaction code:

Modify Project

Modify Stage

Modify CDP

Book time to a stage

Book materials to a stage

Modify time estimate

Modify material estimate

The System in Use

There was authorisation such that only the project manager could create projects, only the clerks could book costs etc.

The Project manager would create a new project, which would automatically gain the standard set of stages. He could then add or delete specific stages. the project manager could also control the status of a project, so that costs could not be booked to it if the project was closed.

Evaluation

The system was a relative success, it enabled the divisional manager to gain a reasonable picture of all projects. The problems with the system stemmed mostly from the fact that its outputs had to tally with those of the central system, run on a completely different machine. Initially the same time cards were enetered in CMCS and then sent off to the central DP department to be re-keyed. It soon became someones full time job to ensure that there were no discrepancies between the two systems.

Late on in the systems life it was used to manage a new type of project: a 350,000,000 project. This project needed to be composed of sub projects. Whilst the system struggled on, it began to fail at around this point.

The problems were not so much with the computer system as with the situation it was intended to automate. The notion of a 'stage' comes initially from shipbuilding, and did not necessarily fit very well with the type of projects SPD (Vosper Thornycroft, Support Project Division) actually had. Consequently some project managers divided up the projects in terms of resource types: all typist hours would be stage 02 and others booked all hours during the analysis stage of a project to stage 02.

The system was not developed using relational DB technology, so initially all queries were actually hand crafted reports, so the old IT resource problem hit rather hard.

The use of total fields within the stage records was an expedient, as these figures could have been calculated on the fly.

Recommendation

As DB technologies have moved on we can afford to be more pureist in our data design. We might as well calculate totals from their constituent transactions.

The distinction between a project and a stage became very blurred when we wished to report upon a block of projects as a single project.

The main consideration is that a booking transaction should only be reported once.

Our situation is reather different. Whilst the view that our customers wish to see is similar to the view required by the SPD Project Manager, the view that we, PanEris members, require is different. We need to be able to see reports of bookings by one individual across different customers. The data structure will support this, but we need to add additional reports.

Document Dated 14/11/97 TPP