Bishop's Blog

Previously we have looked at the power interest matrix for helping you map and manage your stakeholders.  Now we will turn our attention to an Energy vs. Commitment matrix.   Now you plot the individual stakeholders and stakeholder groups against these criteria – their commitment to you change / programme and their natural energy for communicating and acting – which gives us four groups:

Tags:

I was once again reminded of the scourge of unproductive meetings the other day.  There is a whole industry around meeting effectiveness and I cannot do it full justice in a single post.  However, here is a list of useful pointers for managing effective meetings.  I am referring to general meetings rather than specific Agile meetings like the Daily Stand Up.

#1 Start on time

Many people would tell you firmly never to arrive late for a school exam or a flight or a job interview.  Yet those same people would think nothing of arriving late at a meeting.  In fact I know some places where this almost seems to be a badge of honour, the best people are the really busy people, therefore those who always arrive lates must be really busy and rushing from one vital meeting to the next.

#2 Finish on time 

There is also the simple maths problem - most people start meetings on the hour, finish on the hour, have scattered meeting rooms and often have back to back meetings.  I would propose that not only must you finish "on time", but "on time" must leave time to get to the next meeting. So meetings should end at 5 or 10 minutes before the hour.

#3 Have clear objectives

Meetings will be more productive when you start with an agenda that answers the questions: Why am I at this meeting? Who requires that I be here? When does this meeting end? How will we know if the meeting is successful?

#4 Stay focused on the Agenda

How can you finish on time and meet your objectives if the meeting meanders off in different directions or breaks up into sidebar conversations.  Ideally appoint a faciliator and look at techniques like "3 knocks" where any person knocks 3 times on the table to highlight a deviation.

#5 Be prepared.

Review the agenda or other background information ahead of time so this is not the first thing being done in the meeting. Know where the meeting will be held and how long it takes to get to and from that meeting place so you can be on time.

#6 Be engaged

This starts with turning off your phones and putting away laptops or tablets. One good practice is to leave a little bit of time at the beginning of the meeting allowing people to get something off their chest at the outset as a way of parking it.  Set up a charity box for those who arrive late or take calls during the meeting.  Stand up instead of sitting down.

#7 Use Whole Brain Communication 

