Keeping a Project Journal

[article]
A Key to Personal Growth
Summary:

If you think that keeping a journal is only for adolescent girls, read this week's column by Lee Copeland. Among other things, he suggests that a project journal helps you stay organized; teaches you what not to do next time; and makes it easier to explain what went wrong in a troubled project when you have to defend yourself. He also gives tips on being a good recorder.

Yesterday I was helping my youngest son, Rajan, with a report on John Muir, one of the first environmentalists.

Remembering a journal of Muir's I had read many years ago, I dug through dusty boxes in my basement to find My First Summer in the Sierra. It is Muir's record of his experiences as he first explored the magnificent Yosemite Valley in 1869. As I read passages to my son I remembered journals that I have kept-project journals-that recorded my experiences as I worked on various projects. I'd like to suggest that you too should keep project journals.

 Why keep a project journal? I can suggest a number of reasons:

  • Remembering. By recording in my journal, I have all the information in one place, nothing gets lost, and it is organized.
  • Evaluating the project. Often we will be called upon to evaluate some part of the project's activities or deliverables. Your project journal will be filled with the details that make an accurate evaluation possible. Rather than having to depend on anecdotal evidence (I call them "campfire stories") we will have real data to use.
  • Evaluating ourselves. In order to grow we must change. In order to change we must establish a new direction. Your project journal will be an amazing source of data for your own self-evaluation and improvement.
  • Protecting. When involved in a troubled project, you may find yourself in a round of "Place The Blame." At this point your journal may have great value as a contemporaneous record of what transpired earlier. Many people may be very interested in what you have written. It may save your skin (and other important body parts).

Once you commit to keep a journal, the basic question is what to write. I use an approach derived from Virginia Satir's Interaction Model:

  • First, I record what I saw and heard. I try to capture the event exactly-word for word, scene for scene, with no embellishment or evaluation on my part. As Joe Friday on Dragnet used to say, "Just the facts ma'am. Just the facts."
  • Second, I add my interpretation and understanding. If the meaning I attach to the event is different from the exact words and actions I observed, I write my interpretation in my journal. I also consider whether this interpretation is mine alone or if others would have the same interpretation.
  • Third, I add my feelings about what has transpired. Yes techies, it is okay to have feelings about things. I once worked for a man who said, "Feelings are facts to those who have them." In my youth I thought that bit of sloppy thinking was nonsense. Now that I am much older and a little wiser it makes perfect sense. Our feelings influence us in the same  way our facts do.
  • Fourth, I record my response-what I said or did at the time. Again, I note exactly what I said and did. If I meant to give a different response I note that also.

  • Fifth, I note my feelings about my response. Was my response appropriate?
    Was it too sharp? Too judgmental? Too passive? Not only is it okay to have
    feelings about our responses, it is vital to evaluate them. Our feelings often give excellent guidance about the appropriateness of our responses.

Later, as I put Muir's journal back in the box in the basement, I noticed a
project journal I had written a few years ago. As I thumbed through it, these
passages caught my eye:

10 Feb

Is there a use case model? (No)

Is there a list of actors? (No)

Can we meet with the developers to discuss some questions we have? (No)

15 Apr

Downloaded the latest build from the configuration management system.
It won't even compile. A number of files are missing.

26 Apr

Development has announced that source code will not be turned over to
testing because it "previously appeared to have created some
confusion." What that means is that when we saw how bad it was and
said so publicly, it embarrassed development.

29 Apr

THE DATE SLIPPED A YEAR!!

What we all knew was finally admitted by management.

26 May

That's it. I'm done. My three months of consulting are up. I'll miss my
apartment on the beach. I can't say the same about this project.

Remembering this project, its successes, its difficulties, and most of all the friends I made, I smiled, put the project journal back in its box, and walked back upstairs.

Reference
Satir Model: Family Therapy and Beyond. John Banmen, Jane Gerber (Contributor), Maria Gomori (Contributor), Virginia M. Satir. Science & Behavior Books; ISBN: 0831400781; (July 1991)

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.