I remember my first PMI meeting. It was in the early 1980’s and I had just been appointed to manage a fairly large project for the Data Processing Division of a large bank. The meeting had been recommended to me by a colleague who was not a project manager herself but was married to a project manager at a large civil engineering company. I was the only person at the meeting who was not a civil engineer or construction manager and the keynote address was about building a large oil refinery in the middle-east. I should also mention that I was the only woman at the meeting and a good twenty years younger than anyone else in the room. During a break I was chatting with a couple of the other attendees and when I told them where I worked one of them observed that he believed that “real project management” wasn’t really relevant to Data Processing. Needless to say, I didn’t go back.
Fortunately while at that meeting, I joined the PMI and got my first copy of the Project Management Body of Knowledge – which came in a 3-ring binder. I read it and realized that it contained a lot of information that was obviously influenced by engineering and construction but also seemed to be very relevant to the projects we were trying to manage in Data Processing. Indeed, there were a number of others in DP, which eventually became information systems, then Information Technology, who also saw the relevance of methodically applying a set of principles and processes for managing technology projects.
People started writing about and consulting practices were built around introducing these methods into organizations as a way of improving the predictability and performance of projects, not only in Information Technology but in other industries and disciplines as well. In 1975, Thomas Wheelright and Kim Clark of Harvard first published The Product Development Challenge: Competing Through Speed Quality and Creativity which included a number of case studies and arguments for applying what are now considered standard project management processes to managing the development and introduction of new technology products. Wheelright and Clark also expanded the focus from the execution of an individual project to what they called the “aggregate project plan”, which “helps managers focus on a set of projects” and “improve resource allocation, project sequencing, and critical development capabilities” – a recognition that project management and project portfolio management (PPM) are not different disciplines but common views from different perspectives.
Organizations have also changed to recognize the role of project and portfolio management. Project Management Offices (PMO’s) began springing up as an internal mechanism for introducing best-practices and processes into enterprises, providing oversight of the processes, and maintaining and providing specialized practitioners (project managers) who understood and could effectively apply these processes and principles. And while PMO’s have tended to focused on one segment or discipline within the enterprise (most notably IT), enterprise PMO’s (ePMO’s) are becoming more common as enterprises realize the value of providing oversight and managing the portfolio of projects from the enterprise level.
There are a number of reasons for the proliferation of defined PPM processes and specialized organizations supporting those in different disciplines and businesses. The need for transparency, common language, oversight, and strategic alignment are not industry or discipline-specific; they are the common challenges that PPM is designed to address. What is different is how these processes are applied and executed to support the unique needs of the organization, both at the enterprise and functional level. What is appropriate and effective for the IT division of a multi-national conglomerate may not be appropriate for the product development division of the same company or the IT department of a small start-up. In my next post I will walk you through what makes a successful PMO’s and ePMO’s. Stay tuned.