Where The Bodies of Knowledge Are Buried (& How Blockchain Will Resurrect Them) by John Schlichter

body4.png

Leading thinkers in the realm of project management gathered somewhat secretively in Virginia Beach in the year 2000 at a meeting hosted by NASA as part of an implicit attempt to broker agreement among the developers of the major project management standards across industry. The question was "What constitutes the definitive project management body of knowledge?" Secretive may be too strong a word because it was not a covert meeting per se, but it was named the "Operational Level Committee" precisely to make it sound uninteresting and to avoid attracting attention. More accurately, the "OLC" was the name innocuously given to the group a year earlier at the PMI Annual Symposium in Long Beach, California to reserve a room where plans to recruit a critical mass of intellectual influence peddlers was hatched. The anti-advertising worked, and half a dozen people sat uninterupted by interlopers in an unremarkable room making a remarkable list of invitees.

In Virginia at a much nicer facility, about thirty of those invitees showed up, including David I. Cleland, J. Davidson Frame, Max Wideman, Rodney Turner, Lew IrelandOlaf Pannenbäcker, Peter W. G. Morris, Christophe Bredillet, and me. I think Hans Knöpfel, Gilles Caupin, and Lynn Crawford may have been there as well, but my memory fails me, and there are many whose names I am forgetting. Described by one attendee as "the new blood," I was nearly half the age of anyone in this august assembly. I was breathing that rarefied air because I had been recruited to its milieu two years earlier by persons interested in having me develop the philosophical first principles of project management. As it happens I did not develop those principles. (We didn't get further than an initial principle that "A project does not necessarily need a project manager." An idea ahead of its time? Aspects of holarchy and heterarchy have since been adopted by Agile enthusiasts). Instead I agreed to investigate the possibility of creating a maturity model for project management that would be a PMI standard, and that endeavor took off quickly. I recommended to the 1998 PMI Standards Committee that we should create a maturity model for project-based organizations but that its purpose should not be simply to improve the management of projects in organizations. I asserted that its purpose should be to help organizations improve their ability to implement an organization's strategies through projects (which is quite a different thing), and I coined the term "Organizational Project Management" (OPM) to denote organizational strategy implementation through projects. This was a significant departure from PMI's direction to date. PMI's Executive Director asked me to create and lead a team to produce such a model (which I named "OPM3"), marking PMI's first step toward a "strategy implementation through projects" paradigm. Marketing that paradigm is PMI's dominant logic today, and countless consultants, academics, and authors have followed suit. Things were moving full steam ahead by the time I arrived at the OLC.

At the outset of the meeting in Virginia Beach, the point was made that the "body of project management knowledge" exists in many places, not least in the minds of practitioners like those gathered in the room and across the world. The best we can do is craft guides, summaries, or abstractions of the inherently dispersed and evolving body of knowledge. An exercise was undertaken wherein the attendees wrote the concepts of project management down on sticky notes, one concept per sticky, filling up a large wall, signifying our attempt at canvassing the project management body of knowledge. I suggested we make a copy of all the sticky notes and break into two groups of people so each group could organize the concepts on its own, and then we could compare results. Somebody near me immediately said "Organize this? That will never work." I said "Why not? Aristotle did basically the same thing with genus, species, and differentia." There was a collective shrug, and we set about organizing concepts.

The project management body of knowledge exists in the minds of practitioners across the world.
Screen Shot 2018-05-19 at 11.57.59 PM.png

The décollage stretching across the wall could have been interpreted in an infinite number of ways. Terry Cooke-Davies had showed up, and I suggested to him that it would be quite interesting to put the concepts from the stickie's into textual analysis software to reveal affinity groups. The next day he was genuinely angry with me for proposing that idea because it inspired him to stay up all night doing data entry despite the fact he'd enrolled nobody to help.

I was asked to present the results of the group that I had worked with. I explained our bottom-up approach of organizing the concepts in a way that allowed a structure to emerge without a preconceived design. Then Cleland presented on behalf of the other group and deadpanned "Our group created a structure top-down, which is very good because it was not bottom-up, which is vey bad." He looked at us impassively with just a hint of amusement.

Brokering a shared view of knowledge is a negotiation.

Needless to say, each group had produced something quite different from the other, and neither mirrored what the textual analysis software suggested. At the risk of emphasizing the obvious, that was the original quandary: knowledge is, phenomenologically speaking, intentional. Or said another way, knowledge is a matter of perspective. Brokering a shared view of knowledge is a negotiation, and it is not always pretty. To paraphrase, "Standards are like sausages. It's better not to see them being made." Flying thirty experts to a meeting hosted by NASA to decide what the project management universe looked like "once and for all," and thinking it would be any different from your typical sausage-making, was hubris.

It was not the last time NASA was involved in semi-secret knowledge management activities. A decade later I was invited to join the Federal Knowledge Management Working Group, a virtual community (which included people like me from the private sector) whose mission was to educate and support federal government departments, agencies, organizations, and their constituencies in the research, development, identification, and implementation of knowledge management activities, practices, lessons learned, and technologies. Members included David Bray, Jeanne Holm, John Bordeaux, Denise Bedford, Jimmie McEver, and many others. When Haiti was devestated by an earthquake, we were asked for creative ideas regarding how to coordinate the uncoordinated relief efforts speeding toward the island. Apart from random queries like that, we formed groups that explored how individuals and institutions can more easily distill knowledge from complexity and make policies and decisions using knowledge based processes. Some of us created standards for meta-data embedded in digital communications. We talked about how to preserve the knowledge of warfighters in Afghanistan when soldiers rotated out of service. We argued about the merits of tokenized communications used by airport control towers as a model for decentralized knowledge sharing, and what not. People asked questions like "How could simulation-scripting exercises in virtual worlds accelerate the development of the sustained use of ontologies in the real world? How might simulation-scaffolding ontologies, in turn, improve the pace and complexity of learning associated with large-scale modeling event scenarios and mission-rehearsals that are anticipated in virtual world settings? How can we leverage ontologies to help improve knowledge management, and in so doing, allow organizations to make better decisions?" I thought the group was sponsored by the US military but later discovered it was run by the FBI with support from the Secret Service and servers donated by - guess who - NASA. Organizations throughout the government and across the private sector are heavily invested in knowledge work and, by extension, in the codification of knowledge and development of standards that enable that work. This is the same phenomenon that fomented the OLC.

Power concerns itself with defining reality rather than with discovering what reality really is.

Meanwhile, the efforts of the OLC never produced a single definitive standard that integrated everyone's views about the project management body of knowledge. The IPMA had theirs, and PMI had theirs, which was published as a guide that ballooned to over 1,000 pages. Others have been proffered over the years. Such standards can have far reaching consequences, becoming the basis of individual and organizational certifications, shaping how organizations work (particularly how people from different organizations work together) across the world. As such, the creation of standards is a deeply political affair that may have as much to do with aggregating power as distinguishing prevailing practices. Bent Flyvbjerg has noted "Power concerns itself with defining reality rather than with discovering what reality really is." The major project management standards today are rather less the result of high-brow conclaves like the OLC and more the result of powerful business mechanisms, producing distillations of knowledge that take on lives of their own.

remember-accounting-and-accountability-nothing-in-common-new-yorker-cartoon.jpg

What it means to be a "standard" is something I addressed in another blog post by citing the example of roads. In ancient times, roads became de facto standards as the way that travel occurred, standards in reality by fact of widespread use. That is foremost what a standard is: the prevailing practice. Tacit knowledge of the paths taken by travelers was translated into explicit knowledge in the form of maps that codified popular routes. That too is what a standard is: a paradigm or framework whose authority is asserted. The standard practices of traveling known routes were accompanied by rules or standards de jure (that is, officially or by law) like weights, measures, and coinage that enabled commerce. That is yet another way of understanding standards, i.e. as abstractions contrived to enable interaction. Today, project management standards are an amalgamation of these things that begs the questions "This is the prevailing practice according to whom exactly? This knowledge has been codified by whom exactly? Its authority is asserted by whom exactly? And if a standard has been adopted as the rules of the game, they are the rules according to whom?" Fundamentally these are all questions of trust. Power-brokering is trust-brokering, a proposition that is undergoing a sea change for technological reasons in the 21st century.

Blockchain can bring trust back to standards creation.

Today the International Standards Organization (ISO) requires those bodies it endorses as developers of standards to develop their standards in a transparent and fair manner that ensures open consensus building. But one wonders how it assures that this occurs? One may note that organizations pay money to ISO to be endorsed by ISO as accredited developers of standards. Emerging technologies like blockchain can improve trust in standards creation. Blockchain could introduce full attribution not only of individual sources but of individual votes by individual persons to include specific content in a standard (both for and against), which could transform how an entity like ISO could accredit standards development. It could fundamentally change the nature of standards like PMI's "A Guide to the Project Body of Knowledge" (which is updated every few years by a cast of hundreds if not thousands of volunteers). It could also change how standards are published, extending to the decentralization of copyrighting.

Certified assessments of the adoption or application of a standard by an organization could be viewed as transactions that are reconciled to the original standard itself. Specific records of adoption of a practice (or failure to adopt a practice, as the case may be in any given third party assessment) could be embedded in the published standard dynamically, demonstrating whether the standard (or any part of it) is indeed a de facto standard. With data on usage embedded into the standard, we could see which parts of the standard are used most, i.e. Pareto. We could see which kinds of organizations and users use different parts of the standard, i.e. consumer segmentation. We could compare usage (or lack thereof) to performance problems, i.e. effect stratification. And we could update these and many other dimensions dynamically, refreshing the standard with value-added information in keeping with the real world. Importantly we could cause this updating to occur without the intervention, filtering, or meddling of powerful knowledge-brokers who should recuse themselves.

phronesis.png

To the larger point, with emerging technologies we may be able to solve the problem that the OLC encountered in Virginia Beach nearly 20 years ago and which every effort to establish a standard since then has faced. That is, we can distinguish discrete knowledge from shared knowledge; demonstrate the extent to which any knowledge is shared; provide views of knowledge standards that are most relevant to different parties; update knowledge-based standards automatically with usage data - avoiding Orwellian dystopias like China's social credit system by applying Phronesis methodically; and in doing so, we can bypass centralized authorities or gatekeepers (whose own views of the situation are perforce limited and biased). Through technologies like blockchain, we can add new knowledge like links added to a chain, improving knowledge for all of us with each link in an ever-growing circle of trust. Knowledge in the respective minds of practitioners that may have been buried in backroom battles can be resurrected, and the playing field can be levelled. The highly political and esoteric standards-making machinations of the few can be traded for truly transparent and decentralized knowledge creation by the many. And we don't need to be NASA's rocket scientists to realize that these things would improve the universe of project management for all of us.

 

 

 

My First Project & The Velvet Revolution by John Schlichter

by John Schlichter

For the people of Czechoslovakia, Christmas came early in 1989 when the communists were quietly overthrown. I arrived just in time for the first free elections since 1946 as the Prague Spring resumed on the heels of my eighteenth birthday to lead the first project of my career in a program named “English for Democracy." Unlike repetitive operations that produce the same thing over and over, a  project is a temporary endeavor that produces a unique result: an adventure, if you will. This was no exception. As the wall came down in Berlin, and Slovakia seceded from its Bohemian cousins to the north, I delivered my project to deploy the first English classes by American teachers to the liberated Czechs and Slovaks.

The invasion by the Soviets twenty-two years earlier had been a nasty business, tanks rolling through the streets. Yet they were gone without a fight in '89, overthrown by mere students. It was called the "Velvet Revolution," the gentlest reversal imaginable, a feat of quiet resistance perfected in subordination to the Hapsburgs and later the Germans long before the Soviet regime. Stalinism, an era when workers pretended to work and enterprises pretended to pay them, was out. Capitalism was in, and everyone wanted greenbacks. The banks were limiting currency exchange, but you could get them on the black market at a rate of 30 korunas per dollar, which could buy plenty of Russian champagne in those days.

And where was this black market? Everywhere. I would walk down the street, and it would materialize as soon as I donned a New York Yankees baseball cap, the universal sign for "American," igniting the eyes of budding entrepreneurs. "Change?" they would ask.

A currency peddler confided in me "I don't want to do this forever."

"Do what?" I asked.

"Change" he said, as he exchanged his currency for mine. The unintended pun was not lost on me.

So much had changed, and it was only the beginning. I had skipped my high school graduation, packed a bag, and headed to the Eastern Bloc where students my age had led the revolt against the Soviets in Czechoslovakia. My first stop? Žilina, where my charter was to connect with a tourist agency and establish an ESL school.

1.jpg

The project's strategy was simple. A tourist agency was the perfect location to set up shop because it could arrange for students to travel from every corner of Czechoslovakia and across the border to adjacent countries. English was the language of democracy and opportunity, and people from anywhere in the country could come learn it in full immersion trips around the region. At first I held classes on a balcony of the tourist agency, overlooking a town square where the bust of Lenin was removed. Within a month I had over fifty students living with me, undergoing immersive training. As it grew, we had to move into a football stadium. I would lead busloads of students on road trips across the border with Yugoslavia, where Soviet rule was quickly unraveling. Communist soldiers would inspect the buses and scowl in disapproval, but they couldn't stop us.

2.jpg

These were the streets that gave us Franz Kafka, the literary icon of modernism, a German-speaking Czech Jew whose narratives depicted isolated protagonists in surrealistic predicaments. I could relate, running my project against a bizzare backdrop of clashing political systems giving birth to new realities.

3.jpg

In Prague there were something like 50 different political parties as soon as Communism fell. Each party was designated by a number. They displayed their numbers in windows on Wenceslas Square.

#7 won a majority.

Leading up to the election, I taught people what it meant "to vote." They looked at me with wide eyes, having never experienced democracy before, much less a republic. I realized how much I had taken for granted in America.

4.jpg

Graffiti broadcast the prevailing memes: Havel, OF, and 7.

"OF" (party #7) stood for "Občanské Fórum," which meant "Civic Forum." It was a political movement whose purpose was to unify the dissident forces in Czechoslovakia and to overthrow the Communist regime. In this, they succeeded when the Communists gave up power in November 1989 after only 10 days of protests.

Playwright Václav Havel, its leader and founder, was elected president on December 29, 1989. I watched firsthand as the Forum campaigned successfully during March and April 1990 in what were the first free elections since 1946. In that moment, the separate nations of Slovakia and the Czech Republic were born.

tower.jpg

Currents of political change spread across the region as surely as the Vltava (or Moldau, to use the German name) washed through Prague before continuing to the Elbe and eventually the North Sea.

6.jpg

Images of past lives hidden for half a century ermerged in stoic forms. Without a word, this man sensed I wanted to take his photograph and nodded approval. His hat said "Salvation Army." The Communist Party had banned its activities in 1950 and imprisoned its members. This was the first time the uniform had been seen on the streets of Prague in 40 years.

7.jpg

A couple of long haired Rottweilers sat for their portrait as well.

8.jpg

The astronomical clock in Prague's Old Town Square, first installed in 1410, faithfully recorded Prague's march into a new era. A figure of Death (represented by a skeleton) struck the time. According to local legend, the city would suffer if the clock fell into disrepair; a ghost mounted on the front is said to nod its head in confirmation.

9.jpg

Some students took me into the hills. At a cabin, we sat in a sauna, then jumped in a frigid lake, as was the custom. Then they took me to a vast underground cave that opened up into a natural cathedral where people from far and wide had come to congregate.

12.jpg

Back in Prague days later, as if responding to a dog whistle on a frequency that only they heard, people poured into the streets in seconds, converging en mass from every direction in one of many gatherings that puncuated the revolution.

11.jpg

Crowds filled the public spaces.

14.jpg

At one point, there was a commotion. Everyone ran and hid as soldiers marched past us. There was a feeling in the air that anything could happen.

16.jpg

The old made way for the new.

15.jpg

Castro said we were American spies, which made me laugh. It was in the newspapers. I was pretty sure Castro thought all Americans anywhere were spies.

17.jpg

We were just people who supported the inevitable changes happening all around us.

19.jpg

Citizens celebrated, like these fiddlers under the Charles Bridge.

21.jpg

Memorials were erected to the fallen.

22.jpg

A sense of normalcy returned. At the end of the work day, men would huddle in bars just off the railroad platforms and drink beer in silence while waiting for their trains. Throughout the country, there was only one brand of beer, Pilsner, named after Plzeň, a place in Bohemia where it was first produced in 1842 when the Czech Republic was still the Austrian Empire. A recipe perfected for over a century, Pilsner may have been the one instance when having only one choice, a scarcity indicative of Communisim's central planning, was good enough.

23.jpg

Our full immersion classes continued, taking students on trips across the border to Budapest for example, where the people were afraid to have their photographs taken. While I was there, the Soviets withdrew, moving 100,000 personnel out of Hungary on 35,000 railway cars before the first free parliamentary election was held in May of 1990.

25.jpg

At a bookstore some customers discovered I was there to establish an English language school, one of the first in the country. So few people knew how to speak English back then that running a project to teach it to them gave me quasi-celebrity status. They saw I was holding a book of paintings by Albín Brunovský, widely considered one of the greatest Slovak painters of the 20th century, and offered to take me to his house to meet him.

26.jpg

Brunovský's son imparted to me a limited edition lithograph created and signed by Albín. It was titled "Labyrinth of the World and Paradise of the heart V - War."

var.jpg

The month I arrived in Czechoslovakia marked the novaturient beginning of the end of Soviet rule in Yugoslavia. Refugees flooded Prague, Bratislava, and Zilina with uncertain faces. And more change was coming, tracing its way down the Danube, galloping headlong into a melee of bullets careering across Zenica and Brcko. Havel said "Isn't it the moment of most profound doubt that gives birth to new certainties?" More than 200,000 people would perish before peace returned to Bosnia. But in the Spring of '90, at least for a brief moment, Wenceslas Square glowed in illecebrous wonder, and all was right with the world.

Having established a national network of contacts, I had designed and deployed the classes that were the product of my project. I trained my successor, and we declared the project a success, the first of many project adventures to come. Although some projects are more of an adventure than others, and one's first project may not involve the birth of a nation, every project produces something new and unique. In a world where the pace of change is increasing dramatically, projects are condiciones sine quibus non, essential ingredients of the future. You can be certain that a project awaits you nearby. Are you ready for it? Where will it take you?

Simple Rules for Project Cancelation by John Schlichter

by John Schlichter

In any organization with many projects, although control mechanisms are created explicitly and often in a centralized manner, the projects must adjust and adapt to each other, creating new systems and subsystems that exhibit a degree of self-organization enabled by the adoption of simple rules, customs, and rituals by project teams. Simple rules create the possibility of behavior that is independent in detail and governed by higher organizing principles, i.e. emergence.

An example of an area where simple rules help in project-based organizations is project cancelation. In this context, rules are heuristics or guidelines and are not intended to do the thinking for you or to act as a replacement for the consideration and wisdom of leaders. Here are five simple rules that OPM Experts LLC created recently for a client through a one-hour facilitated working session:

1.     We will suspend or terminate the project if there is a change in the market or competitive landscape.

a.     “Change in the market” is defined as

i.     developments indicate the demand for product(s) of the project has declined to the extent that the business case is no longer valid

ii.     the external environment has rendered our strategies nonviable

b.     “Change in competitive landscape” is defined as

 i.     the state of rivalry has made competing in this space undesirable

 ii.     changes in supplier power or customer power make product development too difficult

 iii.     or new entrants and/or substitutes invalidate the business case.

The <insert name of person or team here, e.g. Vertical Marketing Leader, Product Management Team> will proactively monitor these parameters, which will be reviewed at each stage of the project.

2.     We will suspend or terminate the project if there is a negative change in the forecasted financial benefits.

a.     Forecasted product cost target or capital target degrades, e.g. 10% degradation.

b.     Forecasted ROI, Payback, NPV, Revenue degrades.

c.     Forecasted savings degrade.

d.     Sourcing supplier challenges increase forecasted costs.

These parameters will be evaluated monthly.

3.     We will suspend or terminate the project if the forecasted delivery date is delayed substantially from what had been agreed.

a.     Upon presentation of feasibility studies, the forecasted delivery date is unacceptable.

b.     Upon presentation of business requirements, the forecasted delivery date is unacceptable.

c.     Upon approval of functional requirements, the delivery date that was forecasted upon approval of business case or business requirements is no longer within a quarter of the target.

d.     At approval of final testing results, if the project closure date that had been forecasted upon approval of functional requirements is now forecasted to be delayed an additional three months, the project will be evaluated for suspension or termination.

4.     The project will be suspended or terminated if it becomes technically infeasible or if a failure in testing reveals high impact risks that cannot be mitigated or transferred.

a.     “Technically infeasible” means the functional requirements cannot be delivered within the constraints of the business requirements. 

b.     “High impact risks” are risks that could harm the customer or the company.

5.     The project will be suspended or terminated if resource bottlenecks invalidate the business case.

a.            When evaluating any project for suspension or termination, we will consider whether allocating resources to other projects creates a more optimal portfolio.

Simple rules like these provide a straightforward way for people to align their thinking and action-taking. They empower individuals by improving one’s ability to pursue problem solving creatively within a shared view of the situation. And as always, the litmus test for any rule is simply “Does it work?”

Review of Kerzner's "Using the Project Management Maturity Model: Strategic Planning for Project Management" by John Schlichter

by John Schlichter

A couple years ago, an editor at John Wiley & Sons enrolled me to provide written feedback for a potential new edition of Using the Project Management Maturity Model: Strategic Planning for Project Management by Harold Kerzner.

Maturity Model

I am not sure, but I do not think they moved forward with a third edition after my critique.

Here are the questions they sent me and the answers I provided.

Reviewer Questions

1.      Does the material in the current edition seem to cover the major topics considered important in the field?  Do any subjects appear to be too lightly covered?

No, the book does not seem to cover the major topics considered important in the field. Kerzner’s maturity model does not make sense. It is a 5 stage model. Stages one through three are essentially “standardization,” but he decomposes this as “common language” (level 1), “common process” (level 2), and “singular methodology” (level 3). Then he jumps to “benchmarking” (level 4), followed by “continuous improvement” (level 5). Historically, many maturity models have taken the 5-level approach, but this is typically a decomposition of statistical process control into “levels” or agendas. Statistical process control results in process capabilities. For this to occur, processes must be standardized (levels 1 through 3 in Kerzner), and then they must be measured, i.e. metrics unique to critical characteristics of processes must be collected and analyzed, and these critical characteristics may differ by organization depending on what is strategic to the organization. This is followed by implementation of control systems, then followed by continuous improvement once processes are “in control.” Kerzner’s model conflates measurement with “benchmarking” and then skips the control agenda entirely, leaping to continuous improvement. Benchmarking in this context does not address process capability, i.e. Cpk. Indeed, there is no reason why benchmarking itself should not occur much earlier in the model (as companies can learn much from each other pertaining to standardization). In short, the model is arbitrary, does not include aspects essential to development of process capabilities, and suggests an order to practices in a sequence that is questionable.

2.      Which chapters would be most valuable to you? Least valuable?

The case studies seem least valuable. This is due primarily to two issues: 1) the cases are not clearly tied to implementation of the maturity model, and 2) the underlying maturity model itself is flawed.