People sometimes talk of "communicate visually" - we believe this can play into many myths around the % importance of non-vebal communication the power.  In addition, at evoco, we like to think in "whole brain" approaches where people engage far more with a message that is a combination of pictures and sounds and also engages them physically (e.g. something you can touch or hold or physically interact with.

#8 Practice genchi gembutsu

This is the Lean approach of "going to see it for yourself".  All too often meetings are held at locations remote from the relevant place and discuss abstract problems.  Far better to be in the right place and include some first hand experience.  I also believe there is a strong overlap with this and the Agile concept of modelling and prototyping.  Don't meet to discuss and review a document that represents, for example, a design.  Meet with a prototype that you can all look at and hold (whole brain approach).

#9 Avoid the Three Evils of Meetings

These are the ones taught by Takeshi Kawabe, former executive of Showa Manufacturing and student of Taiichi Ohno :

1. Meet but don’t discus
2. Discuss but don’t decide
3. Decide but don’t do

As you can see there is a lot of overlap between these rules and many positive feedback loops between the different behaviours the rules help to drive.  We hope these pointers will help improve the effectiveness of your meetings.

As the economic gloom spreads and job cuts spiral – who wants to be seen to be doing nothing?

Beware, the current climate might only serve to increase the incidence of an old problem. Research has suggested that 90% of managers spend their time in unproductive busyness or busy idleness. An oxymoronic scourge on corporate productivity. This appeared in the Harvard Business School press in 2004 and deserves a close look.

10 years (or more) of study helped Heike Bruch and Sumantra Goshal reach the conclusion that only 10% of managers use their time effectively. How does this break down?

Energy and Focus

Bruch and Goshal identified 4 managerial behaviour types based on energy and focus.

The Purposeful

The 10% who are highly focused, energetic and come across as calm and reflective when all around appears chaotic.

The Frenzied

the 40% who are highly energetic, enthusiastic and identify strongly with their jobs. However the need for speed can overwhelm and distract them.

The need to do more and more without time to reflect as the pressure builds can be highly destructive.

The Procrastinators

The 30% who procrastinate on the important work in favour of minor details and possibly fear failure.

Sometimes these people can be recovering Frenzied managers who choose to procrastinate to avoid the pitfalls of frenzy.

The Detached

The 20% who are focused but low in energy and coming across, perhaps, as aloof and tense.

This is an interesting piece of work because it turns the spotlight back onto the individual. We can all blame the tight deadlines, and external pressures, when perhaps we should consider underlying patterns of behaviour.

Without action it’s about self-sabotage and a focus on making the inevitable happen rather than making a real difference. With the right action it’s about harnessing your will power to ensure you remain effective, energetic and focussed in spite of the inevitable disruptions, distractions and blockers that occur in every day business life.

Look at yourself and where do you fit? Look at your team and where do they fit?

Remember one of the golden rules of management “you get what you inspect, not what you expect”.  Are corporate metrics and incentives encouraging people to occupy one or more unproductive boxes?  This could be an unintended side-effect of apparently good metrics, or the lazy application of metrics (measuring what is easy rather than what is important).

Find ways to help the Frenzied to pause momentarily and reflect. Take a break from their incessant toil and unhesitating action.

Procrastinators often fear failure, what is at the root of this? In other cases it appears the Procrastinators are actually reformed Frenzied managers resorting to inaction after becoming dis-satisfied with the lack of real result from their activity.

Resolving this is not easy, in fact could be called a Wicked Problem (more on this another day). Measuring real productivity is not easy. Measuring activity is much easier and activity is, therefore, often used as a proxy for productivity. Measuring and rewarding activity can easily create a feedback loop that encourages Unproductive Busyness.

There are few things that are more important than understanding and managing your stakeholders.  There is too much to cover in one post – I plan to return to this topic…………  Let me introduce the first tool I recommend to you – the Power-Interest Matrix:

Map all your stakeholders against this grid.  Basically you are looking at their interest in what you are doing (e.g. project, programme or business change initiative) and their power to influence what you are doing.  According to their position you can start to select the appropriate actions:

Minimal Effort - phew, the people with a low interest in your initiative combined with their low power places few demands on your comms and stakeholder management teams.

Keep Informed – a bit more required here, particularly on the communications front.  These people have a high interest in what you are doing, but relatively low power.  Don’t become complacent though, the combined effect of many disgruntled individuals can grow.  Additionally the opinion of one individual may feed up into more powerful bodies such as unions or the press.

Keep Satisfied – these people need to be kept happy!!  Those with a high level of power but low level of interest need to be kept satisfied.  Bear in mind the level of interest can change rapidly when a stakeholder becomes dis-satisfied.

Manage Closely – here come your “key players” who should be the key focus of your stakeholder management time and effort.  We will come back in to this in other posts, looking at ways to manage these people.  Above all don’t forget to give them a really good listening to from time to time.

Remember this map may not remain static over time. In a long and complex programme a stakeholder might have a low interest initially with increasing interest as the change came closer to them.  Also external changes, scope changes and role changes might all move people from one box to another.

This approach links back effectively to Kotter’s 8 step approach – in particular, step 1 of “creating a sense of urgency” requires effective working with all stakeholders and step 2 “building a powerful guiding coalition” means working effectively with your key players.  And don’t forget, the earlier you start these activities the better!

Many of you will have heard of MoSCoW prioritisation (though many may not). We have recently found it being used more widely, and also being abused more widely as a consequence. Hence the thought to write a short article to clarify the approach.

MoSCoW is an approach to prioritising project requirements that belongs to the DSDM consortium. For those with an interest in history, the term was created by Dai Clegg of Oracle, but he later donated the IPR (Intellectual Property Rights) to the the DSDM consortium. For those with no interest in history I should have warned you to skip the rest of that sentence.

We won’t go into the detail of the DSDM approach to Agile project delivery (though it is very good) as the technique stands alone quite well. MoSCoW is very good for getting to the heart of people’s priorities. Essentially it proposes you agree to put all requirements into one of 4 buckets:

• Must Have
• Should Have
• Could Have
• Won’t Have this time (but would like to have)

You might also see why some purists say it should be MuSCoW, but that’s splitting hairs in our view.

At first sight this might look a lot like a lot of other prioritisation approaches – the real difference lies in two areas:

Won’t Have this time

It is vital to bear in mind, this is not “Would like to have” nor is it “Won’t Have ever, ever, ever”, the emphasis is on “this time”. All too often when we go in to help with a troubled project, one key area to address is the scope, looking for requirements that aren’t really needed right now, but are holding everything up. There are all sorts of reasons requirements go into this bucket – in no particular order some of these are:

• Not that important on closer scrutiny
• Are very difficult or costly to implement
• Depend on external and/or uncertain factors
• Are high risk
• Are untested, haven’t been successfully delivered elsewhere
• Are subject to external changes (e.g. revised legislation)

MUST = Minimum Usable SubseT

There is also a key nuance in the use of MUST – defining the Minimum Usable SubseT of the full set of requirements. All too often the concept of Must Have is dominated by lobbying, hobby horses and the whole idea that at some point you will have to trade some requirements, so you might as well go in high.

In the DSDM approach these are really the show stoppers. If you fail to deliver one of these requirements then at least one of the following will apply:

• There would be no point in doing the project, you might as well pull the plug now
• The solution would not be compliant with relevant legal requirements
• The solution would not be safe
• The business case would not be delivered / the key benefits could not be realised

So basically if you ask the question “What happens if we fail to deliver this?” and the answer is “Cancel the project” then you have a Must Have. Otherwise you are looking at a Should Have or a Could Have.

For those involved in Agile approaches, it is important to note that a requirement can have an overall project MoSCoW priority as well as an iteration or increment MoSCoW priority. But that is too much detail for today – we can return to this.

Should Have

Should Have requirements are still important, but do not pass the vital test above. It would be painful to leave them out, but your solution would remain viable. There is probably a workaround, expensive and painful though this might be.

When you evaluate the level of pain, the number of people affected, the cost and impact of the workaround, the level of benefit attached to the requirement, then you can differentiate between Should Haves and Could Haves. There is no golden rule, just some good old common sense and frank, grown up discussions with your stakeholders and sponsor.

And finally, don’t get too bogged down in the idea this is just for Agile projects coding new software solutions. It is an approach you can readily adopt to any situation requiring you to prioritise a future workload.

For those with an interest in linking MoSCoW to project estimation read our post on Planning Poker.  You could also have a look at our Streetwise Moscow guide.

We have created and started to use a powerful new tool that we have not found in PRINCE2 or other related methodologies.  At the time we were looking for better ways to address the “best practice paradox”. It’s called the Morecambe and Previn log

You might just care to remind yourself on Youtube of this classic sketch.

The “best practice paradox” is a phenomenon we regularly observe where companies implement best practice approaches and things do not improve and, paradoxically, often become even worse.  A simple technique is to look for implementations that meet the test of “all the right notes being played, but not necessarily in the right order”.  In these cases it is not a matter of throwing everything out and starting all over – but looking for ways to rearrange the notes into the right order.

All too often this is a governance problem and people are focusing so much on the best practice boxes that need to be ticked that they forget to apply common sense.  In other cases systems are implemented with such vigour and rigour that people are unable to apply common sense or lose all motivation to try.  In yet other cases companies have tried to apply every single component of every single process in every single part of the operation and this has led to a complete overload on the staff and a serious outbreak of Morecambe and Previn events.

When there are many entries in the log it is usually a sign to have a close look at the governance and performance management systems that are in place, as the old saying goes: “you get what you inspect, not what you expect”.

Make it Happen

Make it Stick

Project cost estimation is one task that should not be under-estimated (sic). In reality the JFDI (“Just Focus and Do It” as the version we will print) approach followed by the SWAG (“Silly Wild-Ass Guess” rather than a Super WAG) estimate tends to result in a rather moveable baseline and a rather disappointed customer and project board.

There are several approaches to improving this and we will visit various of them over time (e.g. Planning Poker). However one tried and tested approach is that of 3 point estimating (sometimes referrred to as PERT estimating or 3 point planning).

In the land of MS Project each task generally has a single estimate of duration and / or cost (as a result of typical usage btw, not software shortcomings). When using a 3 point approach you apply a “best case” (OPT), “worst case” (PESS) and “most likely”(LIKE) value to each item.

Then apply the following formula:

o EXPECTED = (OPT + (4*LIKE) + PESS) / 6

For example:

In this case we would use 15 days as the estimate for our schedule, but we now have a view of the possible up and down sides. This might look very similar to the estimate of 14 days (assuming you received this answer if you just asked for a single estimate). However you can now start looking at the impact on your schedule if the task did take 25 days rather than 15.

There are some who advocate adjusting what you ask according to the person – e.g. for the optimist / salesperson type start by asking for the best case, and for those glass half empty types start with the worst case. I.e. start them off in their comfort zone, move them to the other end and then finish off by asking for the most likely.

There are then some other fancy things you can do, for example consider using Monte Carlo simulations that can help you achieve a greater level of confidence across a large schedule. Also another trick people use is to revisit the estimates over time. Ideally the uncertainty (as represented by OPT – PESS or 15 days in this case) will decrease over time – i.e. the closer you get to something the clearer the picture. This is not always the case, but should set some alarm bells ringing for the project manager if this number is either staying the same or even going up.