How to Implement Significant Change


Managers live in a world of spreadsheets and slide decks.  The problem for managers who want to see actual change implemented is that companies are really just groups of people and people don’t operate in the same way as spreadsheets and slide decks.  Things get messy and emotional very quickly and the challenge when managing the organization through a significant change is not in checking the box for each activity that has to be undertaken but in understanding how people will react and helping them to navigate through the change.


This may be viewed as heresy by purveyors of project management techniques and certifications, but line item planning of activities doesn’t always work well in a business environment.  There are environments where the steps involved are predictable and immutable.  For example, the steps involved in implementing a software package are well known in advance and the duration and resources required for each step may be estimated with a reasonable degree of accuracy.  However, if the project is to implement a new organizational structure, build a new function, implement new ways of working, or other people-intensive business initiatives, the steps are known in advance only at a high level and the bulk of the implementation effort is spent on the ‘how’ rather than the ‘what’ of the activity.  It makes sense in these situations to work toward milestones rather than activities.  Milestones have the advantage of acting as signposts on the journey while being blind to the method of arrival.

This author once worked in the program management office (PMO) for a large program with a budget of $800M.  The goal was to split off one business from within a financial services corporation and float it independently on the stock market.  This involved the execution of more than 300 individual projects.  What tool was used to coordinate activities on such a massive program? Microsoft PowerPoint.  Sitting in the PMO, my team had access to the plans for each project and we quickly realized that those that were technology related had well defined activities that could be documented in project management software.  Those that were more business related (e.g. build a Finance function) contained too many unknowns to define activities at a detailed level but instead had very well-defined deadlines.  Focusing on milestones therefore provided a language that could be understood by everyone involved and avoided the creation of granular but inaccurate activities.  We used a simple graphical method to communicate status on the key milestones to the stakeholders so the message could easily be understood.

Milestones create a goal-oriented mindset while activities give the impression of being busy.

Rather than being viewed as an embarrassment, not knowing exactly what your project will be doing six months from now should be accepted as realistic.  A project manager should know at a detailed level what is happening over the next few weeks, at a higher level what is happening over the next few months, and at an even higher level what is happening over the next couple of years.  To try to add more detail is a waste of time, and creates a false level of precision at the cost of accuracy.


If you want to implement changes and have them stick, then you need to bring people along with you.  There are as many different reactions to change as there are people in the workplace but some broad patterns exist.  Those employees on the front lines recognize that there are issues with the current process and structures, since they feel the pain every day.  The senior management is paid to improve the company’s performance and so has to at least be seen to be trying to implement change.  Middle managers, however, are often the most impacted by change and don’t always benefit from it.

How then do you bring people along if they aren’t particularly enamored by the thought of the journey or the end destination?  Involve them.  Don’t just involve them in the implementation of the changes; involve them as early as the design phase.  Turkeys are never going to vote for Thanksgiving, so there may be a limit to the scope of changes that people will offer up. However, this author has been surprised on several occasions by the willingness of employees to recommend changes that help the business but hurt them individually.  So long as the analysis and design process is viewed as fair and transparent, people will generally work with it.  There are several tools that can help in this regard:

You can’t always make the journey painless for employees but you can always show respect.

  • Brown papers are a wonderful way to document processes or organizations and to solicit feedback. Their large size and work-in-progress nature encourages people to comment directly on them.  When an employee makes a comment that they know is going to be read, they feel that their voice has been heard, even if it is just in a small way.
  • Focus groups can be used to obtain input from several employees at once. They work best when the participants are in the lower levels of the organization and don’t tend to worry about the political implications of their statements.
  • Design sessions can be organized in a way that is open, with all stakeholders present or available. If you contrast this with sessions that take place in smoke-filled back rooms, the former designs tend to stick much better than the latter ones.
  • Era charts are a way to document the progression of specific elements of the business across time, in a way that is visual and lends itself to comments. These can be used to communicate the logic of the change and solicit alternative visions of the future.

These tools are all ‘high touch, low tech’.  This is the essence of change management.  This paper is not meant to be an explanation of change management and much more could be written on the subject than would fit on four pages. Consideration for employees and the journey they are on should be reflected throughout your project even if you don’t set up a specific change management stream of work.


