That old sinking feeling

Whenever you take over a change of any size, you spend some time getting to grips with what has gone before.

As an aside – the ability of an organisation to pass a project (programme, workstream, change) from one person to another and be confident that there will be a decent continuity of knowledge between the two people is a key marker of maturity in change leadership.

I like to start by getting to know some of the people on the change, because that’s after all the only way to get any change delivered: working with people.  You find out a lot, often things that aren’t related to the change itself or their ability to work.  But directly and immediately relevant: you also find out things which aren’t documented.  In my experience, always.  It doesn’t matter how good the handover has been, or (at least so far) how comprehensive the documentation, you’ll always turn up something extra by talking to people – well in fact, mostly by listening to them.

Listening is in every field a key leadership skill.

You can find out how people feel about working on a project (even if that’s not what they are talking about) by what things they think you ought to know.  You can find out a surprising amount about their ambitions and career development goals in some cases – information they just don’t share with their line managers for a variety of reasons.  And most likely you find out things about the change you didn’t already know, from the documentation, or from the handover.

In an Agile project you often get to find out things like which person estimates high in the planning you do (I personally like planning poker, but other methods work too).  You can find out little things that help you to motivate people – that Jane likes coffee, that Bob likes Early Grey Tea (and doesn’t like Star Trek), and that Sam can’t resist cakes or biscuits, but really wants to.  Most of all, you can find out how coherent a change team has become – how much they have gelled – by the way they talk about each other, and about the change.

Or, and this comes back to the title of this article, you can find out that the team don’t agree on what the goals of the change are.  You won’t find that documented in quite that way in most handovers – and a lack of transparency in the culture (we don’t want to hear bad news) is often at the root of that. With any kind of waterfall project, a vague, badly understood scope, is a sign of Bad Things.  It’ll surprise some people to hear that it’s as bad in Agile too, but exhibits itself in a different way.

In all organisations – if you know differently, please do let me know! – there’s a limit to the resources available to bring about any particular change.  In waterfall style projects that’s often set up front, before you really know the detail of what you’re going to deliver, and at an early stage you try to estimate how badly wrong you’re going to get it, and call it contingency.  In pragmatic Agile, it’s often the case that you get given enough money for a set number of sprints, and a relatively fixed business goal, and you do your best to achieve it.  (In platonic Agile, where the world is organised entirely around Agile, you don’t have to do this because you start earning real business value along the way and people are happy to fund you forever or what passes for it).  Sometimes the budget cut off expresses itself in a different way – a restriction on the number or size of teams, periodic reviews of value achieved – but in principle there’s a limit to the blank cheque, and you need to deliver within that limit.

In waterfall, everyone expects you to come back and ask for more money at some point.  (I know that it doesn’t always happen, but it’s common).  In Agile, and for good reasons, the dynamic is different: but even in Agile, if you don’t focus on what your business goals are, on what you are trying to solve as a problem, you will drift.  In neither case is it the responsibility of the people I talk to when I’m taking over a change to either fix or even identify the problem.  Some do, some don’t, I consider it a bonus when they do.  However, change leaders can diagnose that this problem exists when many people you talk to have an idea what the scope / goal is, but they are all different.  (If no one has any idea, the problem might be this, but it might also be a terrible communication culture, and that’s entirely too common too).

If you take over a change, and find this problem, you probably just found your top priority thing to fix.

Lessons Unlearned Again

Within the legion of people some organisations employ to help guide change to a safe conclusion, there are many people doing a difficult and often (sadly, literally) thankless job – the PMO.

Let’s leave aside for the moment discussions of whether Agile doesn’t need a PMO (or project managers) because that’s a different discussion for another time.  A lot of places still have them, and they deliver a lot of value.

It is extraordinary the range of skills you come across in a PMO organisation.  I’ve seen the full range from people who just help out a bit with the administration of projects, right up to people who, if they were to choose to do so, could without difficulty run an entire project and programme management practice, or be a very successful programme director, all called “PMO”.  Some people choose the PMO path because they think that they will help more that way; some choose it as a way into project management; some choose it as a way out.

