Rethinking Projects in Change

Intro

We currently caution against taking a default position that managed change is done with projects.

This caution is important because it is necessary to acquire and exercise management versatility in producing solutions to the problem of change.

Companies must understand the difference between the success factors of a change and the success factors of a project. And they must be able to determine if and why a project would be the best use of time and resources to pursue a needed solution.

In that light, it is also necessary to be able to determine whether a project that has failed is the reason why a managed change has failed. Reports continue, routinely, to say that 65% or more of managed change efforts “fail”… Clearly the post-mortems should account for whether projects are responsible when they were involved.

From that point of view, the following revisits the idea of projects with regards to managed change and the potential pros and cons of a project approach.

Included Ideas and Terms:

• Managed Change
• Production Options
• What is an Organization?
• A Project is/is not…
• Producing Solutions
• Projects are production tools
• Graphic: a structural model of Projects
• Clarity: what we already know about projects
• Recap: “Project”
• Recap: Managing Change

Managed Change

Change happens whether it is managed or not.

Most management of change is focused on how a future state that is deemed an improvement versus the current state will be attained with two objectives:

•Prevention of unnecessary risks to interim stakeholders

•Adoption, by a predominance of stakeholders, of the new state created

Accordingly, any approach chosen by management to support and secure those objectives can be considered a “management” tactic.

Per “management”, the future state that is recognized as the desired change is deliberately produced. Intentionally attaining the future state in a deliberate way is a production effort.

It is necessary to understand that the range of “production” in managed change includes cultivated evolution, training/teaching/learning, acquisition, collaboration, controlled experimentation, policy, and numerous other approaches — used alone or in combinations, over a span of time.

A project is/is not

A project is one kind of approach for producing an intentional change.

My favorite definition of a project is this:

• a project is an intentionally temporary micro-organization, designed and operated to produce one defined thing, under a high accountability plan, within a predefined resource allocation.

If that sounds just like a workforce using a method, that’s because it is a workforce using a method, but not only.

I use the definition to call out all of the key points that distinguish a project from a process, from an experiment, from a “case”, and from other forms of categorized groups of goal-oriented activity.

In a project, the organization, the method, and the plan are the key points, and those are elements related to each other for particular reasons (necessities) that further characterize and distinguish a project.

What is an Organization?

An organization is a specified set of functions arranged and supported specifically to ensure the continual availability of the functions to each other for co-operation.

The specification can change, either to allow different operations or to allow different ways to do a given operation.

Either way the point is to design the organization for a given purpose.

Producing change calls for using a work approach conducted by an appropriately purposeful organization.

The support for the arrangement of functions may come from any mix of sources internal and external to the organization; generally the support is also intentionally arranged at any time.

Producing Solutions

If there were NOT “projects” things would still get done but of course get done differently.

At minimum, the casual sense of what gets “done” is a “solution” to something — whether the solution is to a concept, a puzzle, or a “problem” (an unresolved negatively impactful condition).

A project is only one way among many to produce a solution.

That means there is a logical difference between a “solution requirement” and a “project requirement”.

What is it about an effort’s outcome that is required to make it a “solution”?

The characteristics that define an outcome as a solution should be True independently of characteristics that are required to make an effort unambiguously a “project”.

When something is solved, there is a new current state that does not have the important omissions or deficiencies of the prior state.

Projects are Production Tools

A project is only one way to produce a solution. And, a solution may include a project for producing only one aspect of the solution.

(Now, assume that outside of learning and training assignments, the problem is not “we have to do a project”.)

Projects get done when someone thinks that getting something done a certain way is necessary.

What is the certain way of “projects”? And why would it be necessary?

The necessity served by a project has to do with limitations on the effort — primarily on scope, on resources, and on how the two are related.

Typically, the application and enforcement of those limitations is done with the management of and by an organization.

And there are specific issues that hold highest priority in the relationships of the organization, the plan, and the method used in the effort. Among those three things, each one is variable, but no one of them can be removed and still have the remainder be a project.

The above is true regardless of whether the project’s eventual outcome turns out to be a solution or not.

Clarity: what we already know about projects

For starters, a project mode of effort requires multiple tasks, and is carefully planned to achieve a particular aim.

But it is still different from a “process”.

It is not the same as a process because of one of its criteria for completeness: it is intended to terminate.

• A process does not by definition need to terminate. By definition, a process needs to be coherent-by-design to achieve an expected output, and terminating is not a defining property of that ability. Additionally, time does not define a process; time is instead a performance attribute of a process. The same process can go very fast or very slow. And a process can be continuous, operating with no requirement to stop.

Furthermore, as part of what defines a project instead of a process, task planning is mainly about organizing the availability of task resources for a scope of commitment.

Because the targeted solution is the reason for the project to exist, the goal of the project is to have a sufficient impact. The sufficiency will have a calculated scope; and all commitment is calibrated to that scope, including adjustments as needed over time.

The critical awareness of what finally defines the effort as a project is even more specific: the commitment to the scope sees time itself as a limited resource committed to that scope.

And the primary reason for that is the presumption that the other resources are limited by their commitment to the project: the commitment excludes them from being used otherwise in the designated time.

Recap: “Project” is a discretionary mode of production committed to an outcome

A project mode is a strategic decision about how to pursue a level of impact that an output has on an outcome.

In that way, the decision declares a commitment to the scope of impact.

However — That scope of commitment is not the same thing as the scope of resources.

In project mode, managing the commitment means organizing resources, and enforcing accountability of resources, targeting the outcome not the output.

In project mode, managing the commitment applies authority, accounting, and capacity as needed and in combination, to create and maintain alignment to the intended outcome.

Resources are varied and variable, in type and amount, through applying management. Applying management is for controlling progress towards the impact, changing the output as necessary along the way.

In the context of the target solution, failure of impact is a failure of the project.

Recap: Managed Change

Per “management”, the future state that is recognized as the desired change is deliberately produced. Intentionally attaining the future state in a deliberate way is a production effort.

Most management of change is focused on prevention of unnecessary risks to interim stakeholders, and adoption, by a predominance of stakeholders, of the new state created. In managed change, adoption of a future state is success. Failure to adopt is a failure of the managed change.

Risks and stakeholders, and therefore reasons for adoption, respectively come in a wide range of varieties.

Change can therefore be managed with a variety of approaches, used individually or together. Selecting approaches to managing change is essentially a strategic decision — not a default decision to do a project.

© 2021 malcolm ryder / archestra research for ChangeBridge LLC