I’ve mentioned before that I like to keep an accurate project journal. Scratch that – I like to use the process of telling my project coordinator what to put into the journal as a way to organize my houghts and record the various threads of action as they unfold. This is all well and good while the project actively runs, but it does raise an important question. What do we do with the project journal when the project comes to an end?

Now, to some extent projects never really end. The work we spawn changes the environment, and those changes should in theory go on for quite some time. However, as a practical matter project teams eventually disband and the various responsible parties like to claim their victory laps. As an entity the project journal doesn’t contain much useful to the operational world; after all, it records the work required to make the change, not necessarily the change itself. It also contains inconvenient information for victory laps, as it shows the careful process of negotiation we went though and all of the seams in the “victory”.

I hold on to the project journal for a month or two after the postmortem analysis. If things seem to have died down, I’ll load it into the appropriate document management system. If, however, people come hunting for the team’s heads, I sit on it until it becomes useful for either the audit team or my management. Since the journal is not an official artifact, there’s rarely any reason to formally announce its presence.

Frankly, for all the time I spend on it, the journal’s information is time sensitive. It is extremely useful during the project, informative during the first few months after the project, and pretty much pointless afterwards. Well, not exactly pointless; let us say rather that it is not something people will get much value from except under very specific circumstances.

Those circumstances include both audits and when the organization decides to create a similar project or a project affecting the same product. Both of these circumstances have become increasingly familiar over the last few years as our industry changed.

Audits, whether we like them or not, have become a familiar part of the corporate IT landscape. The journal helps to refresh your memory about events which lead to the decisions you made, giving you a lot more ability to defend yourself and your team when someone comes to grill you six months and three projects later.

Although the audits seem important at the time, getting though them really amounts to just another chore on the project manager’s to-do list. Laying the groundwork for the next project manager, though, provides a priceless service. I know I generally land in a project with only a little information and often times no idea how we got into our current situation. If, though, the project manager before me kept a good journal I have some point of reference to start with. Even if I’m dealing with a whole new team, the politics and compromises, the decisions and good intentions gone awry remain.

What do you do with your project journal?