A PMO within a programme has a lot of responsibility, but also a lot of influence and even power.  A good PMO can make a change leader’s life considerably easier; an influential one can make it much harder; and let’s consider too, there are some change leaders who need their life made a bit harder, because for example they are running their change (project or programme) ineptly, or even with malice aforethought.  As long as the PMO isn’t too entranced by, or unduly influenced by, the change leader, they can act as a brake on things going too far wrong.  That’s one of the good reasons for having a PMO reporting line as a practice which doesn’t run too close to the change leader reporting line.

At an enterprise level, if the PMO is divorced from the day to day realities of make change effective, something else happens. The tendency to focus inwards, on tools and processes and project management artefacts (seldom programme management artefacts I note), seems to increase over time.  One of the most important things for any PMO which includes process or methodology responsibilities (and setting up governance definitely has a large overlap into methodology) is feedback.  Ongoing and continuous, detailed, and evidence based feedback.  When you lose this, the Enterprise level PMO particularly runs the risk of proliferating practice but failing to understand either the impact on the changes, or the benefits (disbenefits…) of the processes they create.

When the number of mandatory deliverables just keeps going up, and the intricacy of the process persistently increases, it is time to refresh your EPMO with an influx of new blood.

 

Lessons unlearned

Many of the challenges of bringing about change in organisations are the same, but starting at a new organisation and encountering things again which I thought were old problems, long since solved, the last time I saw them reminds me that while there will always be someone ahead of you, there will also probably always be someone behind you.

When you start at a new place, and you are focused on delivering change, you start to look for the things which are going to cause you problems straight away.  In some places, it is resources – getting the budget, and the people, to realistically do what is required of you.  In other places, it’s that you are a captive organisation – an organisational unit belonging to another, far larger or more powerful organisation, and unless your priority becomes their priority, making change happen is extremely hard indeed.  In some places the enemy is the process.  In some, it is the lack of process.  Surprisingly often, a challenge will be something I think of as “Decision Weakness”.

Decision Weakness is a combination of a couple of factors.  The most obvious one for change leaders is: the inability of the (nominally) appropriately empowered leaders to make decisions.  This surfaces in a number of different ways, but a very common one is the desire to ship off the decision to a number of other “leaders”.  Trying to pin someone suffering from decision weakness down to making a decision without escalating it so far up the tree in a given organisation that you can never get that higher echelon’s time is frustrating and often fruitless.  This results in a waste of more senior people’s time and an astonishing proportion of the delay in getting changes delivered, or even more so in getting them stopped when their business case no longer holds water.

Decision Weakness also manifests in another way.  I’ve often referred to it as “insincere signoff.”  The person making the decision has a momentary rush of blood to the head, and actually agrees to something.  Be careful that you have this recorded in some unambiguous manner, because what will happen later – either as a result of buyer’s remorse, or as a result of a strangely inaccurate memory – is the denial of the decision by the decision maker.  This insidious problem can be very damaging to change leaders – typically more so to project managers, whose decisions are nearly always provided by external resources – but they can bite programme managers and directors when the decision weakness is far enough up the chain; or when for instance the host organisation’s operational leadership agree, then later disagree, to host the organisation and change output created by the programme.

Frustration sets in all around with Decision Weakness.  Those more junior see the decisions being made, then unmade; or stagnation setting in.  They quite rightly feel indignant that their efforts are not being allowed to be successful or proceed because of the failure of someone more senior – often quite a lot more senior – and if they aren’t fit to take these decisions, why are they in the more senior role?  This is a question I often have a lot of sympathy with.  If you can’t deal with the increased responsibility, don’t seek it, don’t let it be thrust upon you, or at least have the backbone to delegate to someone who can, and defend that position.  It also causes frustration in more senior – often Cxx level – executives, who have a view that change should happen, they want it to happen, and why isn’t it happening?

The organisations I’ve seen this most prevalent in are the ones where there are both too many levels of management, and too many managers.  This Decision Weakness stifles innovation; slows all kinds of change; kills agility; wastes a great deal of effort – both financially, but also precious focus, which large organisations already find it difficult to muster; and it drives good, agile, delivery-focused people out of the organisation to somewhere where they can get things done – compounding and accelerating the issue.

Decision Weakness.  It’s a bad thing.