Assurance isn’t our conscience, it’s our coach

A lot of organisations use project or programme assurance as a means of checking people’s homework.  The stance of assurance is something like a particularly robotic teacher marking an exam.  Getting the right answer matters, and the right answer is the answer in the book.  Sometimes there’s flexibility to be interpretive, but often there isn’t; and the people who work in assurance are never going to be rewarded, recognised, or praised for being lenient.  It goes even beyond this into the realm of trap laying in some cases: the assurance function are there to catch you out, to spot the kind of inconsistencies which might be poor practice, or deliberate malpractice, and ensure punishment ensues.

The attitude of change teams towards this kind of assurance is, unsurprisingly, defensive.  If the best outcome you can have from interfacing with assurance is that they don’t give you a kicking, there’s no way the change team can gain anything, and everything assurance require of you is a pure imposition.

What if there was another way, a better way?

Assurance can be a very different experience indeed.  If you provide Assurance functions and activities with a clear, simple goal: improve the outcomes of our projects/programmes; and staff them with experienced operators in the field they are assuring; if you give them a direct link to feed back to update the methodology when new things are found, and ensure they liberally share the good things they find, there’s a completely different dynamic available.

You can go to assurance, and come out with suggestions on how to fix things; a fresh perspective on problems you’ve been tackling alone; even a public pat on the back for finding a different way of doing things which isn’t the standard process (yet) but works better.  “Works better” could mean “takes less effort input for the same result output” or maybe “gets to the same result faster” but if you’re really lucky it’s “takes less input, gets better output and faster too”.

At the very least, you’ve made sure that whatever problems you are facing are transparently visible.  This can help to overcome the still-common cultural problem of burying bad news.  Everyone has access to assurance, and that means there’s a route to getting problems aired which doesn’t get blocked by, for instance, an incompetent sponsor.

This depends on what the reason for assurance is.  If you are putting assurance in place because you want to improve project outcomes, or the ratio between inputs and outcomes (cost, effort, time versus benefits), a well constructed and appropriately targeted assurance function is just the thing.

If you’re putting in assurance because a lot of projects are going wrong, and your processes aren’t being followed, well that can help too – but it needs to be backing up and supporting a review of the clarity of your processes, and almost certainly some additional training.

If you’re responding to the discovery – possibly by an audit – that you haven’t got good control over your projects, you’ve come to the wrong place.  Adding assurance isn’t how you get better control; reinforcing control is how you get better control, and while there are many different ways to achieve that, simply forcing people to get better at covering up their mistakes – which is the result of adversarial assurance (as described at the start of this piece) – isn’t going to get you better control; it might well make things worse.

Choose better. Choose improvement over bludgeoning




JFDI, or the illusion of fast delivery

Every now and then a change is issued as a JFDI.  Blanket exemption from everything, throw resources at it, just get it done.  (If you don’t know what JFDI stands for, ask someone old enough to vote).

In an organisation which has a good level of control over its change, JFDI is the exception.  In a badly run change organisation, JFDI is the norm.  In an organisation which is too rigid, nothing is ever done by JFDI.

Did I just say that no JFDI is a bad sign?  I did, and it can be. For two reasons.  First the less contentious JFDI learnings.

Organisations need to be cautious about doing change via JFDI routes because JFDI destroys value before it delivers anything.

As soon as you do something by a JFDI route, stampeding through process gates and ignoring boundaries of responsibility, you show that the organisation can ignore all those safeguards you’ve been putting in place with the assurance, training, communications, and best practice processes.  That’s a bad precedent to establish.

JFDI tramples on other people’s work.  If you aren’t on the JFDI train, don’t get in its way.  This discourages people from working on anything else, destroys teams already in place (by robbing resources), weakening committment, morale, and initiative, and harming the long-term retention of those thrown under said train.

JFDI ignores strategic considerations – in a software change organisation, it often ignores architecture and design patterns, testing best-practice and planning, stop-to-think time – whether it’s a good idea to continue or not; in a manufacturing organisation (where it’s very rare indeed) JFDI represents shipping a prototype without testing.  In some organisations it’s simply unthinkable.

The aftermath of a JFDI delivery can be wide and long.

