PM World Today Letters To The Editor

Editor's Note: Craig Curran-Morton's Viewpoints Column in the September-October 2004 PM World Today "Beyond OPM3 Hype: A Reality Check" resulted in a dialogue between Craig and John Schlichter. Reference http://www.pmforum.org/viewpoints/2004/0910beyondopm3hype.htm This letter is a continuation of that dialogue.

John writes...

Craig, I interpret four main points in your open letter to me in response to my observations on your article. Those four points are:

The High Level Assessment drives everything else. OPM3's capability assessment (Appendix E) provides little, if any, evaluation criteria for evaluating each capability. Organizations are unlikely to develop OPM3 assessment instruments other than what is provided within OPM3 by PMI today. OPM3 does not explain how organizations can enact strategies through projects.

Because I rebutted point number one (above) at length in my previous observations that are already posted at http://www.pmforum.org/viewpoints/2004/0910beyondopm3hypereply.htm, I will not address that point further.

I rebutted point number two more concisely, so I will repeat that concisely as follows: the criteria for evaluating whether or not a Capability exists is defined in OPM3 in terms of the Outcomes that one should expect from each Capability. You evaluate the Outcomes to determine that a Capability exists, and if the Outcomes do not exist then the criteria for concluding the Capability exists have not been met. Likewise, for each Outcome, OPM3 specifies the criteria for evaluating an Outcome in terms of the 'Key Performance Indicators' (KPI's) that one should seek when evaluating whether an Outcome has been produced by a Capability. If the KPI's are missing, then one should not conclude that the Outcome has been produced. Furthermore, each KPI is explained in terms of specific Metrics. I do not view this as "little, if any, evaluation criteria.'

The third point of the four above refers to your statement that you are unable to imagine many organizations taking the time and energy to come up with another assessment instrument (other than what is provided within OPM3 by PMI). A few already exist. Having said that, I am unable to rationalize a need for 'many' OPM3 assessment instruments, but that is up to and shall be driven by the market. Consider what happened in the development of SEI's CMM's. Numerous CMM assessors, including one of my previous employers, developed their own tools or instruments for performing CMM assessments, and many of these tools are available publicly for purchase. The original SEI CMM did not even include an assessment methodology aside from a simple questionnaire, which was retracted and replaced.

The needs and requests of users in the marketplace resulted in things like certification of CMM assessors, norms for performing CMM assessments, and myriad commercial instruments for CMM assessments. This took time. Like SEI in some ways, PMI has published an initial summary questionnaire (High Level Assessment tool) with their maturity model. Like the original CMM marketplace in some ways, additional OPM3 assessment instruments have been developed. For example, my firm OPM Experts, LLC http://www.opmexperts.com is developing an improved OPM3 Assessment tool now, addressing both the needs of users whom we have encountered and the criticisms of OPM3 from OPM3�s competitors. Like the market that developed via SEI's CMM for the assessment of software development capabilities, the market that is developing via PMI's OPM3 for the assessment of organizational project management capabilities is unlikely to go away, and critics are among the most diligent among those advancing the improvement of such standards.

As regards the fourth point, you have repeated your assertion that OPM3 does not explain the link between business strategy and projects. In particular, you wrote 'Having a handful of capabilities (�) does not provide the user with a clear link to choosing the right projects or bridging the gap between projects and organizational strategy.' The rest of my response below summarizes how OPM3 does explain the link between business strategy and projects, and how it does so with much more than a handful of Capabilities. �Organizational project management,� states OPM3, �is the systematic management of projects, programs, and portfolios in alignment with the achievement of strategic goals. (�) There is a correlation between an organization�s capabilities in Project Management, Program Management, and Portfolio Management, and its effectiveness in implementing strategy.[1]

Projects are temporary endeavors undertaken to achieve goals. An organization can achieve its strategies by both designing projects intended to produce the changes necessary to achieve strategic goals and delivering those projects successfully. Originating and prioritizing the correct projects is largely a Portfolio Management activity. Initiating, planning, executing, controlling, and closing those projects is a Project Management activity, and if there are multiple projects managed in a coordinated manner, that's Program Management. OPM3 shows how to use initiating, planning, executing, controlling, and closing processes to manage projects, programs (which are comprised of projects), and portfolios (which are comprised of programs and/or projects).

The correlation between an organization's capabilities in Project Management, Program Management, and Portfolio Management, and its effectiveness in implementing strategy is simple: choosing the right projects and delivering them successfully through capable processes equates to implementing strategy through projects. The concept is simple enough, but putting the concept into practice is more challenging. Fortunately PMI�s OPM3 explains the concept of initiating, planning, executing, controlling, and closing portfolios, programs, and projects in great detail, specifically in terms of 39 processes.[2] OPM3 defines the Best Practices for making these processes capable (so projects are both designed and delivered successfully, consistently, and predictably). In elaboration of these Best Practices, OPM3 specifies at least 1,521 constituent Capabilities delineating all aspects of making the processes of initiating, planning, executing, controlling, and closing portfolios, programs, and projects capable.[3] Within the 500+ Capabilities dedicated to Portfolio Management alone, a few are particularly obvious as essential to the strategy-project link because they emphasize 'choosing the right projects,' and I referenced these in my previous observations at http://www.pmforum.org/viewpoints/2004/0910beyondopm3hypereply.htm.

Whether we consider the total universe of OPM3 Capabilities (2,109) or those defining how to make capable the processes for choosing the right projects and delivering those projects (1,521) or simply those Capabilities pertaining to part of the equation like Portfolio Management (500+), we are talking about considerably more than a handful. Which aspects of the strategy-project link are missing in OPM3 in your view?

In closing, you could not have been more correct when you wrote the following to me: 'given that you were one of the key developers of the OPM3, you have a great deal of background into the development of the product and why it was moulded the way it was. The average user of the product does not and really should not need to know this information to use the product successfully.'

John Schlichter

[1] OPM3, p. xiii
[2] Whereas the following processes are defined for Project Management in PMI�s PMBOK Guide, the OPM3 dedicates 42 pages to distinguishing how the following processes work within Program and Portfolio Management: initiation, plan development, scope planning, scope definition, activity definition, activity sequencing, activity duration estimating, schedule development, resource planning, cost estimating, cost budgeting, quality planning, organizational planning, staff acquisition, communications planning, risk management planning, risk identification, qualitative risk analysis, quantitative risk analysis, risk response planning, procurement planning, solicitation planning, plan execution, quality assurance, team development, information distribution, solicitation, source selection, contract administration, integrated change control, scope verification, scope change control, schedule control, cost control, quality control, performance reporting, risk monitoring and control, administrative closure, and contract closeout.
[3] The total number of Capabilities defined in OPM3 is 2,109, but the number defining how to make the organizational project management processes capable (via standardization, measurement, and control) is 1,521.

The PMCONNECT posting about Dr.Shan Rajagopal and David Hawkins - On Linking Military Strategy and Project Management

I am responding to the PM Connect posting about Dr Shan Rajagopal and David Hawkins linking military strategy with project management. This is a deserving point of interest. I wrote a paper for PMI S&S a couple years ago that included some of my opinions about this link, and as a matter of fact I included these opinions even though I considered them not something most people would appreciate (and possibly averse to my own business development), but there is much worth studying on this topic. In fact, as the program manager of OPM3, I recieved some criticisms for exploring this topic instead of focusing plainly on OPM3. But now I see this topic being explored again, and that's good.

Whereas less progressive command-and-control techniques of management evoke the image of a captain at the bridge of a ship giving commands that are passed down the line to guide a lumbering vessel through the storm, the newer paradigm of Organizational Project Management invites metaphors describing the coordinated movements of a flock of birds fluidly responding to environmental conditions.

It is interesting to note that this kind of organizing strategy has been recognized for its effectiveness by military strategists. In "Swarming and the Future of Conflict," written for the US Office of the Assistant Secretary of Defense (Command, Control, Communications and Intelligence), within the International Security and Defense Policy Center of RAND's National Defense Research Institute; John Arquilla and David Ronfeldt describe "swarming" as a seemingly amorphous but deliberately structured, coordinated, and strategic way to act from all directions. It is designed mainly around the deployment of myriad, small, dispersed, networked maneuver units. Think "projects."

This method of organizing requires a profound shift away from command-and-control organizational structures to much more agile and adaptable, temporary organization structures. Critical success factors for this new organizing strategy are the devolution of power to small units (teams) and a capacity to interconnect those units so they can communicate effectively with each other. This "strategic way to act from all directions" is similar to creating a shared model of intent and maintaining a dynamic belief hierarchy including uncertainty and information fusion, as described in the analysis of air operations as a distributed problem space (a collaborative decision environment) in Paper 1999-01-5538 "Shared Plans and Situations As a Basis for Collaborative Decision Making in Air Operations" written by Norman Geddes and Carl Lizza for the 1999 World Aviation Conference.

Geddes and Lizza describe requirements for collaboration in distributed operations, emphasizing several shared elements of knowledge and information: the 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. While a central operations site can still set the overall operations picture in terms of situation and operational plans, the detailed planning and execution of the sub-elements of the operational plans are left to the distributed components. This permits the best local information about conditions to be combined with centrally maintained, wide area information in making operational decisions. A second important feature of distributed systems is their ability to scale up. Since the responsibility to satisfy new needs is distributed to the components, the workload of the central operations site is not strongly affected by the addition of components.

Yet two important issues confront distributed systems. The first is the communication of information between the distributed components. The second issue is the coherence of the system with respect to its activities. By coherence, Geddes and Lizza mean the extent to which all of the activities intended within the system are mutually supporting and free of conflict, both in the present and into the future. In distributed systems, it is important to guard against local decisions that appear benign, but that actually create major conflicts within the overall system. Shared situations and plans provide direct support for distributed collaborative operations. Shared situations and plans permit a network of associates to manage information flows and provide coherent activity across the system. While centralized control architecture emphasizes the pull of all raw data to a central site for processing, a distributed system of associates emphasizes local data processing with a push to others of only the relevant information. Each distributed associate uses the local data available to him to compute aggregated and abstracted conclusions about the situation, which can be sent to other collaborating associates. Each associate also receives relevant situation conclusions from others, building a shared situation model across the distributed collaborating set. The distributed situation assessment process has built into it the algorithms for maintaining a dynamic belief hierarchy, including uncertainty and information fusion. Each associate shares a situation knowledge base that allows it to capture the meaning of a shared situation provided by another associate. Shared plans refer to how the distributed network of associates is also capable of forming highly coherent shared plans in a collaborating manner. Each associate has a shared set of knowledge for planning and a set of planning responsibilities. The planning process is represented as a hierarchy of sub-plans and sub-goals, permitting some of the associates to be responsible for higher level, more abstract plans and goals, while others are responsible for detailed planning about specific operations within the abstract plans. Each associate can share the contents of their plans with other collaborating associates, resulting in a large, distributed shared model of intent, with complete synchronized local copies at each associate.

The shared model of intent is dynamically monitored for changes and conflicts, which can result in rapid adaptation of existing plans or the creation of new plans. The communication of shared situation and shared plans between distributed associates is highly efficient because it is highly tokenized. This is possible because the collaborating associates share the same knowledge that defines the meaning of the tokens. It is not necessary that all associates be identical in operation or construction, but they must share the same knowledge content. In addition, the communications between associates is asynchronous and managed, rather than a periodic broadcast. The sharing of situations and plans only occurs when there is a change in the situation or plans that is worthwhile sharing with others. The depth of detail that is shared is also managed, so that only those associates that are influenced by the specific levels of detail receive that level of detail. The management of the communications for both situations and plans is a knowledge based process itself, allowing the user community to determine what should be shared and with whom.

In my view, this is a fantasic strategy for management by projects to achieve organizational strategies. This "world view" is part of what shaped my own thinking significantly when leading the development of OPM3. In fact, I used many of these ideas when managing the global virtual team of OPM3 volunteers, which numbered in total 800 people in 35 countries. This stuff works, although sufficient challenges in stakeholder management involving superior powers can thwart any management idea (which is worth noting).

Regards,
John Schlichter
OPM Experts, LLC
http://www.opmexperts.com
404.252.4299