3.      Is the sequence of chapters appropriate?  Should any chapters be deleted or combined in a revised edition?

The sequence makes sense, but there are many flaws and gaps.

The author claims there is a direct correlation between project management competency and a company’s stock price.  This is a bold claim, but is not supported by any evidence.

The author repeats that there is a need for “strategic planning for project management.” However, it is not clear what the author means. Does this mean that a company’s strategic plans need to be translated into projects? By contrast, does this mean one needs to plan strategically how project management will be developed as a competency? The author transitions unclearly between these two related but distinct points.

The author states “strategic planning for project management is the development of a standard methodology for project management.” This makes no sense. Strategic planning is development of a project management methodology?

4.      Please comment on the Best Practices portion of the book. Does it need updating?

Yes. See the answer to question #1 above.

5.      Please comment on the case studies. Are they useful? Can they be applied across industries? What industries would you like to see represented in a revised edition?

No. See the answer to question #2 above.

6.      From the material available, what appear to be the major strengths of this book? Do you have any reservations about the proposed material?

The book’s flaws overshadow the material as a whole. Yes, I have significant reservations, per the answers provided above. In addition to those reservations, the following are some minor points:

  • The concept of maturity is not defined clearly in the book.
  • Nortel may not be the best example to give to describe an organization that is implementing the model. It is said that Nortel was at stage one (lowest maturity), and as we know, they filed for bankruptcy.
  • In chapter one, the author claims that historically speaking, executives resisted viewing project management as a core competency because doing so required decentralization. This claim is unsupported.

