Applying project history lessons
“What do you mean the software doesn’t interface properly with the mainframe system?” the CFO bellows across the office, arriving back from leave to find the finance system unavailable. “The same thing happened when IT upgraded to the previous version three years ago. Didn’t anyone think to check it this time?”
“But no one who worked on that project is here any more,” you reply in defence.
“Well, we all had to sit through a half-day Lessons Learned review. Why wasn’t that used as input to the project?” he asks.
Now it’s your turn to get frustrated, as the project office told you they didn’t have any knowledge of similar projects when you started, bringing to mind Santayana: “Those that cannot remember the past are condemned to repeat it.” And how often do you find history repeating itself in organisations? The same issues, failures to communicate, problems with release management, and so on.
Given the transient nature of projects, it’s not surprising the maintenance of ‘corporate history’ of projects is often lacking. Sometimes it’s because project managers get brought in from outside and leave at the end of the project without an adequate handover to permanent staff. Other times, subject matter experts are allocated as the project manager without appropriate training in record keeping and reporting. So how can PMOs help organisations with project history?
One key function for PMOs is maintaining a Centre of Excellence (CoE), which includes maintaining and making accessible to future projects the body of data, information and knowledge accumulated during the progress of projects. This should be supported by using education and induction programs to demonstrate desired behaviours and best practice to all staff and ensure lessons from the past live on.
Also, everyone loves project war stories, so maintaining a network—inside and outside an organisation—of people that worked on projects who will share their experiences often can help bring the dry documentation to life through exposing tacit or personal knowledge, or improve efficiency by quickly directing staff to the critical aspects of relevant records.
This sharing of learning is especially important for planning and estimating, where tools and techniques are useful but experience and a detailed knowledge of the work required for delivering a project is essential.
Benefits management is another key PMO function that incorporates history. Projects come and go but benefits management requires an understanding of the original purpose of the project to determine if the capabilities delivered by projects continue to deliver effective benefits.
And, although project reporting is often seen as a basic function providing a snapshot of a program or project, the analysis of historic reports can often reveal where a project went off the rails, or more systemic issues such as shortcomings in governance, demonstrating another way recording the history of change and making it available to future projects adds value to an organisation.
So why should PMOs be given the task of maintaining records? Wouldn’t it fit better in operations, where there is less change? History is about recording events and change, which is the essence of programs and projects. PMOs maintain the processes for monitoring and reporting based on the impartial recording of facts and figures for analysis to improve future delivery of change. However, with every change there are usually winners and losers. If Winston Churchill was correct in stating, “history is written by the victors”, given the level of failed projects, shouldn’t project history be recorded by impartial observers rather than the last man standing?
Still not convinced? Remember that best selling memoirs are based on the events in people’s lives. Now doesn’t being part of that make it sound more exciting?