Wide: across the organisation which has been afflicted, many projects will have been disrupted.  The cultural impact can also extend beyond the boundaries of those obviously involved – not just the team who delivered the JFDI change, nor even only those who were the recipients of the change, but also the supporting teams – the Finance team, the HR team, the trainers; the PMO or assurance teams; often the testers; IT support (both internal and for external customers).  The negative impact on individuals can, and often does, lead to staff turnover or at least burnout.

Long: change debt.  That whole class of things which are the consequence of having done things the fast way, rather than the right way – technical debt, architectural debt, training debt or process debt, organisational debt.  Technical debt and architectural debt often take years to recover from, and sometimes last the lifetime of the platform which has incurred them – with a knock on effect on many or all changes to that platform.  Training debt results in people being ill-equipped to support the change which has been rushed through, and that in turn demotivates people who are good, provides excuses for failure to all, and reduces the positive impact of whatever change was rushed through.  Process debt is like training debt, but represents the impact of not having designed the right processes in the first place, and no amount of training can fix this if the process people are learning is a bad process.  Organisational debt is a surprisingly common problem which goes unnoticed: when the organisational design has not been updated to allow for the changes which have been brought about, there are gaps in accountabilities and responsibilities – or these have been aligned to a group which doesn’t have a good, organic reason to care about the thing they’ve been given to look at.  I’ve seen an organisation which had absolutely no one accountable for shipping the product to the customer (it was a digital product, but there was still no one, and no organisational unit, which was held accountable for the customer getting the product – the IT department had taken care of it).  Changes cause creeping drift, and every now and then it’s important to realign design and reality (one way or another) and see there aren’t any gaps.

So JFDI comes at a price.

Sometimes organisations make the choice to sacrifice some of the good things that fall by the wayside during a JFDI delivery to achieve something of great value – a takeover (in either direction); hitting a particular deadline for a tremendous opportunity, or to avoid a hideous regulatory hurdle; the sort of disaster or emergency which, for instance, 9/11 represented, and what some organisations did in the aftermath of that.  If they do it conscious of the consequences, and with a recognition of the mess they’ll have to clear up afterwards, they can not only plan for that, but genuinely reduce the impact of these bad things – especially the ones which impact people.  Morale, commitment, initiative, the culture – these all rebound if they recognise that this JFDI thing is an exception, a response to something that happens only rarely, and not the normal way of doing things.

If organisations do JFDI delivery too often, the debts mount up calamitously, much like the stables of Augeas, and it is a labour of Herakles to clear it up.


If there’s no ability to overturn the fences from time to time; if there’s never a situation where you throw caution to the wind and just go for it in a JFDI manner, the organisation you’re looking at may well be suffering from being too hidebound and too cautious.  That doesn’t bode well for the future, and for fending off competitors.  I know there are business domain exceptions – I do not want to be the first to fly on an airliner that’s never been tested, or even which runs software which was produced JFDI; other than in these business domains, the total lack of JFDI can even indicate that the organisation has reached the kind of steady state without change which is the last rattle of a business dying, peacefully, in its sleep.  While a business can rarely recover from this sleep of death, it is typically only with an injection of a very different senior leadership team, and that often comes at this point by aquisition.

And a total absence of JFDI can mean that the organisation has given into the illusion that it controls its market entirely, and can predict everything; and that is also dangerous.  It means that sticking to the plan is more important than pursuing an unexpected turn, which is an environment in which very little (if any) innovation can flourish.  It can happen to organisations at the very peak of their arrogance, and topples large and healthy organisations from their commanding position.


The Matrix? Do you want to know what it is?

light green characters on a black background

Another movie quote, from The Matrix (1999).

Matrix management is a common affliction.  It is adopted as a way of managing multiple people across an organisation into different temporary organisations (i.e. projects or programmes) without formally transferring them out of their original organisations.  That’s the simple version.  The more intricate version, often adopted in larger organisations in the hope it creates efficiencies (cost savings), is where people are not only loaned out to projects/programmes, but to multiple such temporary organisations at one time.

I’ve given away my position on this in the first line of the previous paragraph.  It’s not that the idea is utterly terrible – in fact it can be done well, and have some really surprisingly good results – but the execution is usually so dreadful that I use the term “affliction” deliberately.  Let’s look at some of the worst sins.

Matrix Performance Desserts

