UNLIKE MOST INFORMATION TECHNOLOGY project managers, I have a degree in history. Okay, so I ended up in the IT industry more by accident than by design. But as a history major, I have made a few observations about the profession of project management.
As part of my studies for the Project Management Professional (pmp®) exam, I was pleased to see that A Guide to the Project Management Body of Knowledge (PMBOK® Guide) promotes the use of historical information, particularly in planning. When available and accessible, historical information can provide lessons so that mistakes can be avoided and good practices duplicated. Yet, many organizations do not have meaningful historical information. (By meaningful, I mean somebody can find and 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. Most organizations confuse data repositories with project histories. Many also underestimate the value in storytelling.
What is History? There are two major factors preventing organizations from making the leap from historical data to historical information. 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 …. And in 1777 he ….” 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 than in understanding what they mean. History is actually a conglomeration of conflicting stories about people, not a single list of facts. The one thing that anyone should learn from history is that everyone had imperfect information, irrational impulses, and often very modest goals. The history of most projects is not any different.
Gordon MacMaster is a Partner of Day Is Done Partners Inc., an information technology management consulting firm in Ontario, Canada. To satisfy his parents, he tries to use his political science and history degrees whenever possible, even though he works in a different profession.
Another factor is a characteristic of the 20th 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 and 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, the decisions, assumptions, and guesses are gleaned from project information. 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 storyteller. One absorbs the context, nuances, and rationale (or lack thereof) behind the project documentation from them. Having access to a storyteller bypasses much of the forensic decision-making process. I believe that 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, storytelling 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? Storytelling is effective but usually informal. To formalize the process, a project manager should focus discussions by having specific questions about a past project that relate to an upcoming project. One drawback is relying on the presence of the storyteller. With the high mobility rate and use of contractors, the storyteller's presence is unreliable. Another drawback is requiring a storyteller 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 personal 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 and conducting a postproject 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 good mechanisms that can be used to create some meaningful project history.
Of course, the biggest roadblock to creating useful project history is the corporate culture. If good deeds go unrewarded, if mistakes are used as clubs rather than lessons, no one will be too willing to share any information about his or her project. If all of the official project history is quite rosy, but the actual project products are of questionable quality, it is a good sign that you have a corporate culture determined not to learn from experience.
TO PARAPHRASE GEORGE ORWELL, “He who controls the present controls the past. He who controls the past controls the future.” Without a formal knowledge transfer, organizations find themselves repeating past mistakes or not maximizing good practices. Take command of the present, tap into the lessons from the past, and have a bright future with your projects. ■
Reader Service Number 173