In my work with Program Management Offices (PMOs) for the past few years, I have developed some observations about PMO maturity, and the capabilities and competencies that PMOs have incorporated into their overall organizational makeup. Typically, PMOs are formed in organizations to ensure that the project groups can consistently and repeatedly deliver excellence in their project outcomes. Or, in the case of strict IT PMOs, they are usually formed to provide project strategy and execution of IT projects for the organization. They are also often formed at mergers between two large firms to insure that systems integration and application rationalization are handled in a systematic manner in order to achieve the expected synergies of the merger.
As Program Management Offices (PMOs) mature in their capabilities and delivery, they receive much feedback from the stakeholders that they serve concerning what they did right, and in what areas they need to bolster their capabilities. This feedback comes from auditors, from business functional areas that are served by the PMO, or from systems/applications/infrastructure delivery in the case of an IT PMO. How well the PMO meets overall organizational objectives and goals is very important to the future of the PMO and its growth.
In my experience, two capability areas that most PMOs almost always improve are Vendor Management and Risk Management. Although these two areas might have been given simple methodology tasks at the outset of the PMO, it is the feedback from stakeholders and the organization, as well as PMO benchmarking outside the organization, that determines to what extent Vendor Management and Risk Management are improved in both competencies and capabilities.
Technology development is a third area that normally receives much PMO attention during growth and maturity because more and more projects have a technology development component that cannot be addressed on a “one off” project basis for long if the PMO is to ensure consistency and repeatability of delivery.
At some point in the development of every PMO, the topic of Knowledge Management is raised as an additional capability area that must be addressed. This happens in several ways. First, the larger organization in which the PMO resides may already have a Knowledge Management system that captures, defines, classifies, and documents data and information for the larger organization. The second way in which Knowledge Management systems are often introduced in PMOs is as a result of recurring problems in projects that are not detected until they have hindered the delivery in three or four of the projects. Then, PMOs get interested in capturing these problems, their solutions, and what can be done to prevent them in the future. They may start with a simple Project Lessons Learned initiative to get the ball rolling. Lessons learned are one of the principal pathways for data and information to be capture, stored, and analyzed in a knowledge management system.
Michael Koenig, in his paper “What is KM? Knowledge Management Explained,” from KM World, May 4, 2012, explains the difficulty that most organization have in implementing effective lessons learned processes.
“The implementation of a lessons learned system is complex both politically and operationally. Many of the questions surrounding such a system are difficult to answer. Who is to decide what constitutes a worthwhile lesson learned? Are employees free to submit to the system un-vetted? Most successful lessons learned implementations have concluded that such a system needs to be monitored and that there needs to be a vetting and approval mechanism before items are mounted as lessons learned. How long do items stay in the system? Who decides when an item is no longer salient and timely? Most successful lessons learned systems have an active weeding or stratification process. Without a clearly designed process for weeding, the proportion of new and crisp items inevitably declines, the system begins to look stale and usage and utility falls. Deletion, of course, is not necessarily loss and destruction. Using stratification principles, items removed from the foreground can be archived and moved to the background but still made available.
All these questions need to be carefully thought out and resolved, and the mechanisms designed and put in place before a lessons-learned system is launched. Inattention can easily lead to failure and the tarring of subsequent efforts.”
I have witnessed this difficulty in implementing project lessons learned processes in several PMOs. Typically “project lessons learned” are perceived by the project managers and teams as a means of “assigning blame” for things that went wrong in projects. Politically, the project managers, and even management, shied away from attempts to identify lessons learned. Certainly they did not want them documented for others to read and remember.
However, there may actually be an alternative pathway to Knowledge Management systems that most organizations have not leveraged to this point. It’s called “Project Risk Management.” If your organization has a robust project risk management process in place that identifies risks, monitors risks if they triggered in projects, and then facilitates an effective mitigation program for them, then focusing on project risks is a natural pathway to Knowledge Management that the PMO should explore.
I have depicted the relationships between Knowledge Management, Lessons Learned, and Risk Management in the triangle diagram below.
In a particular organization where the path between Lessons Learned and Knowledge Management seems torturous, then the path between Risk Management and Knowledge Management may present a clearer pathway. Of course, in a fully mature organization, the legs of the triangle would represent flows in both directions meaning Knowledge and Risk Management would feed and sustain the other as would Risk Management and Lessons Learned.
Program Management Offices (PMOs) will continue to seek ways to capture, document, classify, share, and use knowledge management. What I have provided here is food for thought about the origin of the data and information that they may wish to preserve in their KM systems. Some very mature project organizations have employed what is termed as “knowledge-based risk” whereby they define risk manager roles, and feed those roles with knowledge so that they make informed decisions for future project efforts. NASA, for example, has some of these groups. You may want to consider such a structure for your PMO.
Leave a Reply