MOSCOW - are we there yet ?

A work-related post:

Moscow - but as prioritisation rather than destination. As time is a constraint, and we all know there is always more work we could do, somehow we need to prioritise what we are doing....

Must Should Could Won't (now)

How we prioritise things consists of two elements - how important something is, and how urgent it is - MoSCoW gives us the "how important" part of this. It doesn't mean that only the "Musts" get done. But there are only a certain number of "Musts" that can be done at any time, and not everything can be a Must.

So the other part of the equation is how urgent an item is - urgency alone is not a reason to do something (see the urgent/important matrix for more on this). But if we only ever have time to do the urgent things, over time everything becomes urgent.

In reality we end up with a mix of things, like the story about how you fill a jar. You can see the "stones" as being the larger things you need to do, or as the "Must" items that go in first. And then you fill in with the pebbles, sand, water in turn.

It is often difficult to get a clear decision on what is a Must. For things like help desk calls we can define a set of criteria - for example that a "priority 1" is when a complete service is unavailable. This doesn't necessarily mean it is a "big" thing - in a previous job we had a printer down. It was initially treated as a low priority as hey, its just a single printer. But it quickly emerged that the failed printer was located in the factory and was used for printing the despatch notes as things went out of the factory. No despatch notes meant nothing leaving the factory !! That's a priority one. Having a set of clear criteria in terms of the impact something has allows the priority decision to be consistent rather than "who yells loudest". After all, as the saying goes

"A lack of planning on your part does not constitute an emergency on my part"

(I can't find a reference for that quote as it is so often repeated)

When we do hit a crisis the focus is always on resolving that crisis first, and sometimes the step of working out why the crisis came about never gets done. Without that root cause analysis, how do we prevent the crisis happening again ? Another quote, which may be from Pat Parelli but he does have a habit of quoting other people

"what happened before what happened happened ?"

In my day to day work there are often deadlines that we are working to - dates for submission of papers, dates when a project task needs to be done. As that date approaches, there is a need to know "are we there yet ?". Fairly often it is only as we reach the wire that the message comes across "no, net yet". But like any journey, if we know the route and the expected timings along that route, often we have an idea we are at risk of not being there on time well before hand.

A few times recently I've had reason to say "in reality didn't you know this situation 3 weeks ago ?" because there was something due to happen at that point that didn't. And the subsequent leadtimes and steps after that mean that if things were late 3 weeks ago, it was extremely unlikely that the end point could be achieved on time. If they hadn't caught up two weeks ago, then you start to be asking for heroics. And if they hadn't caught up by a week ago, we're talking miracles.

What stops people saying "I'm not sure we're going to make it ?" Is it a triumph of hope over experience ? Is it that we really don't like to admit we can't do something ? Is our work culture unsupportive of saying "it's not going to happen" ?

Hw do we fix that so that if we have something that is urgent and important, the right questions are asked to get it back on track ? And if it is not so urgent, so an open and honest conversation can happen to work out and agree a new and realistic plan

A collection of things (risk, leadership, Deming, multitasking)

Again based on some work posts, a collection of bits and pieces

1) Risk

I was just checking I was using the right language when I talked about risk strategies when I came across this article

The Six Ways of Dealing With Risk

I like the fact that they make the "Ignore" option visible

There is another article referred to, which in turn references a book (in German) - and as part of that they say

Note that avoiding and reducing are aimed at the causes of risks (Ursachenbezogen), while reducing, limiting, insuring and retaining are aimed at the effects of risks (Wirkungsbezogen). The two latter are seen as passive risk management (Passiv), while the three former are seen as active risk management (Aktiv).

It's kind of commonsense, but still a nice reminder to see in writing

2) Management is not Leadership

As this is a blog I should probably be preparing some well considered words of wisdom. But instead I am just going to share someone else's

a recent article from HBR: Management Is (Still) Not Leadership

3) Deming's 14 points

There had been a series of  "employee engagement" meetings, and I was in a reflective mood when I came across this blog post....

Deming's 14 points

and it seems to me that a number of these contribute significantly to employee engagement. Where they don't (e.g. End lowest tender contracts), do they still have a lesson for us ?

4) the impact of multitasking

It was interesting to come across the following piece on the impact of multitasking because basically it means that the more small projects any one Project Manager has, the less effectively they are able to work.

It's all about the journey

Change is everywhere, it is the only thing that is certain (other than tax and death !)

So often we are on TV these days we hear people talking about the "journey". It's all about the journey. So if you had the choice between

a driver you knew and trusted who had a clear and current road map, in a well maintained vehicle, on a well maintained road with clear signposts to the required destination, with good visibility

vs

a driver you don't know who doesn't have a map, on a narrow windy road on the side of a steep mountain, in a poorly maintained vehicle.... and on top of that you had to wear a blindfold

which journey would you want to take ?

