The 3 Elements of Change ManagementAbout Change Management
I’ve read books and articles over the years to try and help me improve my management techniques around all aspects of project work, especially Change Management. There are some very good articles on Change Management around from some very experienced Project Managers. There are also some very good industry standard methodologies which will attempt to guide you through the ins and outs of Change Management, amongst other things, and they are also very good.Will any of these articles, books or training courses remove the challenges of Change Management – I don’t think so. Remember this always “Projects are about People” and then you’ll always be sure to blame the right aspect of project management on it’s core failing – it’s always the people that catch you out.Lets briefly look at the three core elements of Change management then, that make this a special sort of headache for all project managers. In doing so lets first distinguish between change brought on by the nature of the project and change within the project. We’re interested here in Change within the Project – which is Project Change Management. More about the reasons we make change and use project management to deliver that change in another article.The 3 Elements of Change Management:1. Causes and Drivers of Change
2. Impact of change and getting agreement
3. Implementing change in the project (or program)Well that wasn’t too painful was it? If only life was this simple. If you take these basic elements and build a simple process around them you’ll get a reasonably workable process flow which identifies basic causes of change, such as;Change Management of Planned Changes – for example;agreed upgrade in a solution as part of a strategic program who’s conclusion was announced after the project started.
value engineering where the project has an opportunity to embrace a new approach to the advantage of the whole project, to reduce costs etc..
unplanned business growth requiring an expansion (or contraction) of the final solution.Change Management of Unsolicited or Unplanned Changes;Client decides part way through delivering a project that they don’t have enough meeting rooms and require a re-design of floor space to accommodate more.
Increase in scope of the conference facilities after they have been built, to include new/additional technologies.
change in senior management who decides he wants the floor plan changed to meet his “new needs”
- my favorite – a complete re-stack (re-shuffle of trading teams) of a trading floor because the wall of screens from one team block the main view out of the building, a week before go-live.Change Management of Emergency Changes;Fixes to critical components as a result of damage caused through some uncontrolled event – accidental flooding or collapse of some critical infrastructure.
Changes to critical components brought on by poor planning and failure to predict accurate requirements. You got caught out! – yes it happens.
Impact of dwindling resources (budget) forcing the need to adjust the solution quality or schedule etc.There are other elements to Change Management – at a higher level it’s the communications before, during and after projects. Within the project it’s about managing expectations and being able to predict or foresee the impact of a required outcome, and “coax” your customer along the right path to retain their support and the momentum in delivery.Change Management is an essential Control component of any project. You will need the following ingredients in place to make change work;1. An agreed and signed-off scope of work clearly defining the deliverables and constraints
2. An agreed (and proven) change process which will take a change input (request) and provide:
Complete description of the changeWhat’s driving the change
Impact on schedule, cost and quality (final deliverables)
Who raised the change request
Who approved it
When it will happen
Who will action it
If change is denied, then a sign-off to that intent.3. A communications forum where Changes are regularly reviewed and all impacted parties are present for comment.4. An appointed Project Board or Steering Committee where there is the authority to approve changes that impact the project beyond the authority of the project manager or project team to decide on.Remember – Change Management is all about people. You need to identify the change and it’s impact and then get the right people to agree to approve or decline the change request based on facts and credible experience (sometimes).This sounds easy but on small projects people can get very protective of their “perceived control” or authority and the project manager may become hamstrung to make basic decisions or to manage the sometimes unreasonable requests for changes from customers staff. On large projects Change Management can and often does become a full time job with a dedicated team doing nothing else but review Change Requests and facilitate the right communications forums and approval meetings.Basic Change Management Process flow
Process ->
Recognize Change request ->
Document it ->
Review it ->
Analyze Impact ->
Present to Change board->If approved, re-plan program to include.If denied, close it and get on with life.Of course, this is just one view of Change Management based on 30 years of delivery experience. Each Project Manager will have there own view but I doubt that any experienced Project Manager will argue with the above but would embellish it with there own invaluable experience to put more “meat on the bone”.

In this article we will examine the main constituent parts which make up program management as carried out by a program manager. Firstly, let’s define what it allows you to do: it allows organizations to manage complex bodies of work that combine software elements, hardware elements, new or changed business models, and changes to organizational structure and capabilities as a whole. It allows us to do this in a way so that the organization realizes benefits that it could not achieve if the program’s constituent projects were run separately.Now let’s examine the main components of program management:GovernanceThis aspect is concerned with defining the structure so that the program can be guided, both by the program manager and by senior managers. It is during this phase that roles and responsibilities will be defined. While the structure for managing projects is normally quite simple, the structure for managing programs will typically be much more complex, spanning multiple divisions within the organization.ManagementThis aspect relates to the planning and running of both the projects which make up the program and the overall program itself. They are accountable for every aspect of quality, schedule, and budget. They will approve the project plans and provide guidance to the project teams also.FinanceThis aspect is concerned with the financial policies and practices governing the program execution. Because programs are much larger than projects, there will typically be, not just a greater cost incurred in running a program, but also a greater variety of costs incurred.InfrastructureIf anything, this is the aspect of the role that most resembles project management. By Infrastructure we are referring to a variety of different things. Making sure issues are managed. Making sure that risks are managed. Ensuring that resources are coordinated. It also encompasses making sure that all communication is well thought out and well coordinated.PlanningProgram management is also concerned greatly with planning. This is not planning how you might think of it within a project management context. Project plans are concerned with deliverables and work packages. Program plans are an integrated visualization of the key deliverables of the program, and they will be structured such so as to best realize benefits to the organization.All of the above categories may seem similar in essence to project management, but they are not. In program management these activities are much broader in their scope and concerned with benefits rather than deliverables. I hope this article has give you a good overview of the key aspects of program management.