7.      Are you familiar with other books on this topic? Which appear to be most similar, and therefore, most competitive with this proposed volume?  Do any of them provide anything that this proposal could, but does not?

PMI’s OPM3 is the leading book on this topic. In terms of things it provides which Kerzner’s does not, see the following:

8.      Please comment on the audience for this book. Do you think a new edition will be widely accepted by academics? Does it have a place with practicing professionals?

I do not think a new edition will be widely accepted by academics. There may be a small audience among practicing professionals, as Kerzner’s name is known and respected within PMI.

9.      For what courses have you used this book/would this book be suitable?

Course Name

Course Type (core or elective)

Course Level (Freshman, Sophomore, etc)

Size of Class

          N/A

10.    What sort of electronic ancillary products (web-based instructor’s manuals, test banks, lecture slides) would you expect to accompany this book when published?

If Kerzner is going to claim that there is a correlation between project management maturity and stock price, I would expect him to back this up with data.

11.    Would you adopt this title for any courses you teach? (Hypothetical)

No, I would not.

12.    If published, what would be a fair price for this work, based on the price of comparable books currently available?

I do not know.

12.    Are there any thought leaders on this topic to whom you are paying attention?

"Like John Schlichter?" he said with a wink.

An Exponential Future Is Accelerating Toward Us by John Schlichter