It's a bit of a leading question I know, although your appetite for risk may affect the answer !

I've come across a couple of articles in change management recently. In all likelihood such articles are always out there but I noticed them because it is a hot topic for me right now.

10 key principles of change management

and this you tube video 1 minute guide to Change Management

One of the key aspects of the first part of change management is setting out the vision. Now this may be done in many different ways. For example you could paint the picture of the future in terms of the positive destination you are aiming for. Or you could describe the "armageddon view" of what will happen if there is no change. Either way you are setting out the journey, providing a roadmap, maybe even describing some of the route. And in doing so you are establishing what kind of a driver (or leader) you are.

If you don't take this step, the journey planned may be no different - but the people you are taking on that journey have no idea of where they are going, what they may encounter on the journey, or how to prepare for that journey. And all of those fellow passengers will have their own personal appetite/tolerance for risk.

It becomes kind of obvious why this is the first step in change management, assuming you want your fellow travelers to make the journey with you.... doesn't it ?

Decision Gates in a staged project process

(More work/project related content that was written at work. I'm not sure the final quote is the best - but basically what I was wanted to say was "do the right thing at the right time") I first came across a stage and gate project approach many years ago in a private sector context. Basically the idea is that every project has clear and obvious decision points along its journey. Between those decision points, the team does its work. While the overall vision is still what guides the journey, between gates the tasks and work that are done relate to getting you to the next decision "gate". At each "gate" there are a series of checks that will be done to allow the project to get a clean bill of health to start the next leg of its journey. There is an implication here that a project is never guaranteed a "pass" at the gate. It may fail the test. In which case it may either take corrective action and represent, or the project may be closed. The resulting profile of projects was referred to as a funnel - because there would be more projects in the early parts of the journey than the later. At each decision gate, the project would effectively be given delegated authority to progress and would only need to refer back to the decision group if the project went outside its approval (time, cost, scope, etc) and hence was in exception. As I have worked for other companies since then, it has become clear that many organisations use a similar approach even if they call it something else, and their project pipeline has a different profile and shape. In my (humble) opinion, one of the key factors in a successful stage and gate approach is being clear what decision is being made and what authority being delegated at each stage. For example, an early decision gate might simply be "Is this a good idea ? Does it align with agreed strategy ?". Such a decision would only require an outline of the idea and would only be granting approval/authority to take the investigation to the next stage - which in this case would be to explore feasibility and, inherent in that, options for delivery. And to make that decision (to explore Feasibility) does not require a high level of detail or fully explored Cost Benefit Analysis. Even after Feasbility has been explored, it may only be possible to give a range of figures for time, cost, scope. But the decision at the end of the feasbility work is merely to progress to refine the solution, and confirm design etc. At this stage the decision may be to exclude certain option - for example "it needs to cost less than...." or "it needs to be complete by....". But again the information behind the decision only needs to be appropriate for that decision. If you skip stages, then you are effectively also slipping decision points. So you might go straight from "Is it a good idea ?" to "Can the build/development work start ?". But if you do that, you need the information to inform the "start" decision rather than the information you would use to agree feasibility work. This may be absolutely the case where the feasbility and solution are already well defined - but if it is already that well defined, the information for a fully detailed business case should also be available with relatively little effort. If the decision makers require additional detail and information at the earlier stages, there are a number of risks. For example that the figures and detail provided are by their nature much more liable to error and will have a much lower confidence level. Relying on that detail to inform a decision that does not require it could mislead the decision making process. There is also a risk that assessing, for example, financial fitness at an early stage could provide a false sense of security and lead to less rigorous scrutiny at a later date - i.e. that there is an implicit "pass" at all future gates if the information has been seen once (despite its low confidence level). As Robert H Schuller said Never cut down a tree in wintertime

The Domino Effect and Traffic Management

(A combination of two work posts - about throughput and constraints)

1) the Domino effect of project failure

“Given the rule of thumb that one in ten projects will go badly wrong, and given a program of 20-25 projects, you will most likely have at least two that overrun seriously and will be canned. But the damage won't stop there. Those two projects will then cause the two below them in priority to be canned. Now there are four projects out of two dozen that won't happen.” The domino effect can be taken even further: “In certain instances those projects that have gone wrong are on the critical path for other projects - and they push those back as well.”

from Best Practices for Small Projects

Interesting.... and of course this doesn't apply only to small projects.

Wherever you have a constraint... time, resource, money... one project going over (or under) will impact others. In most cases a project being "under" time, resource, or cost represents an opportunity. And that opportunity will also have a ripple effect.

But where the project goes over on a constraint, then the impact is like throwing a stone in a pond... the ripples spread a very long way.

It is human nature to try and carry on with all the existing commitments as if there is no issue. But the result is that resources get spread more and more thinly, so more

2) which led me on to: Traffic Management

I've been trying to work out how to illustrate that there is a point where more projects just mean you reduce what you are delivering. Here is my first attempt.