All of us have been part of an effort that, for some reason, did not turn out as we intended. It could have been something as simple as that new omelet recipe you wanted to try. Why didn’t your omelet look the same as that pretty picture on recipes.com? Or it could have been the 2013 rollout of healthcare.gov, the beleaguered web portal of the Obamacare initiative.Somewhere along the way, something went wrong with that omelet and with Obamacare’s website. Identifying what went wrong (and quickly) is a big part of what change management is all about.What is Change Management?Whether the goal is to make an omelet or to roll out healthcare.gov, it is important to realize that these products came into existence only after the completion of many individual steps. In the case of the omelet, you beat the eggs, warmed the butter, diced the fillings and so forth. Your future omelet will eventually come from this soup of ingredients.This soup of ingredients undergoes major and minor changes as you progress through the recipe. The current state of your omelet can be called your “as-is state.” From this as-is state, you make a series of observations and form the “baseline” mental image of your omelet. As you move ahead to the next step in your recipe, you remember this baseline and monitor what the next change does to your effort. You can likely identify a problem faster if you pay attention to what things looked like before.A lot of change management is simply empirical observation. With a good record of changes and whether the result was positive or negative, the bad outcomes can often be minimized and the good outcomes made more frequent.Advantages of Change ManagementIn practice, change management has great practical value to the enterprise. Many organizations are subject to regulatory agencies or laws. For example, U.S. hospitals and healthcare providers are subject to the Health Insurance Portability and Accountability Act (HIPAA).One technical provision of HIPAA is that healthcare providers must safeguard against unauthorized changes to a health record. In this scenario, change management is not simply a benefit but a requirement. For example, if a patient has a documented history of an allergy to penicillin and his record is erroneously updated to report no allergies present, monitoring may help catch an otherwise deadly mistake.For undertakings that involve many steps or many changes, change management can offer a clear reversion path. The record of change is the “trail of bread crumbs” that gets your product back to a functional state. Let’s say that you are working on an Excel spreadsheet with many embedded formulas, each of which references a specific location in the spreadsheet.If you start introducing a lot of changes all at once – moving around columns and updating formulas in the spreadsheet – you may find that some of your formulas no longer work. But which change broke your spreadsheet? If you can’t identify the change(s) that did, you may have to redo all of that work.Another advantage is that it helps preserve institutional knowledge. In large programming projects, for example, the product manager can review the state of the application over time. Each code change or revision is typically checked in to a repository as a sort of archive. The entire evolution of the application project can be observed by looking at these snapshots in time of the code. As a result one can begin to understand the way the product has changed over time – even if the original programmers have long since left the company.Challenges of Change ManagementChange management is often unpopular due to the increased overhead it brings. In fact, if done poorly, it can bog down the output of the entire organization.There is a cost associated with change management. That cost can come from the time it takes to train staff to use the new process. There can also be capital expenditures if the company decides to purchase a CM software application.Perhaps the most serious challenge to consider for change management is the overhead it may bring. If the process of change management is more onerous than making the change itself, the CM process may need improvement. If change management is not handled in an efficient manner, the new process may not gain acceptance and consistent use. Worse, the rank-and-file staff may quietly lower their output to the business as a way to avoid using the change management process.Recommendations for Change ManagementBefore rolling out a new process or buying new software, the business should identify key stakeholders for the effort of rolling out change management. A project sponsor should be identified that will act as the owner of the project. Together, the stakeholders and project sponsor should identify what needs the project must fulfill to be considered successful. Desirable features can also be included alongside project requirements.Once the project team is identified and the goals listed, the team should examine what resources should be involved in determining the necessary steps to accomplish those goals. Many goals in the project will likely reveal an interdependency between two groups within the business: for example, the rank-and-file’s acceptance of the change management systems, and the executives’ ability to provide an efficient and functionally relevant system.Failure to meet such an interdependency can risk project failure. Therefore, it is important that the project team hold conversations with staff outside the project team to determine what an efficient and functionally relevant change management system might look like. This can mean lots of conversations and interactions with entities across the business.If requirements, interdependencies, and functional concerns are addressed prior to rollout, the business will have an accurate idea of what their change management system will need to be successful.