Managing Product Development

Don has a great post on Single Point Requirements. You get one example of the requirements: “This product needs to do this. Just this.” Sure enough some months (or years) later, that single example is not sufficiently general to do everything you want the product to do.

That’s ok, as long as you plan to iterate the product development. If you really think that one example is all you’ll need, you will be bitten. But if you (and your customer) are smart enough to say, “Ok, we’ll get this for now, and see what happens over time,” you’ll be ready to iterate.

This happened to me when I was converting a database from one platform to another over 20 years ago. I’d received the spec for the database and assurances that the data was “clean.” I expected to spend up to a week on the script to convert the database and any cleaning by hand. Only the first 20 records in the database were clean. Ok, maybe the other 10,000 weren’t really out of spec, but over 1000 were, and all in different ways. What I expected to take a few tries (I was reading the database off a tape and writing to another tape–this is the olden days), took weeks of finding all the ways the data could be dirty.

I learned several things from that experience: to use a lab notebook to record what I was doing, including what had worked and what hadn’t worked; and to plan to iterate on anything that looked like it might be “the only way the data can look.”

I’m teaching project management to graduate students this year. One of their assignments is to keep a project management journal. I explained it this way: PMs make decisions where the consequences — the results of their decisions — can be far removed from the decision. One of the things I want the students to learn is how to observe their states, not just the project’s state. Journaling is the feedback technique I chose for this class.

I explained this to someone last week, and he was more than mildly surprised. He’d never heard of journaling, certainly not as a technique to obtain feedback about your own work. I was surprised, because before I’d heard of journaling, I’d kept an “engineering” notebook. I took notes at meetings, notes about problems, anything I didn’t want to forget in my notebook. I didn’t use the notebook specifically as feedback for me — not at the beginning — but my notebook is how I finally learned not to create infinite loops. (I was a pro at writing infinite loops no matter what language, and it wasn’t until I started noting under which circumstances I’d created the loop did I learn to stop writing them.)

I learned about journaling when I read Weinberg’s Becoming a Technical Leader. Weinberg suggested people journal, not just taking notes, but looking back at your work or life and commenting on it. Aha! I learned about my decision-making patterns and I could make choices about whether I wanted to continue with those same choices or make new ones. (I learned tons of great stuff from that book.)

In my consulting, I find that too many managers and project managers don’t take a few minutes a day to reflect on what they’ve done, the decisions they made, or the consequences of those decisions. I started notebooking in 1978. I started journaling in 1995 (ok, so I was a little slow). But now, I don’t work without the benefit of some form of notebook and journal. Do you journal? Do you find it effective? Have you ever kept a journal to see where your PM decisions have taken you?

If you’re a project manager, a functional manager, a technical lead, or someone who wants to improve their work, start a journal or a log.

When I was an engineer, I kept an engineering notebook. I discovered a bunch of ways I created the same defects. (Yes, developers create defects as they create products, and we pay them to do so.) For example, when I wrote FORTRAN code, I was great at creating infinite loops. As I wrote the code, I didn’t pay enough attention to the start and end conditions. By tracking how I didn’t pay enough attention, I was able to reduce the number of infinite loops I created.

I used that learning when I started running projects. On my first project, I got stuck, not achieving part of the end state. Since I was still keeping an engineering notebook, I wrote this sentence, “Gee, this seems just like those inifinite loops I wrote. Will this project never end??”

That sentence was a clue: Look at my initiation and end states. Had I set up an infinite-loop project? What did I have to do to stop the loop?

I use journals (engineering notebooks, management notebooks, notes at meetings, whatever you want to call them) to track my individual patterns and learn when they help me and when they hinder me. Then I have a choice about continuing the behavior pattern.

So, if you’re not yet keeping a journal or log, consider it. Write down your decisions and why you chose to make them. Write down your problems or defects. See if you can discover the root cause of the problem. After a few months, you’ll know more about how you think and act at work — which, for me, is a Good Thing.