In the article Get the Schedule Right one of the key items is to know the history of how our organization has performed in the past. As simple as this is to say, it can be very difficult to do in practice. Here are three successful techniques for getting the project management tool data we need.

Three things I’ve found that have helped me quickly find our past project performance:

1. Ask How Long Similar Projects Have Taken In the Past.

Simply ask your team or other managers how long projects have been taking. Ask them for the evidence, actual data that shows when something started (such as an e-mail request) and when something ended (such as when the customer said they will take the product).  As much as it is nice to have dozens of data points, I’ve found some data is often better than none at all. In one case, when we decided to redesign our primary software application, we needed to estimate how long we thought the project would take. While the resulting estimate was not short, it seemed reasonable. I then asked if anyone remembered how long it took to develop our current system. The consensus was a number that was twice as long. I then said that twice as long number would be our estimate. No one liked this approach. Their notion is that we’ll not see all the problems seen in the past but I’ve found that such an estimate is often better than an estimate made just by walking through everything we believe needs to be done. Actual past project performance data almost always captures more of the time needed then does a traditional estimate. Most estimates fail, not due to getting something wrong, but for missing things that were needed — errors of omission.

2. Search For Information On Past Project Performance.

While I like to get data from people on what they remember, I always want to back it up with hard evidence as I mention above. Here is where I go and look at the archives of past projects. There is often a formal folder (physical or electronic) that includes much of the data on the management of a past project. As much as I like these folders, and often they have good information in them, too often they reflect what is politically safe to say, rather than the details of what actually happened and what was done to make things work. Use formal records with caution. An InformationWeek article from Nov 9, 2009, called “IT vs. Organizational Paranoia” talked about companies limiting search because of a fear of exposing e-mails, draft documents, private communications and other sources of potentially embarrassing and easily misconstrued information. This, somewhat humorously, may be part of the reason so many “official status reports” are often nearly useless to determine how things are going, or how things went, on a project.

3. Find Project Transactions and Versions For A Highly Insightful Source of Information.

Here, I look for those streams of discussion that talked about the last projects. For example, minutes of meetings. These are often less sanitized then official status reports. In one case, we had an initiative to put out a combined weekly status report on all projects. This was a simple e-mail with updates on milestones being reached (and some being redacted, saying they weren’t reached), and major open issues. The reason this data is more useful than data found in official reports or official databases is that it shows all the “transactions” against that item (milestones, plans, etc.). In other words, the official report or database often only shows some version of the final action. Instead what is actually more useful is seeing everything that happened that led up to the final results.

Put It All Together Into A Realistic Plan

I was asked to plan a new product based upon the apparent success of another product using the new technology we wanted to adopt. I found the Microsoft project plan that controlled the apparently successful effort. Overall, it looked pretty good from beginning to end. It had the duration we needed to hit a marketing window. Luckily, in a sense, the project plan was kept in a repository that archived all the changes to the plan. This allowed me to go look at the original plan and compare it to the final plan. Once the original baseline was taken into account, and the half dozen “replans” of the plan, the real time from beginning to end was on order of 50% longer. This longer schedule turned out to be a better estimate of what it would take than was using the “final” published plan. One fundamental that most people miss is the notion that our plan, on the first day we propose it, might in fact go through multiple replans during the duration of the project. These replans are what is often lost in formal records. I tell project managers that when they stand up in front of senior management for the first time and propose their plan, the project manager should know how things have historically transpired — including all the typical things that will go wrong. A project may in fact regularly go through, for example, three replans on its way to a successful launch. We just need to find the data that adequately describes how projects normally transpire — warts and all.

While getting and understanding project data is critical to successful efforts, in a time of “data glut” we still have to work hard at making sure the data we get is something we can reliably use. Just because it is found in a database, or a wiki or served up as a service from an analytic system, does not mean we don’t have to understand the real meaning and source of the data. Sometimes we have to look in unconventional places to find the project past performance data we need.

Where have you found to be your best source of project data?

For more on planning, start with Yes Virginia, There Is A Project Management Plan.