Within the world of work we all get managed towards better performance, at least in theory.  The fact that some contractors (freelancers for those across the sea) cite annual appraisals as the strongest motivator for going that route – rather than the increased financial rewards – speaks volumes about how well that entire process is handled in many organisations.  Nevertheless, in theory we receive coaching on how to improve our performance from our line manager, who has pastoral care responsibilities for us; and in theory in many organisations they are also supposed to support our career development.

So what if all the work we do as individuals, or the vast majority of it, is done for projects via matrix management?

Time and time again line managers are divorced from the quality of their staff’s work.  Matrices are a very good place for poor performers to hide.  It makes me question the point of having any line management in the traditional sense when people within that line are spending all their productive time working in projects away from the perception of the person.

I didn’t say simply “how bad their staff’s work is”.  The lack of visibility cuts both ways. It’s demoralising to work hard for a project/programme, make a real contribution, and then discover that in your end of year review your performance has been marked as mediocre.

Some organisations have the good sense to put in place a means of recognising and rewarding good performance in a more tactical way.  I have yet to encounter an organisation which has a good way of giving just desserts to non-performers in a similar manner – if there’s anybody out there with suggestions, please pass them on!  Neither of these two are a substitute for the performance review goodies – in typical organisations your individual, performance related pay does not necessarily reflect tactical rewards at all, and permanent pay rises are more a question of the line manager’s perception than the value delivered to the company.

I have an odd habit.  I like to collect ways of saying thank you (in different languages for instance).  Last time I counted, I got to around 50 different languages I could communicate thank you in, including some very peculiar ones.  This – albeit not in different languages – is a habit I strongly commend to anyone who has to deal with Matrix Management as part of their role.  Certainly not every week for every contributor, and there will be times when it’s a lot less often, or only a subset, but cultivate a habit of feeding back about good performance to both the contributor and their line manager as a regular part of what you do as a matrix manager.

When it comes to poor performance, the same principle applies.  You don’t have to write a foul-mouthed rant about someone’s unlikely parentage and personal habits, but you should feedback, again to both the contributor and their line manager, if you can see development areas that the person needs to focus on improving.

A bit of coaching to the contributor is useful here too: encourage them to set aside that feedback, from any such matrix engagements, and use it with their line manager during the review process if such a thing happens.  (And since you’re going to be constructive if you’re giving “please improve” feedback – always – you can encourage them to consider for themselves how they can act on that feedback.).

This approach could be shocking for the line manager, so it’s worth letting them know that you will be doing this.  Make sure that they understand that if you’re going to them for an escalation, or for them to take action, you will explicitly say so to them in your communication.  Otherwise every time you do this you may be getting more and more demoralised resources.

I will be jacking back into the Matrix again soon…

A beginning is a very delicate time

“A beginning is the time for taking the most delicate care…” – Frank Herbert, Dune.

The title of this is taken from the 1984 film version of a book I enjoy tremendously, and both quotes are good observations, particularly reflecting the natural world.  New born creatures are delicate, and vulnerable.

With changes, you could be forgiven for thinking the same is true.  Certainly the behaviour around them in many large organisations would lead you to believe that.  The start of projects is often the time when bad news and negative thoughts are hidden, or manipulated.  Risks, downsides, recognised areas of doubt or uncertainty: these are not shared with the decision makers who decide which projects get to continue, and which need to wait.  People treat new projects, programmes, workstreams, unbuilt products as if they were newborn babies, gently, quietly, and with care.

The result is that far more projects (etc.) get attempted than should be; and both the inputs and outcomes of those projects are sometimes very different from what was expected.

The beginning of an endeavour like a project is not a time to be delicate.  It is a time to blow the bloody doors off.  It is a time to thrash around with the idea and see whether it really will hold water.  It’s a time to examine, to question, to try different ideas.  In a healthy, mature change organisation, a lot of changes will stumble at this hurdle.  Some will fall entirely, others will take time to be rethought and approached differently.  Some are already just right, and will go ahead with a confident step knowing that they have already been through a testing time and stood their ground.