by John Schlichter

An exponential future is accelerating toward us, and projects, those temporary endeavors that create knowledge and deliver change, are the management paradigm for thriving in that future.

In this complex, volatile, and uncertain world, project teams form to meet changing needs. Teams are composed of personnel who span traditional corporate and agency boundaries as ephemeral networks.

Project teams span departments, business units, supply chains, and persons who may represent other organizations or themselves as individuals peer-to-peer.

The teams come together when a project starts and disperse when a project finishes, and while this has the advantage of endless adaptation it subsequently creates the problem of knowledge loss as team members depart.

Knowledge necessary for the problem solving inherent to projects must be captured, codified, and internalized as standards for networks of projects to implement strategy capably over time.

The trick is learning how to develop those standards without creating fossilized bureaucracies and the inability to adapt to changing needs.

In June 2010, OPM Experts organized a summit on this topic, described in the video below.

In March 2011, we held a symposium on the same subject at Emory University, sponsored by the Claus M. Halle Institute for Global Research and Learning. It was described in an agenda titled "Knowledge Futures."

Nearly a decade later, the same questions framed in this ongoing inquiry have never been more pressing. Are you interested in participating in a follow up symposium on these topics? If so, contact us.

 

PROJECT SPONSORSHIP AND RISK - A Better Alternative to Escalation by John Schlichter

chess-strategy.jpeg

by John Schlichter

PMI has adopted a new risk response strategy in the PMBOK Guide 6th Edition. That new response is "escalate." According to the PMBOK Guide 6th Edition, “Escalation is appropriate when the project team or the project sponsor agrees that a threat is outside the scope of the project or that the proposed response would exceed the project manager’s authority.” But a closer look at the sponsor role suggests there is a better way to deal with the problem that risk responses exceed the project manager's authority, a way to organize that obviates escalation, avoids inducing sponsors to micromanage, and eliminates the rampant misalignment between sponsors and project teams that disempowers those closest to the work to act wisely and with agility.

An essential role of the sponsor is to convey the project's risk appetite and risk tolerances and from this perspective to sign off on all severe risks and responses to those risks. By comparison, the project manager's role is to identify risks, develop risk responses, get approval from the sponsors for responses to severe risks, and to manage risk responses capably to resolution.

In most organizations, the sponsor is the project owner. Sponsorship is ownership. Sometimes this is delegated (or the sponsor is a proxy for the owner). Sponsors are benefactors, and as persons who provide or secure resources for projects they typically expect something in return, meaning they seek the benefits from the outputs of the projects. As such, sponsors approve success criteria, performance baselines (schedule, budget, scope), change requests (CR's) pertaining to the aforementioned things, and risk response plans for severe risks that the project faces. In this context, they "own" the project. The owner has the power to continue the project or dispose of it. Without sponsorship, a project cannot continue.

Enrolling the sponsor to distinguish the project’s success criteria, to approve the performance baseline, and to set the project’s risk appetite or tolerance effectively flattens the organization structure. If alignment is maintained, the need for escalation is obviated.

SPONSORS ARE BENEFACTORS

As the project's benefactor, the sponsors implicitly approve that the project can proceed in the face of risks. While the project manager will manage those risks, the project manager cannot decide on the project's behalf the threshold distinguishing acceptable risks from unacceptable ones. This is why the project sponsor must "own" (approve) the risks that the project manager manages. In RACI terms for project risk management, the project manager is responsible, but the sponsor is accountable. If one wishes, one may further refine these roles by distinguishing different levels of sponsors and different levels of approval for different types of risks. However these roles are defined, a project's sponsors must not transfer risks to their project teams, just as project teams must define their own success in terms of their sponsors succeeding.

Sponsors must not transfer risks to their own project teams.

BENEFACTORS SEEK BENEFITS IN RETURN

As benefactors for projects, sponsors typically seek benefits from projects in return. As such, sponsors provide a strategic perspective (linking project outputs to expected benefits), motivate the team to produce the outputs that will yield the expected benefits, and help to supply resources and dismantle issues that the team cannot dismantle themselves. To be successful in this role, sponsors must be engaged proactively in their projects, and project managers must make that easy for sponsors. 

PROJECT MANAGERS OWN MANAGEMENT OF THE TRIPLE CONSTRAINT

By comparison to the sponsor role, the project manager owns management of the project, which includes schedule management, cost management, scope management, stakeholder management, integration management, resource management, quality management, communications management, and procurement management. All of these areas of management are inputs to risk management, which is a primary function of the project manager. Project managers should spend much of their time on risk management.

The project manager  must ensure the sponsor is aligned and agrees with the way risks have been identified, how they are articulated, agrees that risk statements correctly distinguish what the real risk is, and that the sponsor agrees that the correct responses have been formulated by the project manager or team.

SPONSORS DECIDE THE PARAMETERS OF THE TRIPLE CONSTRAINT

Sponsors must be informed of risks and approve risk responses because the sponsor is accountable for risks in ways that a project manager simply cannot be. While the sponsor (and not the project manager) decides the organization's risk tolerance and threshold, the project manager is responsible for managing the risks. To be successful in management of the project, the project manager must enroll the sponsor(s) to distinguish how the project manager should manage the triple constraint (and the "true North" of those constraints) within an acceptable threshold of risks. This is a dialogue between the project manager and the sponsors, and it is ongoing. Sponsors typically sit on a Change Control Board (CCB) for the projects that they sponsor, which approves success criteria and performance baselines (schedule, budget, scope) at each stage of the project. Sponsors approve or decline change requests (CR's) pertaining to the aforementioned things, which may occur at any time. The role of approving success criteria and approving performance baselines and changes to these things is not the same thing as managing the triple constraint, which is project manager's role, i.e. to manage the delivery of project deliverables (specs, on time, on budget, on cost).

INCREASING MATURITY IS THE ONLY WAY TO OVERCOME THE TRIPLE CONSTAINT

The triple constraint of a project (or the "Iron Triangle") is unforgiving. Changes in one of the three constraints of schedule, budget, or scope (delivered with quality) will always require a change to another of the constraints as a trade-off. However, as the organization increases its Organizational Project Management maturity, it will become more capable. When capabilities increase, it is possible to create more project outputs, to do so faster, at a lower cost, and with higher quality WITHOUT increasing risk.

SPONSORS BALANCE RISK-AVERSION WITH REWARD-SEEKING

It's natural for the persons who seek benefits from the outputs of projects to advocate that the project produce more of those outputs or do so faster or at a lower cost or with higher quality. Those imperatives, however, often increase risk. For example, we can speed up a project by taking work that is serial in nature and re-planning it so that tasks which were serial are done concurrently, i.e. "fast tracking." But this increases risk.

Requiring the sponsors to sign-off on risks and risk responses corrects imbalance between reward-seeking and risk-aversion. It ensures sponsors remain informed and aligned. It changes the dynamic of teamwork in positive ways. It discourages adversarial relationships, encourages partnerships, and cultivates servant leadership.

risks.png

IF PRODUCT MANAGERS OWN BENEFIT REALIZATION, THEY'RE NATURAL SPONSORS

Because the sponsor, who secures resources on behalf of the project, is invested in the realization of benefits from the project (which occurs after the project is finished), it makes sense for a product manager to be a sponsor on New Product Development projects (assuming that the product manager owns the product life cycle).  Alternatively, a product manager may play the role of "Business Analyst," which facilitates the capturing, prioritization, and implementation of business requirements and functional requirements through the stages of the project life cycle.

ONE PROJECT, MANY SPONSORS

While it is a de facto standard that the project owner is the project sponsor, we often see that projects have more than one sponsor. In many organizations the top priority projects have both a "sponsor" and an "executive sponsor." As these names imply, this is a distinction between levels of the vertical management hierarchy, where a "sponsor" plays the primary role we have discussed (acting as the project owner or proxy, accountable for benefit realization and governing risk tolerances), while an "executive sponsor" also plays this role but is naturally an escalation point.

In addition to having more than one sponsor, projects may have sponsors from different organizations. When there are multiple organizations involved in a project, whether those organizations are internal or external, we may see sponsors from each. If I.T.  undertook a project that required an extraordinary investment on the part of, say, Supply Chain, we would expect projects sponsors to include both someone from I.T.  and someone from Supply Chain. If Finance undertook a project that was composed largely of employees of a consulting firm contracted to help deliver Finance’s project, one would expect the project to have a sponsor from Finance and a sponsor from the consulting firm.

