The history of OPM3
John Schlichter, MBA
Bill Haeck, MBA, PMP
1998 - Going Boldly Where No One Had Gone Before
In 1998 a project was chartered to develop an international standard for industry and government strictly through the grassroots efforts of unpaid volunteers. Unlike other such efforts, this was a first for many reasons. The standard would help organizations to assess and improve their project management capabilities as well as the capabilities necessary to achieve organizational strategies through projects. The standard would be a project management maturity model, setting the standard for excellence in project, program, and portfolio management best practices, and explaining the capabilities necessary to achieve those best practices. In time, the volunteer team developing the maturity model would seek and obtain widespread participation from more professionals across industries and geographies than any other initiative to develop a maturity model to date. While these characteristics made the project the first of its kind, another fact set the team apart: it operated almost entirely as a virtual team, and most members of the team never met each other face-to-face. This is the story of their journey and of the development of the Organizational Project Management Maturity Model or OPM3™.
What led to the decision to charter OPM3?
In May 1998, members of the Project Management Institute (PMI) Standards Committee met to design a portfolio of project management standards. The 1998 Standards Committee was an eclectic mix of one dozen personalities from a wide spectrum of industries and geographies, spanning interests, skills, and age groups. In the evenings after Standards Committee meetings committee members like would seek the thrills of roller-coaster parks, in some ways foreshadowing the exhilarating ride ahead to develop the OPM3.
The 1998 PMI Standards Committee discussed the interest that had been expressed by many PMI members in the possibility of a project management maturity model standard. The concept of “maturity” had been popularised through the very successful “Capability Maturity Model” for software that was developed by the Software Engineering Institute of Carnegie-Mellon University between 1986 and 1993. The PMI Standards Committee decided to charter a project to develop such a standard. While PMI's “A Guide to the Project Management Body of Knowledge” or PMBOK® Guide was widely used at that time as the standard for managing single projects, no standards existed for improving project management in organizations.1 Eric Jeanett asserted that the committee must learn and describe why organizations would want such a maturity model standard. With the concurrence of Marge Combe and Paul Dinsmore the original co-project managers, the committee decided the first task was to analyse existing maturity models and the task was assigned to John Schlichter.
John Schlichter immediately revisited Eric Jeanett's question regarding why organizations would want such a standard, and guided the team to choose to create a standard to help organizations develop the capabilities to execute strategies through projects. In this view, project management could be developed as a method that enables organizations to achieve their strategic intent. This purpose was distinct from the single-project focus of the PMBOK® Guide. The PMI maturity model would not be simply a PMBOK® Guide CMM.
What was the project management profession like in 1998?
In 1998, PMI had less than 50,000 members, and less than 10,000 people had earned PMI's Project Management Professional (PMP) certification. Over the life-span of the OPM3 project between 1998 and 2003, PMI membership increased to over 100,000 members and 50,000 PMP's.
What was OPM3 like in the beginning?
In 1999 when John Schlichter became the Program Director of the OPM3 Program, he started recruiting hundreds of volunteers and assembled a core team, which was called the Guidance Team. He campaigned relentlessly, enrolling person after person in a vision of work that would “transform business in the 21st century.” A key message was that the team was the best and brightest people that the world had to offer, that the team was proud of its capabilities and wanted the world to know about it, and that anyone who wanted to join the team could find a place in it where he or she belonged.
People were enrolled by the awesome mission and vision of the project. The project's mission was to develop a maturity model that provides methods for assessing and developing capabilities that enhance an organization's ability to deliver projects successfully, consistently, and predictably in order to accomplish the strategies of the organization and improve organizational effectiveness. The leadership's vision was to create a widely and enthusiastically endorsed maturity model that is recognized worldwide as the standard for developing and assessing project management capabilities within any organization. Early in the project, a curious observer named Stan Rifkin contacted John Schlichter to explain to him the many reasons why a project with such aspirations was likely to fail. Soon thereafter Stan Rifkin accepted John's invitation to become his deputy.2 More and more people caught the vision.
In the early days, the Program Director lobbied for several strategic priorities that distinguished OPM3:
- the standard would link project management with execution of organization strategy
- the standard would not only describe but explain how capabilities cause measurable outcomes
- instead of being a derivative of commercial models, the standard would be an innovation that would advance project management throughout industry
- because all organizations are not alike and their structures are contingent on environments which vary widely, the standard would identify contingency variables of different types of organizations and the ways in which the pursuit of maturity differs for each type
- the standard would enjoy the credibility of primary and secondary research
The team agreed that a standard of this importance must be based in solid research and wide participation from professionals across industries throughout the world. Research was the primary focus of the project for the first year. In the course of the project, the OPM3 team would analyse dozens of maturity models and survey over 30,000 professionals.
The ranks of volunteers grew rapidly, and PMI soon realized that they had never before attempted a project of such magnitude, which exceeded the size and ambition of the PMBOK® Guide Project several times. In the background of this growing project, the issue of intellectual property rights loomed. PMI implemented policies that would allow PMI to control the standards, which were developed under its auspices while allowing widespread participation in their development. Many volunteers disagreed with these policies and left the project, including Stan Rifkin. However, the Program Director and team coped successfully with the change and enrolled new volunteers under the new policy. Due to this change, the project was delayed of nearly one year.
1999 - The year of research
The Program Director recruited Terry Cooke-Davies and John Moran in February 1999 to lead a research team that would continue primary and secondary research for the OPM3 project. Initial research focused on analysing existing maturity models. Led by Peter Rogers and Marlies Egberding, a “Model Review Team” designed an approach to determine the following things about existing models:
- The scope of the model being reviewed, including its boundaries, focus, origin and purpose.
- The capabilities of the model under review, including such topics as its coverage of the PMBOK® Guide, the capabilities it contains, the extent to which paths to maturity are modelled, the working definition of “maturity”, and linkages to project success.
- How assessment of maturity is carried out, including the assessment process and whether or not organizations can “self-assess”.
- The basic structure of the model, including whether it is “staged” or “continuous”, and whether prerequisites are defined.
- Whether or not the model contains an implementation plan to assist organizations to become more “mature”.
Seventeen sub-teams were mobilized to review a representative selection of seventeen of 27 models that had been identified. To learn more about this process, see “Beyond the PMBOK® Guide” by Terry Cooke-Davies, John Schlichter, and Christopher Bredillet.3 As a result of the analysis of existing maturity models, the OPM3 leadership concluded that the provision of a PMI standard for organizational project management maturity would benefit PMI's stakeholders, since there are questions about project management maturity that were left unanswered by the existing range of models available to the profession and the stakeholders that it serves.
Research Team Co-Lead Terry Cooke-Davies demonstrated his leadership throughout the initial research phase of the project. In October 1999, John Schlichter invited Terry Cooke-Davies to become his deputy. Terry accepted the position and held it until July 2001, using his unique talent for facilitation to make countless contributions to the success of the project.4
While the need for an organizational project management maturity model had been established, the team struggled to find the best way to define what comprised maturity. At this time, Program Management was following the progress of one of the other projects that had been included in the 1998 Standards Committee's portfolio: the Project Manager Competency Development Framework Standard. Program Management observed their use of the Delphi technique to collect input from a large number of people, and asked the OPM3 team to use a similar approach to collect input from people regarding organizational project management maturity.
“The Delphi Technique is a means of establishing consensus among a group of people who share a common interest, but have differing perceptions and areas of expertise. It works by asking people for their anonymous input, and then feeding back the results of the input to people, in such a way that they can refine their response in the light of the feedback received from others.”5
The OPM3 Delphi process resulted in identification of individual elements that contribute to an organization's project management maturity. The Delphi process was repeated to include increasing numbers of participants. The elements, which were later named “Best Practices”, were grouped into ten categories in order to divide the content among volunteers who would develop the content further. The ten categories were:
- Standardization and Integration of Processes
- Performance Metrics
- Commitment to the Project Management Process
- Alignment and Prioritisation of Projects
- Continuous Improvement
- Using Success Criteria to Cull or Continue Projects
- People and Competence
- Allocation of Resources to Projects
- Organizational Fit
Organizational structure of the program
In addition to the Research Team, a Synthesis Team was formed to synthesize the input of ten smaller teams. Program Management recruited ten leaders, one for each category of Best Practices that had resulted from the Delphi activity. Each one of the ten teams or “Design Cells” within the Synthesis Team was responsible for development work within its field. While all Design Cell Leaders played a critical role in the development of the model, several of these Design Cell Leaders were promoted through the ranks of the project and remained active contributors for years through the final phase of the project, making vital and indelible contributions.
Ade Lewandowski was the Design Cell Leader for “Alignment and Prioritisation of Projects.” Later Ade Lewandowski would take on the role of Co-lead of the Integration Team (with Co-lead Claudia Bacca), playing a key role in managing the team that integrated organizational project management processes with the Best Practices and Capabilities of the model. Later he was promoted to the position of Architect, responsible for ensuring model development adhered to the architectural design.
Mila Bozic was the Design Cell Leader for “Commitment to the PM Process.” Later Mila Bozic became a “Tiger Team Lead,” responsible for one of several teams that refined the content resulting from the Delphi activity. Later she was promoted to the position of Quality Team Lead, responsible for ensuring configuration management of the model, facilitating change requests, and ensuring quality criteria were enforced.
At this time, Ralf Friedrich was the Design Cell Leader for “People and Competence.”
2000 - The New Millennium and the Design Cells
Each Design Cell team was assigned a category of Best Practices from the Delphi activity. The Best Practices represented maturity or a perfected condition, and Program Management asked the teams to reverse engineer the Best Practices into the incremental steps or capabilities that aggregate from a lesser to a more advanced condition. In this manner, the Best Practices were transformed into a large body of Capabilities leading to Best Practices. Program Management also asked each team to define the dependencies between Capabilities leading to its set of Best Practices, and also to identify dependencies among the Capabilities across the sets assigned to all teams. In this manner, the dependencies among all Best Practices were defined, and the dependencies among all Capabilities were defined, resulting in a large network of connected Capabilities leading to connected Best Practices. This engine of the model was dubbed the “Baseline Network.” No other maturity model had defined the individual relationships among all Capabilities of the model. Because all dependencies were defined, it became possible to identify all of the specific prerequisites for any given Best Practice or any given Capability. This increased the utility and flexibility of the model significantly.
While the ten Design Cells were working on the content of the model, this group represented only half of the organization structure for the project. The other half was devoted to continuing the research that underpins the model. The purpose of the research was to capture the voice of the customer and to validate the requirements used to design the model. The team learned that the market believes it is critical for the OPM3 standard to provide an effective means of assessing the maturity of organizational project management. The team learned that the market requires the product to be realistic, practical, easy to use, consistent, scalable, flexible, and accurate, focused on improvement, and that it must clearly demonstrate the relationship between causes and effects.
Another purpose of the research was to identify the most critical problems that organizations are facing regarding project management. In 2001, over two-thirds of nearly 2,000 survey respondents said their organizations had project selection criteria and that their organizations explicitly aligned projects to strategy, yet only one-fourth said their organizations had well-balanced portfolios of projects designed to achieve organizational strategy. Three out of four professionals said their organizations were not doing the right projects. The team decided this was one of the major problems that OPM3 would solve.
The requirements elicited through research surveys of project management professionals were organized within a House of Quality using Quality Function Deployment (QFD). Using this method, each design component of the model was evaluated and ranked against each requirement, guiding the design of the OPM3 according to the voice of the customer. For example, design components included: Capabilities (describing individual capabilities leading to best practices), Navigation Standards (describing how to navigate from lesser capabilities to more advanced capabilities), Outcomes (describing the results of having or using each capability) and Key Performance Indicators (describing what to look for to determine whether an outcome exists).
2001 - The Year of the Process Model
In June 2001, a motion was approved by the PMI Board of Directors supporting PMI Headquarters' completion of the OPM3. While the support was welcome, the team still faced significant challenges regarding the architecture of the model.
Why was a process model needed?
All of the Best Practices from the Delphi activity were decomposed into Capabilities. For each of those Capabilities, the teams identified the outcomes that should result from having or using each Capability. This resulted in a large body of content. Unfortunately this large body of content did not consistently demonstrate how to achieve the original purpose that the project had been chartered to accomplish: to help organizations develop the capabilities necessary to execute strategies through projects. Leadership of the project reminded the team to “keep the main thing the main thing.” The team decided to define the processes that an organization must operate in order to execute strategies through projects. A clear process by which projects can be used to execute strategies was necessary to enforce the primary objectives of the model.
Developing the organizational project management processes (necessary to achieve strategies through projects) and translating these processes into Best Practices, Capabilities, and Outcomes (which became the majority of the content of the maturity model) was a challenge. Part of this challenge was the integration of “process” content with “Delphi” content. Refining all of the content from the Delphi activity to make it internally consistent was also a challenge. To address this, the team developed quality criteria and internal work methods for reviewing and testing content. By the end of the project, over 15,000 test cases were developed and applied to the content of the model.
Another challenge was ensuring that the maturity model was internally consistent with PMI's premiere standard: A Guide to the Project Management Body of Knowledge or PMBOK® Guide. Over 80% of 2,000 survey respondents had said in response to surveys deployed by the OPM3 team that PMI's PMBOK® Guide should be integrated with PMI's OPM3. To address this challenge, the team determined how the project management processes defined in the PMBOK® Guide interface with other processes that are necessary to achieve organizational strategies through projects. The team decided that the PMBOK® Guide Process Groups of Initiating Processes, Planning Processes, Executing Processes, Controlling Processes, and Closing Processes do not occur only in the project management domain. They occur in the program and portfolio management domains as well.
Over 85% of 2,000 survey respondents had said in response to surveys deployed by the OPM3 team that integrating the PMBOK® Guide's Process Groups into the program and portfolio management processes of the OPM3 was the correct thing to do. The team was challenged then to define how the project, program, and portfolio domains integrate within a process model that explains how to make Initiating Processes, Planning Processes, Executing Processes, Controlling Processes, and Closing Processes capable (i.e. successful, consistent, and predictable) to achieve organizational strategies through projects. One of the Program Director's mentors at this time was George Easton, who holds a PhD in Statistics from Princeton and who had been a Senior Malcolm Baldrige Examiner. In a discussion with George Easton about Statistical Process Control (SPC), the Program Director realized how SPC could be incorporated into the OPM3 effectively to help the team achieve its charter. Through SPC, the initiating, planning, executing, controlling, and closing processes can be made capable through standardization, measurement, control, and continuous improvement. If the processes necessary to achieve organizational strategies through projects could be defined, the techniques for making those processes consistent and predictable could be defined as well, borrowing from the de facto standards made popular by Edward Demming and later used to develop the first maturity models.
Moreover, those techniques could be defined as Best Practices, which could be reverse engineered into the incremental steps or capabilities that aggregate from a lesser to a more advanced condition, in the same manner that all other OPM3 Best Practices had been transformed into Capabilities. This made the entire model internally consistent while creating a logical method for organizing all of the content and ensuring that the model achieves its primary purpose to help organizations achieve strategies through project management. While such breakthroughs propelled the project forward, on September 11th tragedy struck North America, and the team stalled. The leadership team was suddenly faced with the challenge of sustaining morale and momentum while managing public relations through the delay.
In this phase, the project's organization structure was re-invented once again, adapting to the needs of the project at that time. A Process Model Team was chartered to define the organizational project management processes. A Quality Team and several “Tiger Teams” were also mobilized to apply quality criteria to the first version of the Baseline Network. They executed over 2,400 test cases in the beginning of a large effort by many teams over the next couple of years to execute over 15,000 test cases to improve the quality of everything from the wording used to articulate a Best Practice to the logic used to define the sequences of Capabilities leading to maturity.
At this time, Lisa Kruszweski joined the OPM3 project. Lisa was employed by PMI to provide administrative support to the project. After Lisa joined, the administrative tasks of the team leaders dropped significantly, freeing resources for the development of the standard.
2002 - A year of change
Pressure was increasing from the marketplace and from PMI headquarters to speed up development of the model, but the economy was worsening, and most volunteers had to place a higher priority on their own livelihoods.
Re-baselining the project
To speed delivery of the first release of the model, the leadership team made a strategic decision to reduce the scope of the model by eliminating the design component called “Demographic Navigation” and to remove the design component called “Weighting Schema.” Both of these aspects of the model had been ranked as two of the top seven design features of the model by survey respondents. “Demographic Navigation” was a feature of OPM3 architecture that would account for the fact that there is not a single key to excellence or one road to maturity for all of the organizations that PMI serves. “Weighting Schema” was a feature of the model that meant each Capability would be assigned a weight signifying its influence on the organization's ability to execute strategies through projects
The guidance team felt these difficult decisions were necessary in order to keep the project on track for publication by the end of 2003. Developing both features would have required additional research and consensus building, taking time that the team did not have.
In addition to de-scoping the project, the leadership team focused on remobilising the volunteer workforce. The Guidance Team guided the development of a curriculum of presentations that explained everything about the OPM3 project, and required every volunteer to pass quizzes on every component of the curriculum. This was designed as an outreach program that was focused internally on OPM3's own existing volunteers and new volunteers that would join the ranks. Because it was focused inward, the Guidance Team named this training the “InReach Series” instead of an outreach series. Although some volunteers resisted this mandatory training initially, in time everyone including those who resisted initially praised the training as a break-through in harnessing the collective intelligence and experience of all of the volunteers. The InReach Series was also used as a basis for the development of training for beta testers. A monthly “OPM3 Today” Newsletter was also launched. One feature of the newsletter was a column that would spotlight a volunteer of the month.
While the workforce re-engaged, the team still did not know how to organize the massive amount of rich content into an operational format that could be used by organizations to assess and improve their capabilities. John Schlichter designed a prototype solution in cooperation with Ade Lewandowski and Fred Abrams and presented it to the Guidance Team in a physical meeting in Miami, and the team adopted it. The prototype called for multiple directories of information that would allow users to access the Best Practices, Capabilities, Outcomes, and Key Performance Indicators in a systematic way.
Up to this point, over 700 volunteers had worked on the OPM3. With support from the PMI Board of Directors, a strong management infrastructure, a critical mass of volunteers, an effective training program, and a prototype of the model, the team was poised to make the final push to deliver the OPM3 in the first half of the coming year so the model could be published by December 2003.
By November 2002, John Schlichter had led the team for 55 consecutive months. At this point he transitioned leadership of the project to his deputy Ralf Friedrich, although he continued for nearly six more months as a technical advisor to the management team. An announcement was made in PMI's publication PMI Today. PMI's Chief Executive Officer Greg Balestrero said “John Schlichter has contributed greatly to PMI and the OPM3 program.”
Ralf Friedrich recruited Bill Haeck as his deputy. Bill Haeck had been responsible previously for managing relationships with individuals who had expressed interest in having their organizations act as beta testers of the OPM3 in the final phase of the project that was at hand.
A team was created to generate the three directories described in the prototype that Program Management created. This team was called the Model Team, and was led by a longstanding volunteer, Fred Abrams, who previously had been a Research Team Co-lead in 2001. The Baseline Network was stored in a database. To represent the data in the book format, the data had to be converted. The Baseline Network was transformed into a directory of Best Practices, an Improvement Directory, and a detailed Information Directory.
2003 - The year project management will change
Getting the standard in a tangible format
As 2003 dawned, the team began to focus on refining the existing model, on optimising the interface of the model for the user, and on preparing to solicit and react to the results of beta testing. One of the primary challenges the model presented was its size and complexity. The model had to be packaged and presented in a manner which would not be intimidating. As a result, one of the most important decisions made early in 2003 was that OPM3 would be presented to the public in a multi-media format, with part of the model presented as a book, as originally envisioned, but with the majority of the content of the model presented as directories in a CD format. This resolved the issue of page count (i.e. cost, form factor), but also presented new and compelling opportunities for arranging and displaying the encyclopaedic scope of Best Practices, Capabilities, Outcomes, Key Performance Indicators, Metrics, and associated data.
Prior to providing the model to the beta testing community, the work that had begun in 2001 to ensure the quality of the model had to be completed. First and foremost, there was a considerable amount of work to do on the directories in order to ensure that the Best Practices, Capabilities, Outcomes, KPIs and Metrics had the proper dependencies, were well written, and were consistent in their tone, tense, and text. To accomplish this, the Guidance Team empowered a select group of individuals, appropriately named the Extreme Review Team (ERT), to put the entire baseline network through its paces. For almost two months, paired members of this team analysed and modified the dynamic content to ensure it exhibited sufficient quality to present to beta testers.
At the same time, the Guidance Team, John Schlichter and others began assisting a technical writer, Paul Wesman, with the task of actually describing the model and the concepts of OPM3 in the narrative section of the book. A technical writer was hired to do the primary writing of the standard to ensure the final product would read with one voice and to provide professional writing expertise to the project team. For the first six months of 2003, the team was heavily engaged in writing, rewriting, editing, and amending the narrative. As a result of these efforts and the efforts of the ERT, by June of 2003, the OPM3 team will be ready to release the entire OPM3 product to beta testers for its first complete test run.
Through the end of 2002 and throughout the first half of 2003, the Beta Test Team, led by Tom Keuten, worked to identify, qualify and select a final list of organizations from industry willing to spend the time and resources necessary to test the model functionally and provide valuable feedback on how to revise and improve the product. By mid-2003, as the narrative and directories were nearing completion, the Beta Test Team finalized its list of beta testers supported by mentoring teams.
As the second half of 2003 approaches, the team is poised to begin the final sprint to the finish line. In the last months of the project, the team, spearheaded by the Home Stretch Review Team (HST) led by Lisa Kruszweski will navigate through three separate rounds of testing by multiple groups including beta testers recruited from various industries. Finally after three rounds of revisions and reviews, the team will submit the model to PMI to publish. Although there is still much to be done and far too little time to do it, in the context of the entire OPM3 adventure, it is comforting to know this is the final phase of the project.
The standard will be handed off to the Sponsor, Steve Fahrenkrog on schedule.
Opportunities for the profession
Within the OPM3 team there is confidence that the work done by the team will not only provide a springboard for further development in this area, but will have an immediate impact by allowing companies to learn about, assess, and ultimately improve their ability to achieve organisational success through the use of project management. In these achievements the OPM3 team takes great satisfaction, but also looks forward to the use of this work by other professionals within the project management community to further advance the cause of project management maturity. The team is also confident that the OPM3 will be a platform that other standards can be derived from, e.g. it contains the foundation for project portfolio management.
Over the life-cycle of the OPM3 project, the team experienced many highs and lows, like the roller coaster riders of the 1998 Standards Committee who launched this project. The OPM3 leadership consistently reminded the team to “keep the main thing the main thing.” While this is the end of the journey to develop the original OPM3, it is the beginning of a long journey to advance the maturity of the project management profession, which is the main thing. The first release of the OPM3 will create a context for refining and extending the body of knowledge regarding organisational project management, and for improving the ability of organisations to achieve their strategic intent through project management.
In this paper several key-volunteers have been mentioned. The OPM3 product, however, is the result of the hundreds of volunteers who have contributed over the life-span of the project and who deserve their recognition and thank. Without them, OPM3 would not have been the product it is now and without the experience of 1000 of years of project management experience would not have been incorporated into OPM3. I would like to thank everyone, who spent time away from the family, friends and other important activities to contribute to the advancement of the profession.
Appendix 1: Lessons Learned
Lessons Learned 1998
In the beginning, the main challenge was to win hearts and minds to the OPM3 cause. An essential lesson was that people are enrolled by hearing and experiencing the passion of someone who communicates what is possible. Once there was some awareness of OPM3, the next challenge was gaining acceptance and commitment to a strategy. The leaders learned the project's organization structure needed to be somewhat informal, although leadership responsibility was clear. They learned that rewards were personal (through praise and acknowledgement), while control systems were paternalistic.
Another lesson is that in a volunteer project when there are many interests at stake, it is critical to establish the expectations, rules, and terms for volunteering before a critical mass of volunteers makes any significant contributions to the cause. It is imperative to honour the integrity of the relationships that are established in the beginning when a user community emerges and to maintain trust, or the community may divide and fail. Also it is necessary to distinguish rhetoric regarding the virtues of selflessness in volunteer communities from the reality that self-interest should be cultivated within a volunteer community for the survival and health of the community to engender symbiotic win-win relationships within networks of companies and individuals that would not come together to share their best ideas with each other otherwise. Intellectual property rights continue to be an area of strategic interest for PMI volunteers.
Lessons Learned 1999
Not every volunteer is a good leader in a volunteer and virtual environment. The skills required are very good communication, good facilitation, and motivation. Also conflicts must be managed, and standardized work-methods must be enforced.
Changing the rules of volunteer protocols leads to project delays. The introduction of copyright assignments caused a significant delay in the project.
Without full-time support, basic processes to manage a volunteer project of this magnitude cannot be implemented successfully. The administration of the volunteer workforce requires a lot of attention.
Projects that involve volunteers in a wide variety of industries, with a wide variety of perspectives, require constant attention from the leadership team to keep the plans, teams, and discussions focused on the vision and objectives of the project. Everyone must be reminded constantly to “keep the main thing the main thing.”
The team was organized into a structure that allowed a large group to function as small teams that could act rapidly and with agility. In order for distributed operations of this sort to function successfully, power must devolve to the smaller teams, and they must be inter-connected so they can communicate effectively with each other. Other elements that are necessary in order for a project or program with this organization structure to succeed include:
- a shared situation: all parties in the collaboration need a shared view of the situation, but not necessarily a complete set of shared data
- shared plans and goals: by knowing each others plans and goals, alternative ways to avoid conflicts while still satisfying the goals can be explored
- shared solution process: a collaboration requires a protocol agreement, or “rules of the road” for establishing how the collaboration will be conducted, including definitions of privilege and responsibility for communication and action
- a communication mechanism: suitable for communicating the shared situation, shared plans and goals and shared solution process
Lessons Learned 2000
In a volunteer environment, high turnover is common. Job requirements change, family lives change, and world events cause changes in the ability of volunteers to participate. The virtual environment exacerbates the problem because team members are not co-located, which makes co-ordination more challenging, and keeping workers present and focused is immensely difficult.
In the OPM3 project, the work was complex and abstract at first, and many volunteers did not understand how the model would come together in a tangible and useable form until Q1 2003. It is much easier to explain the model now that it is developed, but it was difficult to keep the workforce enrolled in tightly pooled, interdependent, and conceptual work that often required rework. Many volunteers were not used to this kind of work, and they did not see sufficient progress in their efforts. This too caused turnover.
The OPM3 project was essentially a research project, much like a quest. To scope the project's work accurately in the beginning was simply not possible because research revealed important facts that needed to be implemented in the standard. The solution was not evident in the beginning, and initial problems were resolved with solutions that introduced new problems in a manner that unfolded, requiring team members to cope with ambiguity throughout the creative process. Each time a new challenge arose, the volunteers had to be rallied by the leadership to the new challenge, unlike a paid workforce that can be redirected much more easily. The virtual environment made this even more difficult because all communication occurred electronically. Email or documentation does not allow real-time discussion, and it is difficult to gauge team dynamics on a phone. Developing and maintaining a schedule under such conditions was hardly possible.
For all of these reasons, it was difficult for the project's leadership to manage the expectations of the team's sponsor and to manage the team's relationship with the public, whose anticipation for the model was growing. The leadership was under constant pressure to protect the team from outside forces, negotiate the scope of work and timetable for delivery, and manage the image of the project.
Lessons Learned 2001
Adapting the organisational structure of the project team to reflect the focus of new tasks must be balanced with the need to maintain a semblance of continuity in a virtual environment. Virtual teams are more sensitive to changes in the environment than non-virtual teams.
OPM3 volunteers were highly motivated by the invention of organisational project management processes and other innovations. To keep the motivation up, regular telephone conferences and face-to-face meetings are important.
A virtual and volunteer project without administrative support is like an engine with sand in the gears. It does not work well, and eventually it will stop working altogether. While administrative support is not a glorious job, it is critical to the success of the project. The support can be provided by a dedicated volunteer or PMI staff member.
It is important to keep world politics out of project communications. Even this is difficult from time to time.
Lessons Learned 2002
Human resource processes, such as training, recognition and awards, and resource planning are very important for virtual projects. The InReach training series demonstrated the fact that while people can be told, they must be allowed to learn for themselves and must be given time to experience what they have learned.
Good planning, documentation and standardized processes allow for continuation in case the leadership changes. Succession planning is essential for volunteer projects.
Descoping hurts, but is necessary for project success. Descoping is the opposite of discovery. In the early phases of a large project, the project has to accept uncertainty, and often discovers additional activities it must perform. Later as completion dates near, the project may have to remove such discoveries from its scope in order to meet its expected completion dates. In the case of OPM3, improvements can always be made in successive versions of future releases.
Lessons Learned 2003
The lessons of 2003 are many, but a few stand out. First, on a project of this duration, wear and tear on the leadership is extensive. Attrition continued toward the end of the project, and the team benefited from aggressive succession planning. On a volunteer project, any time the knowledge of a critical system or activity resides with one person, there is an extreme risk to the project.
Second, even in the final phase of the project, we found that we still struggled to maintain a strong schedule which was both meaningful and yet relatively non-intrusive. The introduction of an aggressive but even-keeled master scheduler allowed us to keep the project schedule under tighter control without inhibiting the teams.
Third, 2003 was further confirmation of the need for repeated face-to-face meetings as the best and sometimes only way to ensure complete team alignment. Again and again the face-to-face meetings were pivot points in moving past seemingly impossible issues. Idea generation and problem solving in these meetings was far superior to teleconferences, no matter how well crafted the calls were.
One very last, but very important lesson learned is that a research project by nature should not be executed as a standards project. Research projects require a different planning and execution strategy and they are more difficult to manage with a volunteer workforce. In general, practitioners are getting frustrated by the amount of rework a research project requires. Also, the scope of a research project changes as new facts are discovered. Standard projects are much more based on industry practices and less on discovery. Industry experts have to agree on common practices and publish them. Scope and schedule can be easier maintained and less rework is required and consequently fewer frustrations occur. OPM3 became a real standards project in its final year. Before this, it was a research project, discovering the fundamentals of organizational project management.
1 The PMBOK® Guide was later approved by the American National Standards Institute as ANSI/PMI 99-001-2000,
2 Stan Rifkin had worked at the Software Engineering Institute for several years, reporting to Watts Humphrey, and he was the co-author of Software Engineering Process Group Guide, considered a seminal work on how to establish and sustain a group (the SEPG) whose function is to serve as the organizational focal point for software engineering process improvement.
3 Bredillet, C., Cooke-Davies, T., & Schlichter, J. (2001, November). Beyond the PMBOK® Guide, Proceedings of the Project Management Institute Annual Seminars & Symposium, Nashville, Tennessee, USA.
4 Dr. Terry Cooke-Davies was known then and is known now for establishing knowledge networks composed of corporations that share data to discover, share, and create knowledge about project management.
5 Bredillet, C., Cooke-Davies, T., & Schlichter, John. (2001, November). Beyond the PMBOK® Guide, Proceedings of the Project Management Institute Annual Seminars & Symposium, Nashville, Tennessee, USA.