By Dr. Philip D. Mann, PMP, Assistant Professor of Organization and Management, Harrisburg University of Science & Technology

Projects fail a lot, and for many reasons.  One completely avoidable reason for failure, however, is the unnecessary distinction between two domains: Project Management (PM) and Organizational Change Management (OCM).

Across the industry, there is a lot of discussion and description regarding whether PM or OCM is more necessary.  There is even more building of methodological and philosophical empires and reinforcing of positions, but not much progress with making projects more generally successful.  Opinions about the relationship between PM and OCM oscillate between imagining the often-fuzzy distinction as a clear line bisecting the domains and obfuscating any difference by conflating the terms and tools.  The lack of clarity makes it challenging to understand which pursuit is most responsible for project success and how to harness it.

The natural artifacts of professional jargon may be the bigger culprit in blurring the boundary.  A search for “change management” likely uncovers articles related to managing scope change within PM processes, which isn’t the same “change” as OCM.  Confusion continues while trying to understand why OCM projects aren’t often handled as projects but are called “projects.”  After finally finding some information, those without a vested interest in one or the other still wonder if it’s true that PM and OCM are separate and discrete things that function alone, or are they two inseparable parts of an interwoven whole?

Let’s take a look at how the ideas of PM and OCM intersect.

Basic PM and OCM

Projects range in size and impact, from building a new international airport to putting a fresh coat of paint on the dining room walls, and all involve a change from the status quo.  In its most basic form and aligned with Project Management Institute’s (PMI) enduring definition, a project is a change from the previous state of being to a new state of being within a definable period.  There are dozens of approaches to managing projects – what we call “methodologies”– along with associated standards and certifications.  The methodologies have various strengths and weaknesses that help some work better in specific environments and worse in others.

Regardless of methodology, a project is just a deliberate change that may or may not include a tangible product.  Understanding that “project” is not “makes a thing,” it becomes clear that there is nothing inherent in a project that restricts managing it to item-only, non-people changes.

OCM, like PM, is about managing the migration of an organization from one condition to another.  A variety of factors drive changes under OCM and may result in radical realignments or subtle situational shifts.  Right away, OCM sounds a lot like PM, or the results of PM, even if the specific project deliverable is thing-focused.  Although some dispute it, OCM does have a variety of process models, standards, and associated certifications.  There are even suites of tools and engagement deliverables, just like PM.

So, why the conflict?  Where’s the meaningful difference?

Functional Requirements = PM + OCM

The wedge between PM and OCM is a failure on the part of many projects to keep their functional requirements – the business-driven use and benefit of the change – ahead of the technical (or “non-functional” if you prefer) requirements.  We conventionally think of a project when we think of the technical requirements, which focus on the mechanistic description and implementation of change-enabling machinery.  However, the functional requirements stress that success must include solution adoption by the relevant stakeholders, which is the raison d’etre of OCM!

Putting arguments, assertions, and turf defense to the side, PM and OCM are only distinct when neither considers the whole purpose and process of the change.  To truly succeed, every project must include the technical and functional requirements, and facilitate the accomplishment of both.  When done properly, correctly verified technical requirements and correctly validated functional requirements results in a successful and successfully adopted project.

Conclusion

The notion of a division between PM and OCM exacerbates an ongoing blame game where each tries to claim responsibility for project success while denying their part in project troubles. Adoption of a project is part of its success, so any project that does not include managing the adoption of the project by the organization, users, and other stakeholders is missing critical elements of its requirements and scope.  Some organizations may see the need to adapt their structures to account for PM and OCM activities individually, but just including proper functional requirements – the business reason and impacts – will, necessarily, bring the necessary OCM components into every project by design.