ROLE SUMMARY WITH PROS AND CONS

As benefactors of projects, sponsors are naturally persons who seek benefits from projects in return.  

Pro: Sonsors provide a strategic perspective, linking project outputs to expected benefits. Con:  One must distinguish between the motives of sponsors who are project owners and sponsors who represent supplier organizations.

Pro: Sponsors motivate the team to produce the outputs that will yield the expected benefits. Con: Organizations are notoriously bad at managing the link between project outputs and project benefits.

Pro: Expecting benefits, sponsors help to supply resources and dismantle issues that the team cannot dismantle themselves. Con:  Sponsor bandwidth is limited.

Project Managers own management of the Triple Constraint.

Pro: If sponsors set the project's goals and risk profile, project managers can manage timing, costs, and scope against risks. Con:  The project manager cannot decide on the project's behalf the threshold distinguishing acceptable risks from unacceptable ones

Pro: The project manager's role is to identify risks, develop risk responses, get approval from the sponsors for responses to severe risks, and to manage risk responses capably to resolution. Con:  Sponsors sometimes have difficulty understanding that those seeking benefits from the project must decide the project's risk appetite or tolerances, and that project managers cannot do this themselves.

Pro: Project managers can ensure the sponsor is aligned and agrees with the way risks have been identified. Con:  When projects are failing, sponsors may suffer from optimism bias, escalating commitment.

Pro: Project managers can ensure the sponsors approve how severe risks are articulated, and that they correctly distinguish what the real risk is. Con:  Sponsors sometimes fail to appreciate the importance of risk analysis and thus devote insufficient time to it. They say "That's the project managers job, and I don't need to be involved." This is, in effect, to abdicate.

Pro: Project managers can solicit sponsor approval that correct responses have been formulated by the project manager or team. Con:  Sponsors may be prone to "rubber stamp" their approval of risk responses.

Project owners are project sponsors, and project sponsors are project owners.

Pro: Persons who provide the resources necessary to enact a project (the owners) are appropriate persons to decide the project's risk appetite and tolerances. It's their investment at stake. Con:  Sometimes sponsors are unable to decide risk appetite and tolerance on their own, and coordinating these decisions is a cost.

Pro: Persons who provide the resources necessary for the project are appropriate persons to approve success criteria, performance baselines, change requests, and responses to risks to these things. Con:  When multiple organizations provide resources for a project, approvals for success criteria, performance baselines, change requests, and responses to risks to these things must be decided jointly.

Pro: Persons who sustain investment in the project are naturally the right people to distinguish acceptable risks from unacceptable ones. Con:  Sometimes project owners prefer to transfer risk-taking to others when that is not realistically an option. In effect, they wish to abdicate by not taking a position and to do so without repurcussion, which usually is not possible.

Pro: Project owners can approve risk-taking that project managers cannot approve unilaterally. Con:  Sponsor bandwidth is limited.

Sponsors are accountable for deciding the project's risk appetite and approving responses to severe risks.

Pro: This is a role that sponsors can play that project managers typically cannot. Con:  Sponsor bandwidth is limited.

Pro: Naturally balances reward-seeking with risk-taking. Con:  Typically equires a cultural shift.

Pro: Ensures sponsors remain informed and aligned. Con:  Typically requires a cultural shift.

Pro: Changes the dynamic of teamwork in positive ways. Con:  Typically requires a cultural shift.

Pro: Discourages adversarial relationships. Con: Typically requires a cultural shift.

Pro: Encourages partnerships. Con: Typically requires a cultural shift.

Pro: Cultivates servant leadership. Con: Typically requires a cultural shift.

Product Managers can be sponsors of projects, specifically New Product Development projects. 

Pro: It makes sense for a product manager to be a sponsor if that the product manager owns the product lifecycle.  Con:  If it's not true that the product manager owns the product life cycle, then it may be a mistake to assign them the role of sponsor based soley on their title.

Pro: Alternatively, a product manager may play the role of "Business Analyst." Con:  Assigning a Business Analyst does not necessarily help to identify the correct sponsors.

Projects may have multiple sponsors.

Pro: helps information processing through differentiation of the veritcal management hierarchy. Con: No two projects are ever the same, and how this is structured must be tailored to the project.

Pro: Projects may have sponsors from different organizations. Con:  One must distinguish between the motives of sponsors who are project owners and sponsors who represent supplier organizations.

Although PMI has adopted a new risk response strategy in the PMBOK Guide 6th Edition, namely "escalation," enrolling the sponsor to distinguish the project's success criteria, to approve the performance baseline, and to set the project's risk appetite or tolerance level effectively flattens the organization structure. If alignment is maintained, the need for escalation is obviated. If you can overcome the challenges, you can reap the benefits.

 

 

 

 

A Thousand Twangling Instruments: the 3 Phases of Disaster-relief Programs by John Schlichter

puerto.jpg

by John Schlichter

The week after hurricane Maria devastated Puerto Rico, we sailed down to the Caribbean and met with stakeholders across the region.  Programs that respond to disasters like these have three phases:

Phase 1:  Immediate disaster response.  Phase 1 occurs immediately after the occurrence of the disaster event, and has emphasis of emergency response activities such as saving lives; rescuing disaster victims in imminent danger; and getting emergency food, water and shelter to survivors.  Time is of the absolute essence in Phase 1.

Phase 2:  Disaster relief.  Phase 1 efforts will begin to transition to Phase 2 when the immediate danger has passed and activities turn to dealing with victims and refugees from the disaster.  Phase 2 involves managing sometimes large displaced populations, identifying temporary shelter, and making mid-term provisions for food, water, medical treatment and other necessities (e.g., sanitation activities to avoid or mitigate the spread of disease).  Cleanup activities begin in Phase 2, but only to enable disaster relief.

Phase 3:  Reconstruction.  Phase 3 involves the long-term efforts associated with restoration of society after the disaster, including, as necessary, restoration of political, economic, physical, and information infrastructures. 

The myriad of uncoordinated relief efforts is like Shakespeare’s thousand twangling instruments on an isle full of noises.

These phases are linked, and there is overlap between the phases. One key enabler of effective response is the availability of descriptive and prescriptive tools and frameworks that allow decision makers and organizers to characterize the current state of response efforts across the full range of the situation.

In the short term, one of the most difficult tasks (in addition to the response activities themselves) is getting a handle of what is actually going on in the response space.  What is the status of the effort?  Who is involved?  Where are they?  What are they doing?  What problems are being experienced?  Collecting, organizing, and distributing this information all pose serious problems.  In many cases, the information is available, but not structured and difficult to assemble or understand. The myriad of uncoordinated relief efforts is like Shakespeare's "thousand twangling instruments" on an isle full of noises.

In the current situation, news reports and particularly emerging media (e.g., social networking sites, Twitter, etc.) and other open-source data sources have played a role in getting information out about elements of the situation. These diverse and unstructured sources are particularly difficult to rationalize into a coherent picture, but mature capabilities exist to explore these varied information sources and, using technology such as Geographic Information Systems (GIS) frameworks, build useful and responsive pictures of what is going on in space and time, including the discovery of relationships and networks between different organizations and activities.  Such capabilities can be put to work right away to start characterizing the status of current/ongoing response activities.  Once built, this picture can be used to build shared situational awareness and facilitate the discovery of challenges (e.g., hospital A is out of antibiotics) and solution alternatives (e.g., organizations/individuals who can help with hospital A’s problem).

In Phases 2 and 3, response organizations have more of an opportunity to design and/or grow the relief and reconstruction efforts – especially in Phase 3, which is usually the result of a deliberate planning effort.  That said, these phases can be extremely challenging due to the scale and diversity of partners involved (and the range of agenda/visions/missions that are present), the complexity and interrelatedness of the relief/reconstruction activities, and the lack of a unified “chain of command” among the participants. 

How do organizations that have the resources and sealift/engineering/logistics capabilities to respond to large scale disasters work with relief groups? Uncertainty – whether from an inability to gather and/or distribute information or from the rapid pace of change in the situation – places a premium on the ability to manage/influence the response effort (what we would call a complex endeavor).  Decision making must be enabled at appropriate times and organizational locations, supporting interaction and collaboration among participants in the endeavor, and ensuring information is distributed in ways that create shared awareness of the situation.

