Chapter 18 - Project Review¶

Part 2¶

Interaction of the elements¶

Effective project controlling (time, cost and quality) is only possible on the basis of a functioning configuration and document management as well as change control. These three project management elements only deliver their full impact if they are implemented in conjunction with one another.

Configuration management, document management and change control are related and the contract administration builds the framework.

Example

This interaction can be demonstrated using the example of combustion engine development.

Since this is a complex process, different car manufacturers install identical engines, developed by one manufacturer, in various car bodies. This enables them to avoid the substantial development costs that they would otherwise have incurred. However, the mountings and connections for each of the different models are specifically designed for the various vehicle bodies. The car manufacturers must therefore initially exchange and coordinate data (e.g. engine compartment dimensions) and facts (e.g. shape of connections) in the form of drawings and diagrams. The coordination of this process is one aspect of configuration management.

Documents:
Either in paper or electronic format, are generally used as the medium for making these facts and figures available. When a certain volume of project documents exists, it is necessary to administer them, which is where document management comes in.

Changes:
Are inevitable over the course of a project, for example when interim results are viewed as unsatisfactory and therefore rejected. In an engine development project, this would be the case if the supply from the fuel tank could not be connected to the fuel pump on the engine block. The dimensions and shapes would have to be changed to ensure this interface. This, in turn, necessitates document changes. Change control provides the framework of procedures used to make these changes.

Be careful, here is a common pitfall!

In practice, the following terms are commonly used:

Configuration = as designed
Change = how changed
Documentation = as built

The elements of configuration, change and documentation are essential for project management if the project staff is working at different times and in different locations.

Configuration management¶

A configuration is defined as the

functions and physical features of a product or service as described in the supporting documents and implemented in the product,
detailed and complete compilation and documentation of project results and their systematic updating when project changes are implemented.

Configuration management is a management discipline that is applied throughout the entire lifecycle of a product to ensure transparency and guarantee that it incorporates the agreed functional and physical features. Configuration management is only necessary if information is changed in many different documents, so in some projects it's not necessary.

The main objective of configuration management is to document the current configuration of a product, as well as the extent to which it satisfies physical and functional requirements and to ensure absolute transparency in these respects. Documentation transparency can be described as the ability to provide a satisfactory answer to any question within a reasonable time. At all phases of a project, all members of a project team should have access to information about the project deliverable and its creation process ("what" question) so they can check whether the individual configurations can be physically connected to their interfaces. Configuration management also ensures that each project team member uses the correct documentation in all phases of the product's lifecycle.

The configuration management process comprises the following four activities:

Configuration identification

Definition of the product structure and selection of configuration units, which is also called the reference configuration.
Documentation of the physical and functional characteristics of configuration elements in clearly identified configuration documents.
Establishment and use of rules for numbering configuration elements and sub-elements, as well as for structuring documents, interfaces, changes and approvals during and after realisation (e.g. parts-list structures for the production team or document identification systems).
Establishment of reference configurations based on formal agreements which, together with the approved changes, constitute the latest version of the agreed and therefore valid configuration.

Configuration control

Documentation of the cause or reason for changes (e.g. customer request or design defect that had not been previously identified).
Assessment of the impact of changes (e.g. with/without consequential changes).
Approval or rejection of changes (with reasons, e.g. additional benefits or costs of the consequential changes are higher than the projected benefit).
Processing of special approvals before or after implementation (e.g. additional services or features that were only identified as necessary after the first tests were carried out).

Configuration accounting

Configuration accounting ensures the traceability of individual changes.

Configuration auditing

There are two types of configuration audit:

Function-related configuration audit:
Formal audit of a configuration unit to ascertain whether it satisfies the performance and functional characteristics specified in the configuration documents (e.g. acceptance certificate in respect of work performed)
Physical configuration audit:
Formal audit of the as-built configuration of an element to ascertain whether it corresponds to the information provided in the configuration documents (e.g. design drawings with the status "as built")

Document management¶

Documentation is defined as the creation, identification, registration, condensing, editing, updating, distribution, archiving and destruction of data (formatted information) and facts (unformatted information), irrespective of the type of information carrier used.

Document management makes it possible, within reasonable time and effort, to furnish all documents relating to a specific issue. However, the document management team is not responsible for the content of the documents (completeness and correctness). Documents are archive-worthy records that are stored in all kinds of information carriers.

An archive-worthy document

describes future obligations (e.g. contract),
defines work processes (e.g. job orders),
contains interim results (e.g. status report with approvals) and
serves as verification for results achieved (e.g. completion certificate).

The document author's signature makes the content binding. In some cases, the recipient is required to sign the document as confirmation of agreement.

Change control¶

Change control is necessary for the monitoring and management of changes that have to be

identified,
described,
classified,
assessed,
approved,
implemented and
verified.

Change control is an essential aspect of all projects. If data and facts are only contained in one or two documents, an update of one or both of the documents suffices to recognize that a change has been made.

Changes have the following characteristics:

They are deviations from something that was previously established (reference configuration).
They are triggered by an incident (e.g. defect).
They have a purpose (e.g. to improve utility).
They relate to the content of project objectives (e.g. additional work).
They relate to procedural objectives (e.g. budget cut).
They are necessary owing to
- one's own fault (e.g. incorrect calculation),
- third-party fault (e.g. delayed completion by a supplier),
- customer request (e.g. for enhanced software performance),
- statutory requirements (e.g. new safety legislation), or
- new technical developments (e.g. changeover to another operating system by the software provider during an IT project).
They necessitate regulated process structures for traceability purposes.
They generally cause additional costs that cannot be budgeted for in advance.

Tasks

Change control must

identify changes (Why is the change being made?),
describe the content (What?) and process (How?) of changes,
classify changes (What consequential changes will be necessary as a result of this change?),
assess changes (What benefits will the change provide? How can they be measured?),
approve changes (Which hierarchy level approves which changes?),
implement changes (Which new deadline/budget requirements trigger the change?) and
verify changes (Has the projected benefit occurred?).

Impact

Changes and change control often have drastic effects on project execution. If the requested change is associated with additional work, it may be necessary to create a new work package for the implementation of the change and to redefine interim objectives, costs and deadlines. This can result in changes to the contractually-agreed scope of delivery and performance.

It is also possible that a change may influence work packages resulting in a claim that generates additional costs for the customer.

Changes almost always necessitate a fundamental reassessment of costs, deadlines and risks. They therefore influence existing contractual agreements. Systematic claim management is necessary to control the financial impact of changes. Since this is generally associated with considerable time and effort, the project management team should not underestimate the importance of claim management. Rather, it should be treated as an independent activity in a work package or an independent function in a project management structure.

Project review

The project review is a method of analysing the status of a project in terms of performance, costs and deadline adherence at the time of the review. In the review, the project results - negative as well as positive ones - are analysed, project progress is evaluated and any problems are discussed. This variance analysis is performed on the basis of project requirements, project plans and project records.

The project review pinpoints non-conformities and identifies possible control measures.

Project reviews are implemented at fixed dates. Depending on the project type, the reviews can take place on specific weekdays (= jour fixe) or once a month. Reviews should also be implemented at transitions from one phase to another. The project review at the end of the project is carried out to provide rules of thumb for future projects.

How the story ends…¶

"All right, the most important thing from this lesson which I'll take home, is that changes are fine as long as change control is done properly. I used to think that changes were nothing more than mistakes", says John. Dr. Rogers nods: "Yes, many people think this way. But changes are common. If everybody is fine with this or that adaption, you can carry it out - but don't forget to document!"