4squareviews

1.   Introduction

In his magnum opus Sex, Ecology, and Spirituality, Ken Wilber lays out the 20 fundamental tenets that he postulates for holons, which are entities that are at once a) wholes that are composed of parts, and b) parts that comprise larger wholes.    This concept of a holon is fruitful in that it bridges the divide in the history of philosophy between theories that postulate the primacy of the many vs. those that postulates the primacy of the one.

Ken Wilber, in his book A Brief Theory of Everything explicates the 20 tenets of holons in a format that is easier to read and understand, meant for people who are looking for an introduction to his other philosophical works.    In this post, I go through the first of these 20 tenets regarding the concept of a holon, and show how it can be applied to the practice of project management.

So it may seem like arcane philosophical discourse at first, but it has very important real-world consequences, and that is why I am interested in studying it in depth, as a kind of philosophical underpinning to project management.

1.   Tenet #1:   Reality is Composed of Whole/Parts, or “Holons”

A familiar example to explain this concept is that of a cell.    It is composed of organelles, so it is a whole which contains parts or components.    But a cell is of course a part of a larger whole, such as an organ of the body.    A project’s objectives are broken down into components called work packages, so a project contains parts or components as well.   However, a project is also a part of a larger whole called a program (a series of related projects which share certain resources).

Likewise, a program is part of a larger whole called a portfolio (a series of programs which share certain business goals).    And a portfolio is part of the business operations of an organization.

So going from smaller to larger, you have

work packages (deliverables) → project → program → portfolio → organization

The implication for a project manager is that you have to be able to change your focus to look both “downward” and “upward”, if by “downward” we mean from the scope of the project as a whole to the details of its smallest components, the work packages which produce the deliverables of the project, and if by “upward” we mean from the project as a part of a larger program, which in turn may be part of a larger portfolio, all undertaken by the organization.

As a project manager, you have to on a regular basis transmit the status of your project as a whole, and sometimes include the details of some of its components (particularly if there are problems pertaining to them), to the larger organizational units within the company starting with the program manager.

These perspectives sometimes create a tension, an example of which I illustrate below.

As a project manager, your goal is to achieve a schedule performance index of 1.00 (meaning the project is being completed by the deadline) and a cost performance index of 1.00 (meaning the project is being achieved within the budget allotted to it).    Ideally, you would like to have a schedule and a cost performance index greater than 1.00, which would mean you are coming in UNDER budget and BEFORE the deadline.

But what happens if, say, you get a schedule and a cost performance index of 2.00?    That would mean that it took the project took only half the time you were allotted and it only half as much as the budget you were allotted.   That would make you look like a real hero to the program manager, right?   Well, perhaps, but the program manager, remember, has OTHER projects to be concerned about as well.    If you completed the project using only half the resources you were allotted, then that means that, from the program manager’s point of view, half the resources that you didn’t use were locked up in your project unable to be used by any other project.    That, from his standpoint, would be a waste of resources that could have been used productively elsewhere in his or her program.

So this example shows that you have to be sensitive not just to the many parts which you, like an orchestra conductor, weave into the symphony of activity called a project, but you must be sensitive to the various organizational units of which your project is merely a part.

Let’s consider the stakeholders you must deal with on a project.    Stakeholders can be broken out into categories that also can be explained using the concept of a holon.   A project manager might have to deal with stakeholders who are a) internal to the project and internal to the organization (the project team, for example), b) external to the project and internal to the organization (the management sponsor of the project), or c) external to the project and external to the organization (suppliers, customers, regulatory agencies, etc.).    Thus a project manager is dealing with a series of nested entities which he or she must take into account when running the project.    This is one reason why I was attracted to integral theory, because it elucidates these hierarchical relationships you must often contend with.    The other reason is that it facilitates the understanding of different perspectives, which is also necessary when you deal with many different types of stakeholders from each of the three categories mentioned above.

Next week I will discuss the second tenet of the concept of a holon, and its implication for project management.

Filed under: Uncategorized |