OPM Experts LLC has frameworks that can be applied both to characterize the “as-is” response effort as well as to prescribe actions or resources that would be most effective at increasing the efficacy of the response effort through enhanced coordination and collaboration among participating entities. Our models identify the key drivers that enable endeavors to move from one level of maturity to the next, and they have been applied in a range of real-world disaster-relief circumstances. Use of such frameworks helps to benchmark relief activities and guides leadership decisions about how to organize and manage/influence relief/response work. This is especially appropriate for Phases 2 and 3 but could be of great value during Phase 1 to help identify low-hanging fruit that could pay disproportionate dividends in an extremely austere environment, e.g., the use of 802.16-based technology to establish a temporary information infrastructure quickly to de-conflict and then coordinate activities.

All the people whom we have met on our tour of the region are either eager to help or eager to be helped. While many have moved to Phase 2 (disaster relief) and Phase 3 (reconstruction), some continue to grapple with Phase 1 (immediate disaster response).

“The clouds methought would open, and show riches
Ready to drop upon me; but, when I waked,
I cried to dream again.”
― William Shakespeare, The Tempest

Naked in the Desert by John Schlichter

My flight landed in Jeddah, the largest port of the Red Sea, where I was scheduled to meet early the next morning with the mayor to begin assessing the ability of the local government to enact its strategies through billion dollar construction projects. It was the height of the Hajj, the annual Islamic pilgrimage by Muslims to Mecca, which is located just outside the city. I had done this trip before and was confident things would go smoothly despite the fantastic surge of people.

In previous visits, when I had been performing a similar project management maturity assessment for the Ministry of Interior, I had been escorted through customs in seconds. It turns out that part of the Ministry's purview is border control, one of the perks being VIP treatment at customs. But this time, I had no such luck. It took five hours! And on leaving customs I learned that my luggage had been lost!

By the time I got to my hotel, it was the middle of the night, and I had nothing to wear to my meeting first thing in the morning. I might as well have been naked in the desert. But then it dawned on me that Middle Eastern cultures are nocturnal. A simple inquiry at the front desk revealed there was a market just one block from the hotel. And sure enough, it was open despite the late hour. It was worth a shot, right?

Beyond rows of wares, nestled in a back corner of that market, lo and behold there was one rack of clothes. And at the end of that one rack there was an Italian suit! And miracle of miracles, it was my size! Just like that I was wearing a new suit and speeding off for my meeting with the mayor. What incredible luck! I swore to myself that next time I would bring a change of clothes in a carry-on bag. Like the Arabian proverb says, "Trust God, but tie your camel."

How many of us have found ourselves the victim of optimism bias, virtually naked in the desert as we set out upon a new project? It is easy to believe we are at lesser risk of experiencing a negative event compared to others, and this cognitive bias is quite common, trascending gender, race, age, and nationality. That's why it is good to trust one's capabilities but always better to verify you have them.

Ratings for Healthcare Innovation: Can Maturity Assessments Improve Health Outcomes? by John Schlichter

by John Schlichter

As the US Senate debates revisions to the Affordable Care Act this week, people on both sides of the aisle are asking how to improve the healthcare industry. Faced with the reality that the major political parties are entrenched opponents, one wonders whether social collaboration to improve healthcare could emerge in other ways. It is a question I had taken up before, when I asked myself whether organizations across the healthcare value chain could be incentivized by transparancy and reputation to optimize healthcare outcomes. Would leaders reform their organizations if they were graded publicly? From song rankings on the Billboard Charts to credit scores by Moody's or Standard and Poor's, we can see that ratings matter. Could the rating of healthcare organizations change behavior?

Specifically, could maturity assessments improve outcomes? In other words, could a health system innovation maturity model be created that motivates healthcare organizations to develop and use capabilities that improve population health, population healthcare, and the innovation of both? Buoyed by this question, four years ago I waded into the deep waters of US healthcare reform through a multi-million dollar grant proposal to establish a Congressional award based on maturity assessments (Figure 1). My idea was that a highly esteemed national award based on detailed assessments and summarized as scores or ratings could "pull" innovation from organizations to improve outcomes in creative and unpredictable ways that nobody could "push" or require organizations to innovate.

 

 Figure 1: A Plan to Foment Innovation Across the Healthcare Industry. From CMS Health Care Innovation Awards, Centers for Medicare and Medicaid Services, 2013.

Figure 1: A Plan to Foment Innovation Across the Healthcare Industry. From CMS Health Care Innovation Awards, Centers for Medicare and Medicaid Services, 2013.

Measurement is known to change behavior. Evaluation frameworks are self-fulfilling because they shape institutional designs and management practices as well as social norms and expectations about behavior, thereby creating the behavior that they predict (Ferraro, Pfeffer, Sutton, 2005; Biggs, Bearman, Hedstrom, 2009). For evaluations of healthcare organizations to inspire change, they would need to be based on standards endorsed by the major stakeholders. We proposed to establish standards focused on population health outcomes endorsed by Medicare and Medicaid.

Specifically, we proposed to encourage helping the following:

o Age groups: prenatal to age 2, ages 2 -12, young adults (13-19), adults ( 20-64), and seniors (65+)

o Population insurance status: Uninsured; Commercially Insured; Medicaid/CHIP; Medicaid; Other.

That's everybody.

The mechanism is to develop and support dialogue and actions aimed at population health management goals, namely improved health, improved healthcare, cost savings (for the patient – not utilization-based cost savings), better access, and patient satisfaction.

If healthcare organizations were assessed on their ability to innovate population healthcare and improve population health in ways that enact these goals, what kinds of innovations might they conceive? Healthcare innovation projects could take the form of vouchers and privatization that decentralizes the system and removes unnecessary burdens from business. Innovation projects that enable out-of-pocket payment (OPP) by consumers for routine medical care could transform the system from one dominated by third party payers toward a model that would put consumers in charge of their healthcare dollars, unleashing market disciplines into the equation for the first time. Public-private partnership projects could work to reform licensing requirements for medical schools, hospitals, pharmacies, and medical doctors and other health-care personnel, causing prices to fall and a greater variety of healthcare services to appear on the market. Or insurance products could be developed to protect against events over whose outcome the insured possesses no control; a big problem in health insurance is if you are on your own or part of a very small group, you have no leverage for prices, and if someone gets very sick, then you don’t have the protection of thousands or even hundreds of thousands of people sharing the risk, but employers could band together in associations that let individuals join to buy health insurance as a group to cover high risks or even pre-existing conditions. Alternatively, innovation could address the production and sale of pharmaceutical products and medical devices. Whatever the innovations may be, the organizations responsible would be assessed and scored for innovation directed at improving population health and healthcare. Innovations would be evaluated for efficacy, and the ability of organizations to deliver the innovations would be characterized. Seeing clearly which organizations are actually working for the greater good (and whose good works are indeed working), consumers could make more discriminating healthcare choices.

 Figure 2: Letter of Intent from Suffolk University's Office of Research and Sponsored Programs Naming John Schlichter as Principal, 2013.

Figure 2: Letter of Intent from Suffolk University's Office of Research and Sponsored Programs Naming John Schlichter as Principal, 2013.

I was lead scientist, research group leader, and the principal assessor and improvement consultant for participating healthcare organizations (Figure 2). Despite partnering with Emory University and Suffolk University and lobbying Tom Price (who has since become the US Secretary of Health and Human Services), we were unable to enroll the Centers for Medicare & Medicaid. Yet I remain convinced that something akin to the Malcolm Baldrige National Quality Award would be a creative and low-cost way to encourage providers to improve health outcomes for individuals. Payers, providers, producers, fiscal intermediaries, and accountable care organizations would be assessed, ranked, and awarded publicly, creating ratings with financial implications.

What do you think? Do you believe that reputation mechanisms like maturity assessments, awards, and ratings can motivate organizations across the healthcare value chain to improve outcomes (quality of life years or QALYs) for individuals? Do you believe the people running healthcare organizations could be motivated to collaborate on healthcare innovation across the value chain if their reputations were at stake?

ICYMI, here are some scientific breakthroughs that occurred this past week: by John Schlichter

Quantum materials were created that can conduct electricity at nearly the speed of light.

The world’s first fusion reactor created its first plasma; on track to produce clean energy by 2018.

Fungi in a toxic lake was discovered to produce a new antibiotic that kills super-bugs unlike anything before.

HIV infection has been eliminated in living animals through gene editing.

Researchers created the first synthetic retina out of soft tissue.

Scientists discovered how to extract ancient DNA from 240,000 year old dirt.

In this exponential future accelerating toward us, how can executives implement their strategies through projects successfully, consistently, and predictably? The answer is "SIMPLE," the "Strategy Implementation Maturity Protocol for Learning Enterprises." See https://lnkd.in/eMKAV-e

Aligning Projects to Business Strategy by John Schlichter

align.png