Let's assume you have a 4 lane motorway - this represents your total capacity for work and change.

Now I have 3 convoys of vehicles. For ease of identification let's make each vehicle in a particular convoy the same colour - so I have a blue convoy, a red convoy, and a green convoy.

Because I have a 4 lane road, all 3 convoys can be en route at the same time. All my convoys can move at their maximum speed without interfering with each other. And in fact there is an empty lane so I could get one or more convoys to their destination even sooner. If a vehicle in a lane breaksdown, it does not interfere with any of the other convoys. And I could use the extra lane to make up some of the lost time. My arrival simply depends on the slowest speed in each convoy and the length of the convoy. As the last vehicle in a lane clears the start point, I can start another convoy on the road.

Now I add an extra convoy (white). This is still fine as each convoy can use a lane of their own. If there is a breakdown, there will be less chance to make up time as I will need to wait for one of the other convoys to clear the road.

Add a further convoy (black). Hmmm - now I start having to interleave vehicles on the 4 lanes as there are fewer lanes than convoys. This is going to slow up the last vehicle in each convoy getting to the end point. The planning is much more complex as I need to understand the speed of each vehicle in order to work out how best to schedule things into the lanes. There is limited room for manouvre and a breakdown is going to impact multiple convoys. It becomes much harder to tell you when any single convoy is going to reach the end point because it depends so much on what other traffic is in its lane.

If I keep adding in convoys to my road, there will come a point where the smallest slowing down in a single vehicle will trigger gridlock.

Of course for projects it is a more complicated situation in that the size of my "motorway" is not simply a number of lanes, the vehicles are all different sizes and may also require different types of road to run on.

But there is a still a point at which adding more projects in results in delivering less not more.

Liberating Disciple

(Another of the work posts I wrote)

A multinational organisation I have inside knowledge of used to have a concept called "Liberating Discipline". Although on searching to check this, I discover some of the countries knew the same concept as "Liberating Rigour". Call it what you will, the intent was the same.

"the term “liberating rigour” is used to stress the importance of standardising and simplifying where it is possible. This releases the creative energy to those areas where it really brings value to consumers."

or perhaps you could say "Don't sweat the small stuff...... it's all small stuff"

Basically the idea here is that the things that can and should be standard, common, and simple really should be. By making them so, you remove the need to continually ask "how" everytime you need to do a particular thing as it is standard, simple, and there are templates and guidance that you just follow.

The real seller in this concept is that in standarising the "boring" stuff, the bread and butter, the tasks that are effectively a commodity and need doing but do not, in themselves, require a bespoke approach....

by doing that, you free up a whole shed load of time to do the interesting things, the things that make a difference. And sometimes that is a virtuous circle where the time you free up allows you to improve, simplify and/or standardise other areas.... which frees up more time

It is such a no brainer that you have to wonder that they needed to include it in a change campaign and articulate what it meant, to convince people it was the right path.

To quote someone else's blog on this concept:

It meant that we need rigor to perform, but we have to ensure we use rigor TO liberate. That means the right type of rigor, in the right dosage, applied in the right way.

Habits require discipline. But once built, they free us, as we don’t have to fight ourselves to do the right thing. Our energy, physical and moral and even mental and emotional, can then go to performing, not trying to talk ourselves into doing what we need to.

If you want to be ‘free’ to speak a language, dance, run a marathon, understand Goethe’s Faust, you have to first engage in the ‘rigor’ of practicing the fundamentals of the language, building up aerobic capacity and muscles, cultivating a sense of rhythm and movement, deeply reading critical commentary as well as Goethe’s monumental play. Only such rigor frees us to be able to engage these aspirations.

(the other concepts were "Passion for winning" and "Connected Creativity"

The 3-30-3-30 rule

(This is one of a series of posts I wrote in work so have less of the equestrian side in them.)

I was trying to find a reference to the concept of the "30 second" rule as a test for vision and strategy concepts. The idea is that if you can't express it clearly and concisely in 30 seconds, then you need to do more work to refine the concept.

And in checking references for that, I came across an extended version -the 3-30-3-30 rule

Translating that into more local terms:

Three seconds: a headline that grabs the audience attention. Not the ordinary title people use for their site documents, but instead actually thinking clearly about what’s in it for the audience. In other words, how you would quickly describe the document to someone if you were in the lift between floors.

Thirty seconds: A very simple overview of the issue, its background and the position of your organization. Very short, if possible keep to 3 or 4 paragraphs.

Three minutes: A one-page policy brief that overviews the issue in slightly more detail. Think of this as the one-pager the author will print and hand to the stakeholders and/or decision makers.

Thirty minutes: The deeper detail providing everything the team need to be fully informed on the issue. This includes providing document referneces and links to additional resources to help provide a full picture of the issue.

Plagiarism is just another word for sharing best practice