Projects and governance: the wave/particle duality of the modern organization

Andrea Faré
Jul 27, 2017 · 5 min read

Those of us who have a limited confidence in physics know that some phenomena can be explained in terms of waves (sound propagation, water perturbations) and some others in terms of particle propagation (throwing an object, dropping sand on the ground).

Those who have a more advanced knowledge of physics also know that, at the microscopic level (I.e. photons) , the distinction is not so clear, actually the two types of behaviour can coexist, or at least be used for alternative interpretations of the same phenomenon (see here for a deep explanation, and here for a quicker one)

This article suggests the existence of a similar duality in the way organizations perform and can be analyzed. The duality lies in the different perspectives from which the work of the organization can be observed: that of projects and governance.


Let’s first introduce a generic concept of “mutual expectations”. By that I mean: what each of us can expect others will do in order to pursue the organization goals. This is the DNA of any organization structure, because clear and encoded expectations are what differentiates an organization (which is a system based on decisions) from any social system ( based on pure communication). These expectations are usually divided into two broad categories:

1) The category of temporary, finite, result based things (deliverables, actions , projects)

2) The category of ongoing, perpetual expectations (let’s name it governance: roles, rules, processes)

Traditionally we tend to define the shape and the touch points of these categories in a static way at “organisation design”-time and keep them unchanged across most of the organization lifecycle.

As an example, each organization tends to define up front criteria on the basis of which assignments to those categories should be made: how big a project should be to acquire some sort of relevance, what kind of data must be collected and how it should be budgeted, what the granularity of a role definition should be and how big/important a role should be before it can acquire any organizational relevance.

This static view unfortunately is often perturbated by new practices that emerge from time to time and bring completely new categorizations into play. If we do not make our pre-existing definitions flexible enough we end up having to hammer every new specific value creation method into existing outdated governance structures (or the other way around), at the risk of creating unresolvable mismatches. As an example you may think of agile practices, and processes, like Scrum, that define their own nuances of work items (Stories, Epics) roles (Scrum Master, Product Owner) and output (Release, Version) which seem to live in a world of their own, completely detached from the standard definitions of what a project or an accountability were before adopting them.

Categorization serves our brain simplification needs very well , but requires constant reconciliation in order to preserve its meaning in a dynamic context.

Reality is much more complex and shows us that not only the distinction between what a project is and what an organizational construct is, cannot be made precisely, but the distinction itself can vary during the life time of the same organization

To be more provocative we could say that sometimes the distinction is just a matter of perspective, and it’s observer dependent. In fact we could say that the following sentences are always true for any organization:

Each project is at the same time a temporary organization that sets implicit/explicit mutual expectations within team members at work to accomplish the project goal.

Each governance structure (set of ongoing expectations) is at the same time an infinite project with an unreachable “completion state”, a realized organization purpose.

If we accept these two concepts, we then have to start accepting that the boundaries between projects and and governance are not strict at all and we cannot adopt an upfront demarcation.

By stopping to hammer square pegs in round holes we can start seeing the organization as a continuum, where the line separating projects and accountabilities becomes fluid and can vary with time and scope. Some roles will be defined with very precise and detailed accountabilities and will leave room to very small, quasi-personal projects, or engagements based on very specific inter-role interfaces. In some other cases minimal pre-existing governance will leave room for projects that are handled collectively in a freer from. Some other times project-specific forms of governance will be adopted, that may then include their own methodology-specific rules and prescriptive roles (i.e. we could think of the typical scrum roles, such as product owner, scrum master, or developer as: “some methodology prescribed governance in the pursuit of a deliverable solution” )

Furthermore the scope of any project may vary with time, projects may collapse and disappear, or grow and last to the point where they require some project related ongoing expectations to be set up. In that case the project will maybe turn into a “team” with organizational relevance, that has the project deliverable as an objective. And maybe this new team will standardize those deliverables and turn them into products, the creation of which will spark new projects or even new teams, or maybe it will just standardize a methodology and sell it as a service or in some consulting form, producing the exact opposite effect : the “productization” of governance

Think of “change management”: doesn’t replacing some existing governance with new governance require a transformation project after all? Isn’t a meeting where we decide who does what, a project in its own right?

Conclusion: organizations are a complex subject to study, diagnose and improve, the minute we rely on a specific set of categories, those categories become obsolete. In spite of that we have to keep on trying to frame problems and opportunities, to make distinctions, we have to keep on playing with different frameworks, developing always new systemic views of the organization to try to get at least some form of understanding of what organizations really need from us in order to perform. The key is to be flexible: every time we see and area of variability we cannot tackle easily, we should try to dig a bit deeper and improve things at a different level of abstraction (move to the upper or lower meta-level and see if you can improve something there), Personally I find the following three to be the deepest, most basic areas of improvement that any organization needs to work on, so if you are in doubt on what approach to take, start working on these 3 and you’ll be getting off to a very good start:

1 Quality of communication ( What channels?Message formats? language? Vocabulary? And what moments can/should be used to communicate?)

2 Clarity and transparency (What expectations are attached to whom? Where can I go and read them? In What way can they be changed and when?)

3 Decision making processes (how do we meet to make decisions together ?What decision algorithms are adopted?As an organization member what is the span of my authority when I have to make a decision by myself?)

Thanks for reading.

Andrea

Andrea Faré

Written by

Self Management Evangelist & Holacracy Coach | Leapfrog.team

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade