The 7 Big Lies Of Managing Change

During my long career in change, I have worked in almost 20 organisations and come to know hundreds of business leaders and project staff. Here are the seven biggest lies that I have heard most often. They are heard over and over.

There Will Be Less Change Next Year

This is a regular claim, especially around budget time. Strangely at the same time, the demand for change always outstrips a firm’s capacity to deliver. I can’t recall a time when change staff were laid off because the firm had run out of things it wanted to do.

The driver is usually the need to make the financial plans that are presented to the Board and other stakeholders look good. Current projects need to demonstrate that they will finish AND deliver benefits, so they are projected to finish as soon as possible with little or no recognition of any subsequent work. Additionally, change budget is the easiest thing to cut (partly because it is the least defined and understood) if one wants to make the overall projected corporate financial performance better; it is also politically more acceptable.

When I ran a corporate PMO, every year we projected a three-year steady reduction in change spend, BUT in reality, the cost never went down. It might have been different from what was envisaged, but overall it never truly reduced.

At the same time as growing in quanta, change has steadily become more complex which compounds the problem.

The “get out of jail” card was usually “exceptional items” which were added and inflated planned change portfolios. Strangely, most years had exceptional items!

Enough said.

All our Projects are Green

This is a good one and usually exists because the organisation is not mature enough to use the Red/Amber/Green dashboard coding properly. In some organisations, despite exhortations to “tell the truth” it is still not acceptable to be anything other than green - either the reporting project manager lies, the definitions of what constitutes each colour are massaged so that only in dire circumstances is a project anything other than green, or the PMO adjust certain ratings using their own “special” perspective.

There is a lazy reason, and that is that the organisation truly does not know how to manage change, lacks visibility into the details and green just “feels right”.

The worst instance was a small’ish organisation with just two project managers when I went in. Management believed it had something like 94 live projects and every one was “Green”. Go figure.

The Project Will Cost You £5,345,254

Now somewhere a project probably has cost £5,345,254, but that is not the point. The point here is the spurious accuracy that is often demanded in planning and reporting, yet adds no value. In planning, projects are by definition unique undertakings, and thus the work and cost involved something of an unknown quantity. As a project progresses the confidence in projected numbers increases, but only at the end is it truly known.

Even if (and in some cases is it possible) one can budget the expected total spend to the nearest £5,000-£10,000, the financial machine then asks for it to be split across multiple cost types and broken down month-by-month. There is an art in doing this so that it still all adds up - something that creates a false sense of confidence/accuracy. Project managers then spend too much time first creating the “bad” numbers and then explaining “variances” when reality differs from them; time that could be better spent driving the change initiative.

You Can Stop the Project/Programme after this Phase

This is often the dream for large complicated projects, but I have never seen it delivered. Instead it always seems to be the case that when a decision point is reached, there is a compelling reason why “the previous effort will all be wasted unless we carry on”.

To create genuinely self-contained and fully justified phases that will deliver benefit even if a halt is called at a phase break, takes considerable skill and political strength. In this age of consensus management (ie compromise) and demands for quick results that is almost impossible to do.

I say almost impossible, because I do believe the framework for achieving this was described by Tom Gilb in his book "Principles of Software Engineering Management". While it address software development the thought processes are universally applicable.

As Soon as We Implement (this) We Can Redeploy the Staff

The issue here is that every project has a delivery date, ie the date it products go live, the date the “switch is flipped on”. It should also have an end date, and that end date should be different to and necessarily later than the delivery date. Unfortunately the only date that sticks in management’s mind is the delivery date and for some reason they then think that once the delivery date is past, all the staff are available for other projects and/or contractors and consultants can be terminated. They forget that there is a bedding in period when bugs are fixed, refinements made, documentation completed, the project properly closed for good governance reasons, etc..

Yes, of course there can be a scheduled rundown in staffing, but it will likely be gradual/phases.

This also ignores that staff who have been working under pressure to meet a delivery date, may need some time to decompress and recharge. Project environments can be stressful and failure to recognise that can have serious consequences.

In short plans that are built using the same resources (people or technical) and assume that if Project 1 finishes on Day 1, Project 2 will start on Day 2, will only lead to disappointment and yet more stress.

Existing, Employed Staff are Cheaper

This is a huge one and I speak as a project/programme manager, a PMO manager and a financial manager, and as a consultant when I say the true difference between utilising existing staff and employing contractors/consultants is far from clear and may well be in favour of specialist resource, especially in the core team.

While employed staff may be sunk cost to the firm and appear less expensive, their effort is almost always reduced by their involvement in other activities in the firm and BAU demands on their time. Additionally unless they are experienced in working on projects there is a significant training overhead. Part time staff rarely give even the time offered and dedicated staff can easily have 20+% of their time diverted.

On the other hand contractors/consultants, if recruited right, come with relevant experience and the ability to focus near 100% on the task in hand. Yes, there is an induction cost as they learn about the organisation, but overall that is less that the distracted effort of employed staff. Additionally contractors/consultants are not paid for their recuperation/bench time between projects.

The confusion is compounded by the internal charging rates for existing staff that rarely reflect the true total cost of employment ie the opportunity cost related to assigning them to project work.

I know that consultant/contractor rates can appear high and in the past I think that was a fair criticism, but now when you look at the full cost of employment and the continuing drive to reduce rates, I believe they are very comparable.

An interesting comment came from the head of a consultancy who said to me that today he is still billing out consultants at the same absolute rate that he was 20-30 years ago – ie rates have not risen and in fact fallen substantially in real terms.

The PMO is Here to Help

Before the lynch mobs set out to hang me, let me state that I believe that the majority of PMO’s genuinely wish to help and most PMO members I know want to help, but all too often it doesn’t feel that way to the Project and Programme Managers. The corporate drive for standardisation and ever greater quantities and granularity of information tends to create the situation where the project and programme managers are helping the PMO rather than the other way around.

Added to that is the increasing juniorisation (read “cost cutting”) of PMO roles, robs the function of the real world experience to truly engage with and assist in the real challenges project and programme managers face and need help with. I have always tried to ensure that any PMO I have created and run has enough change experience and personal “war stories” to mix well with the front line change and not just be Excel and Powerpoint jockeys.