Wikipedia defines Organizational Change Management as follows: "Organizational Change Management aligns groups’ expectations, communicates, integrates teams and manages people training. It makes use of metrics, such as leader’s commitment, communication effectiveness, and the perceived need for change to design accurate strategies, in order to avoid change failures or solve troubled change projects."

This is important for Agile Project Management because when we look at large enterprise projects this is most often the cause of failure. We have a stellar project manager, we have a superstar team of developers, a highly astute group of business analysts, and a core team of wizard architects, yet the project was still seen as a failure. Why?

Because the most talented project delivery team and the most sophisticated whizz bang technology doesn’t change the basics of human nature, and one of the basics of human nature is that people are resistant to change. OCM is a discipline that studies change in an organization (easy, right.)

Let me state it again: People hate change. When an engineer in 2010 looks at the DOS program that Mary has been using for the last 15 years to enter orders, then sees her print out the manifest, take it to Bob, who pulls the order from the shelf, writes the date, time and release on a piece of paper, then takes it over to Ned who gets it ready for shipping, he sees a Rube Goldberg machine that if properly digitized, optimized, and streamlined could unlock all kinds of value for an organization! Excelsior!

Not so fast Sparky. Mary knows how to do her job. Bob knows how to do his job, and Ned knows how to do his job. They have ingrained patterns of behavior that give them a certain level of comfort with the current system, warts and all. If you come in with a customized automatic digital sign-off and order routing system, the whole order to cash ecosystem could very well come to a screeching halt.

As Agile project managers and technologists, we cannot continue to look at software development and packaged software implementations in a bubble. We need to recognize that the cause of ‘perceived’ failure for many a project is the lack of understanding and respect for how and why people are prompted to change.

I have looked at many technology project plans and have seen no provisions for guiding the organization through the change curve. Zero understanding or respect paid to training the users (what do you mean, I’m a UI GURU…. IT’S INTUITIVE!!!). Try telling that to Mary when she says, "It just doesn’t work!" What she really means is "It just doesn’t work FOR ME. I didn’t buy into the idea, I wasn’t prepared, I wasn’t trained and dammit I don’t like it!"

The next time you are envisioning a project, don’t just think about the developers, dbas, architects, testers, and business analysts. Think about a communication plan (early and often). Think about how you can get executive leadership to take a visible role in enabling change in the organization. Think about how you can expose the organization to the project progress, goals, and value. In short, think about your customer.