Aside from the well known adages about the proportion of effort spent in design versus build, there are other important effects of getting things a bit more right early on, and its opposite.  Right: better-set expectations, the right support early on, well identified stakeholders and supporters.  Wrong: constant political firefighting, distracting detractors, the wrong stakeholders (see earlier comments about Decision Weakness).  Right: A good proportion of the right people in the team to start with.  Wrong: Hammers, where you needed screwdrivers.  Right: time to fight the battles that really need fighting.  Wrong: doing things you know are wrong for the business because a deadline is approaching but you can’t take the time to fix it.

This speaks to the culture of an organisation in general.  If there is a good culture of openness and transparency, the decision makers will know whether ideas are being presented to them having been through a challenging filter, and be better able to trust them; they will also know that a rejection now is not a rejection automatically forever.  If there is a culture of spin and misdirection, projects (and sometimes even programmes) will be started with the gatekeepers having one idea of what will be the outcome, when, and how, and the people in the change vehicle being launched either having a different idea or no idea at all.  “No idea at all” is absolutely fine when the people signing the cheque know that they are backing something entirely exploratory.  Indeed they should be reserving a portion of their change budget (organisation-wide) for just that sort of investment because that’s where the unexpectedly good returns and innovation come from.  It is never fine, however, when they have been sold a different expectation, and it will cause trouble for everyone involved, often particularly those least to blame for it.

One real world example I can think of involves a programme which was started with a very open idea within the culture of that programme – a “let’s see what we can achieve” kind of idea; however the parent organisation was under a much more concrete impression.  If there was a tacit agreement that it would be presented as concrete but continue as blue sky, that tacit agreement fell by the wayside when there was a change of executive management.  Suddenly the open money pit became far less open.  Expectations morphed into demands.  Before very long after the executive change, in my judgement after a generous period of time nonetheless, this programme was stopped.

In the process, the careers of the individual contributors at that institution were blighted.  They had spent a year, or several, working in a culture which was at odds with the parent company culture, acquiring a way of working alien to the parent company.  Their old positions were filled, permanently.  They were looked at, on returning, with a bit of suspicion.  By the end they had been directly disadvantaged financially – as they were deprived of performance bonuses because their programme had (abjectly) failed to achieve the targets it had been set.  If they were completely honest on their CVs when they left that organisation – many did, shortly after – they couldn’t point to the thing they’d worked really hard on being any kind of success, so perhaps even their post-company careers were blighted also.  I can think of dozens of people caught in this particular situation who had nothing to do with the failure of this particular programme.  Most of those I could see being to blame seem to be doing very well for themselves now, although I do know they too had to endure some tough days when things were evidently going badly while the programme was still being run.

Imagine instead a known, arm’s length more risk-oriented investment vehicle, created to attack innovation directly, with a properly understood acceptance of failure, and a deliberate attempt to bring things to a head appropriately quickly… no tarnishing of careers, no great surprise when it isn’t a raging success for any particular line of development, and everyone knows what they are getting into at the start.  (Incidentally, that’s what that company have now set up).

So, in summary: at the beginning, don’t handle the idea with kid gloves, beat the snot out of it.  If it’s still risky, make that really clear to the decision makers.  Changes are best beaten up early, if they are to avoid being beaten up often.



Expansion is still non-linear

Last time I blogged, I mentioned that adding extra creatives to a project is one area where extra people can make a disproportionately good difference.  Well I implied that.

As with all things, it depends; but if what you need are many creative assets created in line with a brief, I do find that adding extra creatives to the team doesn’t just result in an expanded throughput, it ups the quality.  There’s a synergy in creative activities which seems to result from creatives talking about, and sharing inspiration from, their own and each other’s art.  I’ve seen this work best for graphical creatives, but I’ve also seen this work for wordsmiths as well.

I find it interesting, and I also find it inexplicable.  It ought to work for other intellectually-driven activities too, but somehow.. it doesn’t.  The complex interdependencies of coding make that kind of inspirational collaboration something you only see on rare, beautiful occasions, and you can’t plan for it.  The nature of testing isn’t something where someone else’s results help inspire you to .. find more bugs.  Infrastructure engineers sometimes work in pairs the way programmers often do, and with a similar improvement on quality of outcome as pair programmers get – but seldom, and not reliably.  It’s only creatives who seem to really boost each other’s performance in this way.

Or perhaps I’ve just been consistently spoiled in the creatives I’ve worked with?

