Four Axioms for Controlling Change

March 8, 2014 | Author: PM Hut | Filed under: Process of Change Control

Four Axioms for Controlling Change
By Samuel T. Brown, III, PMP, Global Knowledge Course Director and Instructor

Change is a constant in life and certainly a constant challenge in project management.

Our customers don’t know what they don’t know, and so they routinely ask for something more or different. Our teams are comprised of talented, creative people who often recognize opportunities for improvement of either the project’s deliverables or the processes agreed to for producing those deliverables.

The problem is that the team is so intimately involved with the work of the project that they often make changes without recognizing that they have done so.

Of course, there are also the changes that are driven by evolving business objectives, new constraints from regulations, the marketplace, etc. With change impacting the project from all of these sources, both on a requested and on a discovered basis, how can a project manager possibly expect to control anything?

Our first challenge is to realize that we cannot control change. We need to adjust our perspective. Our job is not to control change, but rather to control the impact of change on the project.

Such an adjustment in perspective enables us to avoid the trap of beginning to see our stakeholders as uncooperative villains who are deliberately trying to make our lives miserable. Focusing on controlling the impact of changes on the project permits us to approach each change as a problem to be solved, just like any other issue or technical challenge.

An adjusted perspective alone won’t do the trick. We need to create the conditions that will facilitate better alignment between those who create change and those who deal with change. To that end, here are my four axioms of change:

  • Axiom 1: Document everything.

    Whether we manage our project formally or informally, how changes will be captured, evaluated, prioritized, decided, executed, and communicated needs to be clearly understood both within the team and among the remainder of the project’s stakeholder population. Additionally, every change that is requested or discovered after the fact needs to be recorded to create a history of the migration of requirements, expectations, and commitments throughout the project lifecycle. Such documentation can, and probably should be simple, but it indisputably needs to be.

  • Axiom 2: Keep it simple.

    It is a fact of human nature that people prefer simplicity to complexity. When faced with a difficult process or bureaucracy with little apparent value, most people will look for an easier way. Since we are focused on trying to control the impact of change on our project, we want to encourage our stakeholders to request changes before they begin to affect the project. To gain consistent cooperation requires that the process of requesting or identifying change be easy to engage, understand, and follow through. A documented process helps; a process that can be communicated and understood from a diagram (flow chart, swim lane diagram, etc.) is even better.

  • Axiom 3: Tell everybody.

    Ignorance may be no defense under the law, but it is a significant hindrance in dealing with changes on projects. You can’t hold stakeholders accountable for a process they are unaware of or do not understand. We have to make sure that at least all of our involved and influential stakeholders know the change process directly. It takes more that simply telling people about a process, however, to ensure their participation in and cooperation with it.

    We must:

    • Engage our key stakeholders in defining, or at least influencing, the definition of the process.

    • Recognize who the influence leaders are among our stakeholders and engage them as champions for change control on the project.

    • Remember that people learn through repetition, which means that we must systematically and regularly remind and reinforce our document, simple process.

  • Axiom 4: Enforce consistently.

    People believe what they experience and what they see more than what they are told. To maintain an effective change control process, we need to make sure that all stakeholders have to play by the same rules. In his book Influence, Robert Cialdini declares consistency and commitment one of the six principles of persuasion. The principle of consistency and commitment basically tells us that people will endeavor to act and appear to act consistently with positions or commitments they have made. Thus, if we engage stakeholders in helping to define the change control process, and we have them explicitly agree to comply with the process, then we will garner greater cooperation with the process.

    When we make exceptions in the way we carry out our process, we open the door for our stakeholders to manipulate and subvert the process. Allowing a stakeholder, say the sponsor, to make changes without adhering to the defined process simply tells others that the process isn’t really important and that exceptions are possible.

    This point should not be seen as contradicting another basic organizational concept, namely “rank has its privilege.” We can certainly “help” important and influential stakeholders comply. If the sponsor asks for change, then rather than requesting a change request form (CR)- a potentially career-limiting move - we can put the request in writing, ask the sponsor to confirm our interpretation of the request, and then execute the evaluation and recommendation steps of our process as normal.

There are no “silver bullets” in project management - especially in change control, but by remembering and adhering to these basic axioms, we can improve the quality of change control on our projects.

About the Author

Samuel Brown, PMP, is a course developer and instructor for Global Knowledge with 25 years experience teaching. In addition, he has provided project management consulting services for a variety of clients including GE, Glaxo Smith-Klein, Bristol-Myers Squibb, Michelin Tire, and IBM.

This article was originally published in Global Knowledge’s Business Brief e-newsletter. Global Knowledge delivers comprehensive hands-on project management, business process, and professional skills training. Visit our online Knowledge Center at www.globalknowledge.com/business for free white papers, webinars, and more.

© Copyright 2014, Global Knowledge. All rights reserved.

Share this article:
  • Facebook
  • LinkedIn
  • TwitThis

No comments yet.

feel free to leave a comment

Comment Guidelines: Basic XHTML is allowed (a href, strong, em, code). All line breaks and paragraphs are automatically generated. Off-topic or inappropriate comments will be edited or deleted. Email addresses will never be published. Keep it PG-13 people!

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

All fields marked with " * " are required.

Project Management Categories