What is Change Management?
Change Management, often called Change Control, is simply the process of managing most changes that can have positive OR negative effects on any environment- be it IT, Human Resources, or simply the way a small office works from day to day. Simply put, it is the act of pausing the decision making process before the implementation stage to check whether if it could be affecting more than the scope of the intended activity.
A simple example might be a decision to paint an office. A manager may tell an office worker to arrange to get the office painted, only to have the person schedule it during office hours, instead of on a weekend or overnight, with a consqequential interruption to the normal flow of productive work. A short change control meeting of the stakeholders- the office workers- could have avoided the work interruptions. Similarly, if the change control group also included the corporate office representative, they may have found out that the corporate headquarters had already scheduled a contractor to do all locations, and thereby received significant savings or ensured a standardized corporate “look”.
Usually, change occurs because a problem exists in a process, and there is a clear idea for a better way to do it. While this sounds fairly easy, it often can be quite complicated and frustrating. Without a change control process in place, people will assume that any change is a good change- until it isn’t- and that’s when it becomes a problem, sometimes an expensive one, for companies.
Why Change Management?
Don’t many organizations simply allow the various department heads to run their territory and then deal with issues that arise afterwards? Yes, many do, but the ones who actively manage the change process say that extra effort pays off.
Consider: Any organization that first stops implementation- until approval by a change management group- of any activity or purchase that affects productivity, system security, safety or budgets uses their hindsight far less because they exercised their foresight.
Change will inevitably happen. However, in order to benefit from change we need to know how to manage it effectively, so perhaps we need to review some of the key points that will help us accomplish our goals.
On the flip side, when we actually have decided upon a change, we will encounter resistance. People in every organization protect the status quo, and will often resist any changes, no matter how slight they may be. Some folks are afraid of change in and of itself, while others are afraid of losing their control over a system or method- and some find no profit from changing a system that they see as working adequately.
In addition, some are threatened by automation in change, as a threat to their very livelihood, and will “silently sabotage” any efforts at improvement. This can be everything from playing dumb (can’t learn it- it’s too complicated) to actual overt and purposeful damage to a new system’s data or hardware.
Creating a change control board
Item 1: Key People
This is a critical step in getting a results oriented group: Selecting the right people. The proper temperament of the individuals is important here. People that are averse to risk to a far degree will bog down the meetings, make them long and unproductive, and ultimately nothing will be done (or if so, will be done ages past when it is optimal). We call this “Paralysis by Analysis”.
On the flip side, if the people involved do not have a knack for asking the right questions in their area, or are impatient and begrudging of the time they spend on these tasks, changes will be sped through without a real regard for process and critical thought. “Something must be done! This is something! This must be done!” leads to undesirable project outcomes.
Remember to clearly explain the role of the change control board to the prospective members: This is not where projects begin, it is where they become implemented. It is not for the change control board to be the final arbiter of what projects get blessed, but to see that the changes impacting the environment of the company are well thought out and understood.
In example, a marketing group may have made the decision to switch to a Macintosh based art creation system (or from one) for ancillary marketing and sales materials. It should be understood that the manager of this area has a deeper understanding of his departments needs, and those of his customers and employees, than the generalized people on the board. There may be good reasons to temporarily stall the project- say the network folks need time to look into implementing Appletalk across routers and it’s impact on the Network- but this is not the time for someone’s personal biases or opinions to be used to try to kill a project that has ostensibly already been blessed and funded.
Do you know what you are “looking” for?
That is not to say that some projects won’t be found to be unviable as originally depicted at the change control stage- far from it, in fact.
A security plan to install cameras to allow remote security personnel to see the face of a person as they presented their corporate ID’s was stopped by an HR person at a multi billion dollar corporation in the Midwest.
Why? Because the proposed project included a specific location of the cameras, which demanded that people bend over to place their badge onto a mirrored surface for reading while looking into the camera (They customarily wore them on lanyards around their necks).
When the installation was presented to the board prior to beginning the work the next month (which was designed, tested and created by the all male work force in the technical services department), they did a run through of the process using each of the members of the change control board -which included several women.
What was revealed was… revealing, to say the least. By assuming that particular posture, the security guards cameras were looking straight down the users necklines as they were admitted- which was noticed by all looking at the monitors when they watched each other go through the mock entrance they had made.
So, another project that needed some outside perspective before a potentially expensive re-modification was needed. Challenging our assumptions at the change control stage saves money, time, and potential embarrassment (or possibly even lawsuits!).
The Core Group
At the least, people should be available from the following departments (with some variety of expertise):
- Technical services
- Help desk
- Network
- Purchasing
- HR
- Marketing
- Sales
- QA/QC
- Security
- Maintenance
- Production
- Legal
- Specialty skills (In a trucking firm that would be mechanical, fleet ops, dispatch, etc.- in a Tech services firm that might be Lotus Notes developers, Oracle development or software assurance managers and Exchange Administrators or SAN managers)
In some companies it is not practical to have the entire set of personnel above meet on a regular schedule, so a core group may be whittled down -with an ancillary group, or alternates individually -available for consultation or attendance when warranted. Again, at the least these folks should be designated so that they are available for comment after the meeting where the change is first presented. In some companies certain individuals will fulfil one or more of these roles.
Item 2: Key Areas
- Identification
- The written procedure should cover the identification of the changed device, assembly, component, labeling, packaging, software, process, procedure, manufacturing material or any other related item or document. The change control form should have blanks for recording this data and other data discussed below.
- Effective Date
- The procedure should cover the effective date of the change -which is usually a completion date- or an action to be performed when a specific event occurs, such as “implement the change when the new router is installed, configured, and operational.”
- Responsibility
- The change control procedure should state which department or resource(s) is/are responsible for each function to be performed. Be sure to specify which agency is responsible for the completed change control form. Also, be sure to point out if there is any extra level of management oversight required (and by whom, specifically) during the change.
- Revisions
- Which manner will be used to handle revision levels? It is common practice in many industries to use numerical revision levels during pilot production and planning, and transition to letters during implementation. This allows “At a glance” verification that you are on current doc sets.
- Validation
- Each changed device or process should be thoroughly tested or endorsed by the appropriate department(s). The results of the change -and all information related to the change -should then be reviewed by the change control board (or other designated review group).
- Communication
- The change procedure should cover the communication of changes to all stakeholders.
- Updating Documentation
- The change procedure should cover updating documentation such as network maps, user instructions, etc. It does little good to upgrade users to a new version of an office application if the intranet help resource still refers to old versions.
- Documentation Distribution
- Documentation should be distributed to persons responsible for the operations affected by the change and old documents removed wherever they may reside.
- Follow-up Tasks
- Change affects the system, and the system may need some tweaking in certain areas if it is to be beneficial in as many respects as is possible. The change control procedure should outline the steps required.
- Regulatory Submissions
- Some change may involve filing or even prior approval from governmental agencies. Modifications to devices or manufacturing processes should be made and covered under a QA/QC change control procedure.
- Business Factors
- Financial impact, the modification of marketing and sales collateral, update of products in commercial distribution, or a change in the way visitors or customers access systems should all be considered by the board before granting consent.
- Quality Assurance Review
- Any change also needs to be correctly implemented. Quality assurance personnel can ensure that the change is functioning as planned.
The Framework
The following are generally considered to be the proper steps or framework within which to study and implement changes.
Project Evaluation:
Who will implement it and who is affected?
- What do we need? What is it worth to us? What does it cost?
- Why do we need it?
- When must it be in place?
- Where will it occur?
- How will it be done?
Challenge each assumption for due diligence.
The following areas need to be properly explored by the change control board.
- Research: Mapping your Path, planning the work, work the plan
Does the proposed change seem adequately thought out? Don’t be hesitant to send them back to get more data to ensure the proper research has been done to ensure the change has a manageable impact on the stakeholders. - Design and Scheduling: Be sure what we are putting together goes together
Check the assumptions- i.e., a Network that has Mac clients usually needs Appletalk on the routers for direct printing- is the proposed change of turning it off really what should be done? - Development/Implement: Do the work
Calculate the resources available versus time to implement the change. Are the proposed changes assumptions workable? - Training and support: Give the users the tools and know-how to be successful
The best change control boards are the ones that don’t have to deal with unsatisfied users afterwards. Proper training on changes minimizes the grumbling.
Project re-evaluation:
It is also a great idea to do a Post Mortem, or follow up on the change control items after they are implemented- whether successfully or not. Here are some points to go over afterwards.
- What variances from the expected outcomes were encountered?
- What did we do right?
- What could be done better for future projects?
- Were our initial assumptions correct?
Finalizing the documentation
Getting the docs together will save time and money when issues need to be addressed or the process needs to be duplicated elsewhere in the organization.
While at times this can seem an onerous or burdensome task, we really go through these steps anyway- just in an informal and often haphazard way. By forcing structure onto the process we can guarantee that we at least mitigated some of the negatives by ensuring as many as possible of the affected groups as is practicable are involved, and have the opportunity to voice potential issues or pitfalls- or even highlight some great advantages previously unforeseen.
Since it can be difficult, I have attached a pair of documents to this article. The first one is a template you can use to follow through a complete change control cycle on a given project. The second is an illustration of a fictional exercise so you can “see it in action”, so to speak.
At its basic level, a great change control meeting can be as simple as bringing up a list of proposed items at a weekly meeting.
The attendees make a note to address any concerns they may have during the course of the next week, at which time they reveal their findings to the rest of the group, who all do the same. A short conversation is had on the topic, and a decision to go ahead, suggest more research of a specific type, or to table it until a future specific date is reached.
It doesn’t have to be a long and drawn out, burdensome affair- in fact it can often be the highlight of a weekly status meeting, as the change control is the area at which the “Green Light” is often granted to a project, and things get done- or not- because of it.
Sample Change Management Documentation
Chewing the pencil?
No worries. Here with the article are two Word files. The first one is a template for a Change Control document, and the second is a Sample one made out to a fictitious project, using the template.
Load comments