(In the interests of balance I should add that I can’t imagine getting a gang of creatives to collaborate on a single individual deliverable together and that having the same magical effect)

It does make me wonder whether there’s a way to get the same effect with extra coders, but without the inherent additional complexity you usually get from independent code generation.


Expansion is non-linear

One of the first thoughts when you have a change where you have more money than you can currently spend, but less time than you currently need, is often to expand the team.

This can be a big mistake.

If the current team aren’t performing as well as they ought to be, adding more people will seldom fix the problem.  Quite a lot of reasons for poor performance by a team of contributors will only be worsened by additional people.  I’m most familiar with technology-enabled changes, so let’s take a few examples from that space.

If you’re having trouble getting the build to be stable, adding more developers – and letting them code new code – will not make the build more stable.  You’ll get more new code through, perhaps, with a proportion of mistakes – Erasse humanum est (Seneca?).  If you aren’t using automated testing (why not?), adding additional testers will increase the complexity of coordination between them, eat up time while they become familiar with the product and test scripts, and differing judgements may well alter the things identified as bugs (often: upwards).  More architects do not result in a quicker architecture (quite the reverse).  More designers do not result in faster design results.  More creatives … well actually, sometimes more creatives really does improve things – and I’ll come back to that in a bit.  If your team just isn’t performing with the velocity you expect (whether on Agile or waterfall or some other variation), adding extra people isn’t going to fix anything by itself.

You have to understand the problem you are solving by bringing in extra people.  If those people can start work without interrupting those who are already working, be productive entirely independently of the existing people, and deliver product to at least the same quality, extra people can help.  So many things we do in technology changes – and in many other spaces – are strongly interdependent, however, that many hands do NOT make light work, and it is rather a case of too many cooks spoil the broth.

Sometimes, the problem of speed is better solved by taking people away.

Now I know there are times when the person everyone wants to take away is the change leader – project manager, programme manager, scrummaster, whatever.  If they are serving the team/project/programme/organisation well, they aren’t harassing for pointless updates.  Sometimes, the only thing has been to go and get the coffees, teas, doughnuts or whatever, and if that’s all I can do: good enough.  Sometimes the thing I do which helps the team to get things done is intercept all the people who are trying to find out when the widget will be finished, and lead them away.  That’s definitely a valuable service.

Sometimes, though, it’s not as nice a job as that; because sometimes the right thing to do to allow the team to speed up is to remove someone from the team.

I’ve liked a lot of people I’ve worked with; and not all of them have been good at their job.  One of the difficult tasks in Change Leadership is spotting when someone is having a negative impact on the Change you need to bring about, and removing them from the position where they are able to cause a problem.

I had a pair of programmers pair-programming in a series of sprints.  One of the programmers was a rock star – not a prima donna – but extremely quick, very accurate, very effective.  (He’s also my go-to example for why asking for a number of years of experience is a bad metric of quality – after 9 months of Java programming he was without doubt the finest Java programmer I’ve ever come across.  He still is, years later).  The programmer he was paired with had, nominally, more experience.  He was also Mr Slow.  He was not stupid, and I don’t think he was lazy; but he had no drive for programming, and his attention wandered constantly.  Adding an extra pair of programmers would have meant slowing down while they got up to speed, and wouldn’t have solved the real problem.

The urgent problem wasn’t even the velocity of the project.  I could handle the customers well enough that we were fine with that, as it happened.  The real problem was the velocity of the rock star programmer.  It was painful to watch him have to shift mental gears to try to keep coaching the other programming, bringing him on board, helping him understand what had been coded, and then letting him have a contribution.  It was even MORE painful to watch the frustration and itchy fingers when Mr Slow ‘drove’ the keyboard.  I needed to resolve this problem so that I didn’t lose an outstanding programmer for the sake of being merciful to a far less exciting one.  Or to prevent a murder.

If you’re kind, you can often find something for the person who isn’t working out to do which is more to their skillset and preferences, and makes better use of them – which, after all, is good for them and good for the company.  He made a perfectly acceptable project manager in the end.

If you’re leading a change, and there’s money on the table to help you speed up, think hard about whether extra people will give you what you need, or whether there’s another underlying problem.  Remember that just because someone is offering you what they think will help you doesn’t mean you have to take it.


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.