In a survey of 400 U.S. CEO's out this month, 65% said the next three years will be more critical than the past 50 years. Complexity, volatility, and uncertainty have been on the rise since the turn of the 21st century, making it more difficult for organizations to execute their business strategies through projects, especially those organizations that have not developed Organizational Project Management (OPM) capabilities. From the outset of the OPM3 program in 1998, we knew that organizations would need help for the foreseeable future to improve their ability to execute business strategies through projects in order to thrive in the exponential world accelerating toward us. This need has only increased over time.

That idea, that projects are the way to execute organizational strategies, was a game-changer for PMI standards, which had not been enlarged beyond addressing the management of individual projects to date. Midway through our development of the OPM3 standard in the year 2000, I asked our team to deploy a survey to gauge how well organizations align their projects to business strategy (such that projects are designed to achieve formulated strategy), the first time PMI sponsored such a survey.In that first survey, we engaged 10,000 professionals and found that only 66% of those surveyed said their organizations align projects to business strategy; and worse, only 25% said their organizations had well balanced portfolios (Schlichter John. PMI’s Organizational Project Management Maturity Model: Emerging Standards. PMI ’01 Annual Symposium, Nashville; 2001). Since 2003, PMI's whole focus has shifted to organizations and their ability to execute business strategies through projects, getting more business value from projects. In that time, we have seen many organizations dramatically improve their ability to execute business strategies through projects, but the opposite trend is also true.

In 2013, a decade after our first survey on project alignment to strategy, PMI started surveying project alignment to strategy annually, reporting that from 2013 to 2016 about half of organizations reported high alignment of projects to organizational strategy, which was slightly worse than our finding a decade earlier. And that metric dipped further from 54% in 2015 to 48% in 2016. In short, a significant number of organizations have not been aligning projects to business strategy, a phenomenon that some may say, on the whole, has not improved for nearly twenty years and appears to be getting worse gradually. What do you think accounts for this trend? Is it because the strategy is missing or outdated? Or because strategies formulated top down are not translated into projects? Or that emergent strategies developed bottom up are not aligned to formal strategies? Is it because projects created top down from strategy and projects proposed bottom up to advance strategic intent are not vetted capably? Is it a failure on the part of executives or on the part of middle management?

There are many questions, but beyond musing upon frequent causes of misalignment and well known opportunities to improve it, the more fundamental question is whether organizations actually are getting worse at this, as PMI suggests, or instead are they actually getting better but just not keeping pace with the exponential future accelerating toward us? This question may be one of the more important ones facing businesses today. As Darwin said, "It is not the strongest of the species that survives, nor the most intelligent that survives. It is the one that is most adaptable to change."

Executing Strategy Through Organizational Project Management ™ by John Schlichter

school.png

As the saying goes, “good ideas are a-dime-a-dozen.” Having a good idea simply doesn’t mean much unless it can be translated into results in the real world. Strategic plans that can’t be executed are largely useless. Planning in and of itself has its own merits, yes, but ask yourself, as an executive, how meaningful your strategies are if you cannot translate them into projects designed to enact them or if the projects meant to deliver the strategy ultimately fail. The answer is that your strategic plans are largely worthless without capable translation into projects and without capable delivery of those projects (Charan and Colvin, 1999).

Strategies are decisions regarding where and how to compete. They are decisions regarding the scope of operations and the deployment of resources. To enact strategies, projects are formulated. These may be projects to create or change a business, create technology or upgrade products, to rethink and reshape delivery, to transform organization structures or processes, to innovate supply chains, services, or marketing through new profit models, channels, brands, or ways of engaging customers. These may be collaborative endeavors, incremental actions, breakthroughs or disruptive innovations. Whatever your strategies may be, they are enacted through portfolios of projects, and one must be able to evolve or adapt one’s projects and deliver them successfully, consistently, and predictably in a complex and changing landscape. Would you like to guarantee your organization’s ability to implement its business strategies through projects? A business standard named “OPM3” was created to help you do just that. 

Your organization's strategies or decisions regarding where and how to compete are enacted through evolving networks of projects.

To begin to understand OPM3, first you have to appreciate what it means to be a standard. Cast your imagination to the 2nd millennium B.C. and the vast grassland steppes of Asia that provided fertile grazing, water, and easy passage for caravans. Merchants traveled immense distances from the shores of the Pacific to Africa and deep into Europe to trade in one of the hottest commodities of the ancient world that became the namesake of this super highway: the Silk Road. Across the Archaemenid Empire of Persia’s Cyrus the Great and then the Greek Empire of Alexander the Great, the roads grew through the ages, through the Roman Empire, the Byzantine Empire, Medieval China, and the Mongol Empire. These roads became de facto standards as the way that travel occurred, standards in reality by fact of widespread use. That is foremost what a standard is: the prevailing practice. Tacit knowledge of the paths taken by travelers on the Silk Road was translated into explicit knowledge in the form of maps that codified popular routes. That too is what a standard is: a paradigm or framework whose authority is asserted. The standard practices of traveling known routes were accompanied by rules or standards de jure (that is, officially or by law) like weights, measures, and coinage that enabled commerce. That is yet another way of understanding standards, i.e. as abstractions contrived to enable interaction.

With the onset of the Industrial Revolution and the need for high-precision machine tools and interchangeable parts, the implementation of standards in industry and commerce became highly important. For similar reasons, as projects proliferated and became the preferred method for implementing business strategies, the need for project management standards grew as well, as standards enabled people from different backgrounds and places to collaborate through shared vernaculars and methods even when they hailed from different organizations or had never met before, moving from one project to another seamlessly even though each project, by definition, produces something different or unique. Today a standard is an established norm or requirement in regard to technical systems or frameworks. For example, a framework, custom, convention, company product, or corporate standard may become generally accepted and dominant as a de facto standard. More often, a standard will take the form of a formal document that establishes uniform criteria, methods, processes, and practices de jure.  Standards may be developed privately or unilaterally, e.g. by a corporation, by a regulatory body, or by the military. Or they may be developed by trade unions or associations, or standards organizations that have emerged and solicit diverse input to develop standards voluntarily, by edict, or the formal consensus of experts.

We deployed surveys to over 30,000 professionals globally in order to define a global standard defining all of the elements of Organizational Project Management (OPM).

Against this backdrop, an international team came together in 1998, rallied by the following question I posed to them: “Can we develop a standard that helps organizations implement their strategies through projects?” By this time, standards for the management of individual projects were well known. But there was a need to meet the exponential interest in project management with a way to make project management capable in organizations. My thought was that our purpose should not be to improve project management in general but to improve the ability of organizations to enact their strategies, the raison d'être of organizations, and to improve their ability to do so through projects. To do this, we envisioned describing as a system the ways that organizations implement their strategies by integrating project, program, and portfolio management. To refer to this system, I coined the term “Organizational Project Management” or OPM. Our goal was to create a model that explained how to implement OPM or how to achieve excellence or maturity in OPM, i.e. an “Organizational Project Management Maturity Model” or “OPMMM,” a term which I rephrased as “OPM3” (indicating the three M’s in the name) simply because it was easier to say.  We deployed surveys to over 30,000 professionals globally in order to define a global standard defining all of the elements of OPM. Word-analysis software was applied to the data for affinity mapping in order to organize the data around the key concepts of OPM, and hundreds of experienced professionals poured over this material to distill it into actionable guidance.

Our large and highly experienced team (nearly 800 people across 35 countries) agreed that describing what constitutes all of the elements of Organizational Project Management was not enough. We needed to distinguish each element of OPM in terms of the steps to implement each element in an organization. For this reason, the team reverse-engineered all of the elements of OPM into their constituent parts. For example, if the respondents to our surveys to 30,000 people told us that one of the things necessary in an organization that delivers projects is highly capable sponsorship of projects, then the team decomposed that into the steps required for achieving highly capable sponsorship. The result was magnificent, including steps for establishing the strategic alignment of projects to organizational goals, steps for learning from other organizations who are implementing OPM, steps for implementing management systems and control systems, steps for ensuring projects have sponsors who are doing specific things, steps for adopting appropriate organization structures, implementing project management methods, practices, and specific techniques, steps for enacting resource allocation for OPM, steps for implementing competency management and individual performance appraisals, steps for knowledge management as well as steps for implementing a project management information system (PMIS) and establishing internal project management communities and more.

But as I looked at all of the data, I realized that it did not tell the essential story that reflected our original purpose, which was to elaborate Organizational Project Management as a system for implementing the strategies of organizations through projects. It occurred to me that to do that, we had to ensure we told one essential story that organized the wealth of insights we had collected, a story I summarized as “how to do the right projects the right way,” a slogan I announced to our team and watched ignite the imagination of hundreds of people. Today you can find this slogan in papers, articles, project management course descriptions, and book titles. That idea was that there are processes for translating strategies into projects, processes for project-portfolio and program management, and processes for initiating, planning, executing, controlling, and closing individual projects. These processes can be woven together as a system for doing the right projects the right way, recognizing that what is “right” is somewhat different for each organization but that general guidance can be represented in a way that is applicable to most organizations most of the time.

