I talked excitedly about taking a small team of developers and reducing an eight-year backlog of change requests to nothing after two years of incremental development. My colleagues at the Software Engineering Institute (SEI) were unimpressed. “But Bruce, your experience may not be the definitive one!” This wonderful statement was used to dismiss everything I knew in just the few seconds it took to say it.

Does everything we know have to be anchored by a study of 100 projects and then analyzed for distribution and correlation? I don’t think so.

Instead, our individual experience is one thing that we know is true and accurate. We know because we went through it. The trick is how to use it in the future.

One thing I’ve concluded, in my over 30 years, is that which has just recently happened is most probably what will happen in the near future if we do the same kind of thing over again.

So why wouldn’t we include this low cost experience in our overall total and average cost? My wife’s argument was that we may not get this the next time. I was startled. This is exactly the same kind of “playing with the numbers” I’ve experienced for years in industry. I had stolen my wife away from a career at IBM, where she was a successful software engineer and process improvement lead. She had been making more money than I was. She is Phi Betta Kappa and graduated summa cum laude. I keep wondering why such smart people keep doing the same thing.

This little insight is very powerful, but we seem to rarely use it.

For example, my family and I went on an 18 day driving vacation. We drove from Illinois through Iowa, South Dakota, Montana, Idaho, Washington, Oregon, back through Idaho, to Wyoming, then straight through Iowa and Illinois to home. A great but somewhat exhausting trip. The kids handled it much better than I expected, but the secret was to stop at rocks they could climb or rivers they could fall into. They even found a Troll under a bridge in Seattle that kept them entertained for a long time. But what has this to do with corporate experience?

My wife had a budget to plan the whole trip around. This budget was based upon last year’s total amount we had spent on vacation and trips. First off, we had last years numbers because I keep that kind of stuff religiously in Quicken (see Quicken is a great project management tool). So we knew what we spent last year. Taking into account inflation, this should be a reasonable amount for this year. At least we would start with it and see how it works out.

So we are using an instance of what most recently happened as a planning bogey for what will happen next (see get the project management schedule right). This allows us to use something we know really did happen and see how it compares to what we want to happen next.

The trip went fine. We stayed very close to our expected expenditures. In fact we came in under budget. I asked my wife what we averaged for lodging costs. She gave me a number, but then said we needed to take out of that number the low cost of us staying on an Air Force base. I am retired from the Air Force, so my family and I can stay on a military facility if space is available. It can be a very hit and miss opportunity. We call the night before or the afternoon of the day we want to stay to find out if they have an available room. If yes, the cost of lodging (about equivalent to a 2 star motel) is about half of what we would pay for a commercial equivalent. So it can be a great cost reduction, assuming one is willing to stay in military facilities, no pool nor free breakfast, and don’t mind being awaken to reveille each morning.

So why wouldn’t we keep this low cost experience in our overall total and average cost? My wife’s argument was that we may not get this the next time. I was startled. This is exactly the same kind of “playing with the numbers” I’ve experience for years in industry. I had stolen my wife away from a career at IBM where she was a successful software engineer and process improvement lead. She had been making more money than I was. She is Phi Betta Kappa and graduated summa cum laude. I keep wondering why such smart people keeping doing this same thing?

The individual experience each of us have is, as I said, very powerful. It is a real experience. It really happened. This is an important insight. When we plan for a project, the challenge is to determine what the heck is really going to happen. How do we determine that? We usually gather lots of details from folks who have gone though it already. We may have a template or other “standard process” we pick and choose from to determine what we will need to do. We ideally will have completed projects that were similar that we can pull data from their reporting archives. All of this deals with finding a plan that will closely match the reality we hope to have (also see Four Project Management Planning Secrets).

The stumbling block is of course in the details. While we need the details, we have to be alert to not selectively editing out all the things that did go wrong. In project planning we talk a lot about risk management. A historical project already includes time and actions to handle real problems that arose from real risks. It also contains all those things that went right.

The trick in using this experience is not necessarily in the individual details. They are important but they have a tendency to change with time. So what can we use from your overall experience? Often it is just that — the overall experience.

I often propose the following experiment. Measure how long it takes you to drive to work. Pick two very precise points. One where you will start timing the drive and one where you will finish the drive. Measure how long it takes. Do this for a week. The time will vary based upon the traffic, construction, accidents and how you hit all the traffic lights. All those happening are possibilities each time you drive. One day you may hit every red light and have to wait the entire time of the light. Now compute your average. For extra credit, compute your standard deviation.

Pretty simple yes? Why would you want to throw out the case where there was a fender bender in front of you? It could happen again, yes? Or why throw out the case of some temporary road construction going on? Are you trying to estimate the fastest you would ever make it to work? What good is that? No, you are trying to compute the regular and consistent case. You want to keep all these “bad” and “good” cases. They represent the range of things that can happen. What happens if something new comes up? Let’s say a water main breaks and you have to be routed a different way? Yes, that is rare and different. But its impact is no different than that construction or just the bad luck of hitting all the lights wrong.

That one experience. That one drive is real and everything that happens in it is fair game for what can happen in the future. Why would you ever throw anything away? OK, if you got caught in the hurricane Katrina evacuation, you may want to throw that one out. In general, we want to keep all of it, because it is both what has happened and is something that can happen again. While these same things may not go wrong, they are great placeholders for things that do go wrong.

I’ve read many studies on successful and unsuccessful projects. I’ve come to the conclusion that while they capture many of the common elements, by the act of trying to find common elements they have a tendency to leave out unique and critical elements. I’ve had many successful projects. Some so successful I’ve watched people for years keep asking “what happen, how did we do that?” I’m convinced that in each of those projects the essential elements that made them successful were from a few unique activities that were tailored to the time and place of that project. The common “success factors” were useful and needed but what made the difference was those unique actions that applied to that specific time and place. These, I don’t believe, will often show up as common activities when comparing multiple successful efforts.

Four insights from these observations:
1. Use your experience. It may not be definitive, but it was a real instance of a real case.
2. Record and track your project. No editing. If it gets replanned three times before it finally works, that replanning is part of the experience. Don’t assume you’ll skip all the replanning next time.
3. Don’t assume that it will happen again just like it did in the past. But keep in mind that it will not be totally different either. Use the fact that it took 12 months, but not the fact that you had a power outage for three days during the project. Don’t subtract out the occurrence of the power outage from the total time.
4. Don’t assume the next one will be perfect. That is a great goal, but a lousy way to plan. Also don’t assume that it will just be “a lot better.” Save that until it really is a lot better – and you actually see it happen.

What are your key experiences that help you manage your projects successfully?