Do We Learn From Project History?

Like most Information Technology Project Managers I have a degree in History. OK, so I ended up in the industry more by accident than design. But as a history major I have made a few observations about the project management profession.

As part of my studies for the Project Management Certification from the Project Management Institute, I was pleased to see the PMBOK (Project Management Body of Knowledge) promotes the use of historical information, particularly in planning. When available and accessible, historical information can provide lessons so mistakes can be avoided and good practices duplicated. Yet, many organizations do not have meaningful historical information. (By meaningful, I mean somebody can use the information in the future.) It's not that there is a lack of data. The entire Data Warehousing industry is booming because of data's abundance. Are repositories of data also meaningful historical information? The answer is obviously no. There are two major factors preventing organizations from making the leap from historical data to historical information.

What is History?

One factor is how we are taught history in school. Unfortunately, many history teachers and texts approach the subject as a monolithic, series of sequenced facts. "In 1776 George Washington did the following. In 1777 he did the following...". That sound was my head bouncing off the keyboard due to Repressed Boredom Syndrome. Even history tests are graded more on your ability to remember facts as opposed to understanding what they mean. History is actually a conglomeration of conflicting stories about people, not a single list of facts. The one thing anyone should learn from history is everyone had imperfect information, irrational impulses and often very modest goals. The history of most projects is not any different.

Another factor is a characteristic of the twentieth century - the predominance of scientific objectivity in business. Numbers have a higher value than perceptions - proven facts over insight. Subjective data is often perceived as having a lesser value.

Therefore, it is not surprising to find past project documentation neatly stored chronologically (when it exists but that is another story). Data repositories reflect the objective parameters of a project; the facts, figures, and approved documents. Together, they make the monolithic, official history of a project. It takes a significant effort to sort through the official history to discover those useful nuggets of information for an upcoming project. I call the process forensic decision making and it is not unlike the research process used by historians. The important events during the life of the project are identified. With an event structure, decisions, assumptions and guesses are gleaned. Judgments are then made if any of this information is relevant to an upcoming project. The effort involved is a significant deterrent to using historical data in project planning regardless of the quality of the data repositories.

Do we learn from past projects?

Despite the volume of data out there, the most valuable learning about past projects often comes from listening to those few individuals that assume the role of story-tellers. One absorbs the context, nuances and rationale (or lack thereof) behind the project documentation from them. Having access to a story-teller by-passes much of the forensic decision making process. I believe many organizations do not appreciate just how much they rely on the oral tradition for all information exchanges, let alone previous projects. In some cases, story-telling is discouraged because it is subjective, and may not align with the 'official' history.

Combining objective project documentation with subjective perceptions about a project is the leap between historical data and historical information. By having the data about a decision and the context associated with it, a project manager will be more readily able to turn past project decisions into lessons for the future. Assuming an organization has project documentation, how does one capture the subjective views?

How can we gather information from past projects?

Story telling is effective but usually informal. To formalize the process, a project manager should have specific questions about a past project that relate to an upcoming project to focus discussions. One drawback is it relies on the presence of the story-teller. With the high mobility rate and use of contractors that presence is unreliable. Another drawback is it requires a story-teller to divulge his or her recollections. Most people do not fondly share mistakes. They may also be unwilling (or too willing) to say negative things about a client or co-worker. Focusing on specific issues that bridge past and upcoming projects should keep the discussion away from the hygiene habits of team members.

Subjective information is, well, subjective. So getting a second opinion may be useful. We all have our own perceptions and axes to grind. Having multiple viewpoints should provide the conglomeration of stories, which in essence, is real history.

There are some project management and quality methods that use knowledge management practices to make the capturing of subjective data part of the overall project process. These knowledge management practices fall into two broad categories:
· Conducting reviews during the project
· Conducting a post project review

Lessons learned documents or presentations are very useful for spreading improvement ideas from someone else's experience. There have been several articles in PM Network about conducting project reviews during and/or after the project. These are all good mechanisms whose goal can be to create some meaningful project history.

Of course, the biggest roadblock to creating useful project history is the corporate culture. If no good deed goes unpunished, if mistakes are used as clubs rather than lessons, no one will be too willing to share any information about their projects. If all of the official project history is quite rosy, but the actual project products are of questionable quality, it is a good sign you have a corporate culture determined to not learn from experience.

To paraphrase George Orwell, 'He who controls the present controls the past. He who controls the past controls the future.' Take command of the present, tap into the lessons from the past and have a bright future with your projects.

This article was published in the July 2000 edition of PM Network.