Strategy and project delivery processes can be made capable in ways that reflect your organization's strategic intent and organizational imperatives.

As our global team undertook the work of elaborating those processes for implementing business strategies through projects, in addition to leading the team I was managing a PMO that produced successful results for a private company that was subsequently sold for billions of dollars. In other words, I had been honing my craft in the corporate world. But more importantly to our agenda for OPM3, I was completing a Master’s degree in Business Administration at Emory University’s Goizueta Business School, where my leadership of the development of OPM3 was reformed in classes by the likes of Robert Kazanjian who reformed my understanding of strategy implementation, Benn Konsynski who reformed my understanding of the role of frameworks to adapt to an uncertain world galloping toward us, and George Easton who fundamentally transformed my understanding of what is possible by institutionalizing process capabilities in organizations. In one of the classes of that program, Easton taught us the fundamentals of process management, based on the idea that it is possible to determine if a process can be expected to perform within specification limits, distinguishing how much natural variation a process experiences relative to its specification limits. The basic technique is called “Statistical Process Control” or SPC, a technique that evolved over many decades through use by thousands of professionals, proving its status as an industry standard.

George Easton had my attention because he had been one of the architects of the Malcolm Baldrige Award created by the U.S. Congress and had been teaching Six Sigma since before Motorola allegedly “invented” it and GE made it famous. I realized in George’s class that this was the key that was missing from the work our team was doing to elaborate a system for doing the right projects the right way. We could not only describe the processes for choosing and delivering projects, but we could describe how to make those processes perform successfully, consistently, and predictably through SPC. I realized that although the processes of translating business strategies into projects and delivering them successfully pertained not to manufacturing or operations but to temporary endeavors, this kind of activity-system for executing strategies through projects had become highly routine work throughout the world and that we could re-purpose the techniques applied to manufacturing to this new way that would characterize work for the foreseeable future. Indeed, the Malcolm Baldrige Award was one of the 20+ models our team had analyzed as background for the development of OPM3, and it was a great privilege to have my eyes opened by one of the preeminent minds to pioneer that quality framework as a standard.

I distilled that idea as fifteen steps organized into four maturity levels, and proposed this framework to our team, which they approved:

STANDARDIZATION LEVEL
1. Establish process governance.

2. Document the process, i.e. project, program, and portfolio management processes.

3. Communicate the process to the necessary stakeholders.

4. Achieve consistent implementation of work methods.

MEASUREMENT LEVEL
5. Identify critical characteristics of the process.

6. Focus the process on the needs of the customer, and incorporate performance requirements of customers into process measures.

7. Measure the process's critical characteristics directly.

8. Identify measures upstream of the process, and ensure process users understand how other processes produce outputs that become inputs to the process.

9. Measure the critical inputs to the process.

CONTROL LEVEL
10. Develop a process control plan.

11. Implement a system for maintaining control of the process.

12. Operate the process in a stable fashion, consistently within upper and lower control limits, and update process documentation accordingly.

(CONTINUOUS) IMPROVEMENT LEVEL
13. Identify root causes of problems during operation of the process.

14. Execute continuous efforts with widespread participation directed at improving the process.

15. Integrate process improvements with systems that standardize improvements.

Today the Organizational Project Management Maturity Model (OPM3) is a standard that distinguishes the processes of project, program, and portfolio management, and applies these fifteen steps to those processes as a transformation or capability-development agenda. Supplementing this process transformation framework are nearly 200 other improvement options to implement a myriad of best practices associated with Organizational Project Management, improvement options distilled from surveys to 30,000 people and the work of hundreds of professionals who vetted that material.

Hundreds of people have applied this model in all manner of organizations.

Even though OPM was invented as the basis of OPM3, most people today are not aware that OPM3 defined the standard for OPM. They are not aware that OPM3 includes not only the system of OPM but all of the steps described above - steps that are known as "Capability Statements," including not only the 15 process improvement steps listed above and applied to all project, program, and portfolio management processes, but approximately 200 other steps distilled from surveys to 30,000 people. The reason why most people are not aware that OPM3 was primarily composed of these steps is that even though all of these steps are the essential component of OPM3, PMI made all of these steps for implementing OPM a separate commercial product that was expensive and which degraded adoption because it was expensive, which led to protests. And PMI promoted a misleading survey as a less expensive alternative to the commercial product, a survey so misleading that it effectively derailed OPM3 implementations. It is a case study in how not to manage industry standards. PMI recently announced that OPM3 shall be updated to its 4th edition and will include all of these steps for implementing OPM, which is good, but it's unclear whether PMI will remove the misleading survey when this occurs. It suffices to say a comedy of errors has been made in the management of the OPM3 standard.

In fact, now PMI is creating a separate standard they intend to name "The Standard for Organizational Project Management," which is both confusing and creates the risk of a conflict between standards, i.e. confusion between PMI's self-described "foundational standard" titled "The Organizational Project Management Maturity Model," which defined the standard for OPM in the first place based on surveys to 30,000 people, and "The Standard for Organizational Project Management," which is being created by far fewer people and without the extensive research that formed the basis of OPM3. There is a significant risk that these two standards will have non-identical definitions of OPM and non-aligned guidance for implementing OPM. But these kinds of problems are modus operandi in the development of PMI standards by committee. Do not lose sight of the forest for the trees.

Your organization's strategies or decisions regarding where and how to compete are enacted through evolving networks of projects that are adaptable, temporary, team-based problem solving processes that produce unique results, benefits, and learning, upgrading strategic planning recursively and cybernetically. In any organization with many projects, although control mechanisms are created explicitly and often in a centralized manner, the projects must adjust and adapt to each other, creating new systems and subsystems that exhibit a degree of self-organization.

The adoption of standards occurs as simple rules, customs, and rituals for project teams: simple rules that create the possibility of behavior that is independent in detail and governed by higher organizing principles, i.e. emergence. Rigid protocols in certain parts of the system create greater flexibility across the total system, enabling agility. Decision-making must occur capably to a degree that matches the demands of the environment. As performance is reported, resources are reallocated across the portfolio, project termination decisions may be made, and new projects may be initiated top-down or bottom up.

Strategy and project delivery processes can be made capable in ways that reflect your organization's strategic intent and organizational imperatives. Both the processes and the environment they occur within must be cultivated. These processes and the method for transforming both the processes and the environment that situates them have been codified as a standard, which distills prevailing practices within an authoritative paradigm or framework contrived to enable collaborative action-taking.

Hundreds of people have applied this model in all manner of organizations. Speaking for myself, I have implemented OPM3 in organizations like Automatic Data Processing, AECID, Alcatel-Lucent, Amana (Jeddah Municipality), Battelle Memorial Institute, CARICOM, Cooper University Hospital, Det Norske Veritas (DNV), European Union External Action Service (EEAS), FRTIB, Harris Corporation, Hong Kong SAR Government, Hyder, IBM, Inter-American Development Bank (IDB), Johnson & Johnson, Kurdistan Regional Government, MARTA, Melco-Crown Entertainment (China), Microsoft, National Bank of Abu Dhabi, Nationwide Insurance, Northrop Grumman, Panasonic-Mobile, Pearson Education Measurement, Popular Financial, Prudential Financial, Quality Assurance Institute (India), R.L. Polk & Co., SAP, Saudi Arabian Ministry of Interior, Studiocom, T-Mobile, TATA, Valassis, Verint, WellPoint, WorleyParsons, Xerox, and many others. We have proven that the OPM3 standard is the standard defining what OPM is and how to implement it, and we have the benchmarking data to back that up. This coming Spring I will teach the science and art of OPM to the full-time Executive MBA students of Emory University, my alma mater.

The journey of implementing Organizational Project Management in your organization and making that system capable is rife with pitfalls and decorated with failures. But others have made this journey before you, leaving well-traveled roads for you to follow and even tools for you to use, including a map, i.e. the OPM3 Capability Statements. Unfortunately, new maps are under development that may conflict with the original, and even those equipped with the best map are not necessarily qualified to lead the journey. A sailor must learn to trim the sail before crossing the Pacific, and a mountaineer must learn to detect crevasses before scaling the Alps. Even the experienced can benefit from a guide who is an expert. Join us starting in the Spring 2017 as an Executive MBA student at Goizueta Business School for an intense and exclusive experience where you are assured to learn frameworks you will use for the rest of your professional life to thrive in the exponential future accelerating toward us.