One of the things about being a freelance consultant is that you often get to see projects when they are at their worst ebb. After all, one is seldom called in to solve non-problems.

The basic pattern of a contract goes like this.

1. Work out what is going on.
2. Work out how it got that way.
3. Figure out a way to improve the situation
4. Set about actually improving the situation.

The first two steps in this process are what I call ‘forensic configuration management’.

I call it forensic because, like medical forensics, one is often working with clues, partial (sometimes misleading) information as to what is going on and how it got the way it is.

A detective story starts, usually, with a crime. Our detective story starts with a problem. A project is having difficulty building and releasing its product accurately and in a timely fashion. This may be less dramatic than a murder or otherwise strange death, but it is a common situation for projects.

Like any good crime story we can interview eye witnesses (members of the project team) and ask them what happened. Also like any good crime story these eye witnesses will offer various accounts of what happened. Each story will seem, to the witness, to be the absolute truth. Unfortunately, as with eye witnesses to a crime, our eye witnesses are not wholly reliable. Eye witness testimony is notoriously unreliable and coloured by the witness’s own background and agenda.

Fortunately, our ‘crime’ has, like any good crime, left a trail of evidence. Evidence that will, when followed and interpreted, reveal the whether there is a criminal to be held to account, or that our crime is nothing but the result of circumstance, an accident. Our task is to gather evidence and interpret it to solve the ‘crime’.

The first thing that the police do at a crime scene is to seal it off to preserve the evidence. We seldom have the luxury of sealing of a project but there are several steps that we can take to help us to figure out what has been happening on the project.

• Read all the project’s process documentation, no matter how informal.
• Find any records, such as change requests and defect reports, and try to preserve them.
• Find the documentation and code repositories.
• Find and isolate the machine on which the project builds product from source.

Documentation

Reading documentation is not so much about learning what is done but more about learning what was supposed to be done. Often, while the formal documentation describes what should be done, the more informal documentation reflects what is actually done. For example, many projects maintain informal wiki’s and much of the process the project team uses may be documented there more accurately than in the official documentation.

If there are significant differences between the official documentation and that recorded more informally ask why. Is there a justification for the change? If not then this may be the cause of problems, in particular deviation from a common standard may cause problems with interfaces between the project and other parts of the organisation.

The documentation (formal and informal) should also be compared with reality. What does the project really do? Establishing actual working practices can be a challenge, especially if you are perceived as an outsider by the project team.

Some teams see any comment of attempt to verify practice conforms with documented process, as intrusive. This can cause the team to defend themselves, which in turn makes it even more difficult to establish what really is happening. When investigating process execution be careful to ask questions and not to point out deficiencies at this time.

Records

Records are the lifeblood of a project. They are also seen as bureaucracy, so they are often neglected. The process document should set out which records are used and how they are managed.

Poorly collected, stored or controlled records are a sign of a dysfunctional process.

Repositories

Most projects will have one or more repositories in which the project’s materials are stored. It is a rare project these days that does not have a version control system in which the code is held. Documentation may also be held in a special repository or simply held in special directories on a shared file system.

Whatever the project uses, the repositories must be identified so that a baseline can be established. If a baseline already exists then audit it to ensure its integrity.

Looking through a project’s repositories can be very revealing. Are the repositories orderly or confused? Can you easily identify items that were changed in response to a specific change request? Is each change attributable to one user, if so, how easy is it to identify them from the repository?

A repository that is disorganised, has poor traceability, or does not clearly identify who made each change, is a good indicator that the project is running out of control.

Build System

Too commonly overlooked, the project’s build system is a essential to producing consistent product.

Any project that uses a developer’s machine to create products is playing with fire. Similarly a project that allows unrestricted access to a specific machine used for builds is opening itself for trouble.

The build machine should be a dedicated machine and it should be accessible by a limited group tasked with performing the official builds for the project.