There are few things less useful in business than the monthly project steering committee meeting.  Project managers spend the week prior to the meeting documenting accomplishments and next steps instead of working on the project.  In the most egregious cases, project managers have to submit their status reports a week before the meetings so that participants have time to read and internalize the reports.  If an issue was to arise as the report was being produced and it needed stakeholder resolution, then it could wait for more than five weeks to be discussed.  Does anyone honestly believe that this is how the world works?  When the governance process is this slow, people just circumvent it, getting decisions informally and using the monthly meeting as a rubber stamping exercise.

If the project doesn’t require a forum of stakeholders to make a decision, then the best course of action is to send out a one-page weekly status report and let everyone get on with their day jobs.  If a meeting is needed to make a decision, then pull together those stakeholders as soon as possible, make the decision, and then let everyone get back to their work.  If this means that someone is left out because four weeks’ notice wasn’t given, then so be it; there has to be some trust among executives.

There are some corporate cultures where decision making is centralized and a lack of involvement is interpreted as a lack of power.  However, the communication of status on a weekly basis actually provides steering committee members with more information and on a timelier basis than if they had to wait for a monthly meeting.  It also allows them to become involved to the level that they see fit.  If they have a strong interest in the project, then they can respond to the information that they receive.  If the project has less of an impact on them then they can treat the weekly status update as an FYI.

This author’s favorite example of stakeholder involvement concerned the financial services client referred to earlier in this paper.  The program leads met with the sponsor once a week for thirty minutes.  The sponsor had a clean desk policy: no paper was on his desk when we entered the room and there was to be no paper on it when we left.  We talked through a list of issues and he responded by making a decision, calling a specific individual to obtain a decision or action, or emailing several individuals if that is what it took.  This last option was our sponsor’s least favorite.  We normally had resolution on every issue before we left the room.  On only one occasion did the sponsor call a meeting with the other key stakeholders to make a decision.  We complemented these meetings with a brief weekly status update to the stakeholders that focused on exceptions to the plan.  This system worked extremely well.


Companies implement change in order to realize benefits.  Why then do companies not track the benefits that they hope to realize?  The simple answer is fear of failure.  If you, as project manager or project sponsor, sign up to deliver a project, then you take on some risk.  If you sign on to deliver a project with an expected $10M in annual benefits, then you take on even more risk.  If the project is implemented but realizes only $8M in annual benefits, then did you fail?  In some corporate cultures, this would be seen as failure even though the project was successfully implemented and there was a positive financial impact.

This author was once involved in a sales effort to implement resource planning software, a new supply chain footprint, and a shared services infrastructure.  The total cost was estimated to be in the order of $300M.  The potential client, a bottling company with annual revenue of $16B, had a lot at stake in the program, so it was highly visible.  The two competing vendors were within a hair’s width of one another on cost but one had estimated the annual benefits of the initiative to be in the order of $150M while the other estimated no financial benefits.  The primary buyer selected the vendor with the marginally lower implementation cost and total lack of benefits.  As a member of the losing team, this came as a shock at the time, but it is obvious when you consider the risk to the buyer that both the lower cost and the lack of attributed benefits would have been seen as advantageous to him.  Unfortunately for his employer, they lost out on significant financial benefits because of his fear of failure.

$150M in annual benefits were not pursued because one person was afraid of being seen to fail.

In order to make it safe for someone to sign on to deliver benefits as a result of an initiative, the targets must be seen as a best guess based on the information available at the time.  If the project is long term, then the business environment won’t be the same by the end of the project as it was when the business case was built.  The actual benefits realized may be higher or lower than originally estimated but it is virtually guaranteed that they won’t be exactly the same.


When implementing significant change, there is a need for flexibility to accommodate the realities of business and the needs of individuals.  Implementing change is like undertaking a car journey with people who don’t necessarily want to be there, and simultaneously having to react to diversions and bad weather along the way.  There is a clear objective and there are a few rules that you have to follow, but good humor, humility, and the ability to respond appropriately will be the primary determinants of how well the journey goes.

If you would like to discuss this topic in more detail, please contact us at