When someone is partially right

I run a lot or workshops, so I get into a lot of arguments.

Of course, we like to call it robust discussion when we do so.  And of course I am generally facilitating rather than debating.

So I need to know how to keep conversations “robust enough to be valuable” and “respectful enough to build relationships rather than strain them”.  I therefore employ a range of conflict management techniques when facilitating other people’s discussions.

But sometimes my problem is that I am running a presentation or training course and someone objects to one of my points in a way that is (either by intent or accident) inflammatory and distracting.

For example I once said “blah blah, so if you want a team to be effective then you will need to empower people to make their own decisions”.

The response I got was “no you don’t.  The most effective teams I have been in have been driven by the top.  Everyone knows what they are meant to do and is moving in the same direction”.

Sadly this was a course on empowering teams through servant leadership as part of a change management initiative.  And the same guy, along with a couple of others were not keen on the whole change initiative.

I tried one technique that I often use when I have no idea what to say.  I asked “Can you expand on that?”.   Sadly he and his buddy did, explaining that strong leadership was necessary in tough times, which is where the company is and that therefore empowering people would typically lead to chaos.  So empowerment is what we always pretend we want, when we will really only ever reward managers who are tough and demanding and deliver at the expense of their people.

I could use open questions to further explore areas such as this, but we were already getting off track and at risk of running out of time.

Or I could have disputed what was said, since I had ample evidence to demonstrate that empowered teams are better.  But I feared that a couple of the participants would have dragged the debate on without even listening to my evidence – and some of the other participants were already over watching the show.

I thought of asking the rest of the group for their views, but I was already aware that this guy was both very senior and intimidating to some of the people there.

So I did what I probably should have done earlier.  I agreed specifically with the part that was true and utterly ignored the part that was not.

So I used a specific response someone taught me:

  • To give him recognition I said “you are right”.  I would not have said this if he was completely wrong but in this case some of what was being said was true;
  • But I don’t want to say that all the allegations are right and nor do I want to get into a long conversation of ones that are wrong.  So I specifically state what was right – “… strong leadership is important in a crisis.  People need to know what the goal is and they need confidence that the team is heading in the right direction”
  • Then I brought the conversation back into where I wanted to be going with the course.  “and that brings us to the next point …”.

This is an approach that works well in many different situations.  The key is to do each stage deliberately, concisely and in order:

  1. Validate the person – say “you are right”
  2. Specifically state the point that was correct, in one sentence (and completely ignore the exaggerations, giant leaps of logic, or controversial loaded questions).
  3. Move on with the next sentence, either with a smooth link to the next topic, or even a clumsy “so now I would like to move onto …”.  (don’t say “does that make sense to you” or do anything else to reopen the conversation).

Practice the approach in safe environments and then use in in tough facilitations.  You will be surprised how well it works.

Advertisements

Estimating the cost impact of risks

We all know that managing risk is important.  In fact, Graham Downes recently suggested (in a comment on this blog) that the best way to stop eager young project managers from being “blown up” is  to teach them to better manage risk.

But even when they manage risk actively, I see a lot of teams rating the cost of a risk blowing up on them as “TBA” (ie – to  be advised … ie we don’t know).

Some projects even end with a whole pile of risks listed as high impact with a dollar impact of TBA.

If this is the case, then possibly it is better to not worry about having a column in the risk register to cover dollar impact. Instead, focus on making the impact relevant and real to the team.

I do like to rate the dollar impact of my risks and like other people I often don’t have the time to assess the dollar impact of every risk properly. But I do like to rank my risks by dollar impact to have a look at the scariest ones.

So what I do is allocate a cost to the risk on a scale of really bad to really trivial.  I do this as follows:

  • Decide on what would represent a huge cost in the context of the project, one that makes it worth canning the whole project.  I often do this by simply doubling the budget of the project.
  • Assign this dollar value as “category A”.  So for example if $10m is a really scary figure for the project, then “A” means “any risk whose impact could have an impact of over $10m”.
  • Then assign category B, category C and so on to smaller numbers so that you have a scale with wide ranges for each letter.  It might look like this – A = greater than $10m; B = $2m – $10m; C= $500K – $2m; D=$100k – $500K; E= $20K – $100K; F= $5K – $20K and so on.
  • Eventually you will get to amounts that are small enough to agree not to worry about them as risks.

The trick is to have broad ranges so that it is easy to guess where a risk should fit. The mathmatically pure among you may notice that a risk could fall into category A and B if it is exactly $2m. I claim this doesn’t matter and that you should in this case assign it to the higher category.

Adding a scale for risks allows the team to assign a (very) rough dollar value without too much analysis, yet allows you to categorise risks as really scary or not so bad.

This, I think, makes it easier to deal with the bulk of the risks.  Of course you can still assess the dollar impact of certain risks in more detail if appropriate.

Talking at the SDC next year

I have been quoting my grandma in Agile workshops recently.

She probably thought that “lean” was fat free meat and that “kanban” was probably a type of cake.  But she did understand one of key concepts in successful projects:

“Never mistake activity for progress”.

In other words, writing and deploying a lot of code quickly is not the same as solving business problems or improving the assets and capabilities of the organisation.  So I am basing my talk on her insight when I speak at the  Software Development Conference.

I believe that on many projects there is often a gap around:

  • Handing over knowledge at the end of the project
  • Maintaining knowledge during the project
  • Linking the overall solution into the existing business culture, strategy and processes

Having found these gaps, I also think it is relatively easy for members of the team (particularly testers and business analsysts) to step up and fill them.

I will probably test some of my theories in blog articles in the meantime.  So please let me know what you think of them – not just for me but for the poor audience who will be expecting more from the talk than just my Grandma’s favourite Date loaf recipe.

Why do the good project managers doubt themselves?

I was coaching a project manager last week and we worked through several of the issues he is facing.

He was probably hoping that there were some cool new Lean or Agile tools that he could use to deal with some seemingly really difficult problems.  In fact I always hope the same thing – it makes coaching and work easier.

Sadly, and predictably, he didn’t need cool new techniques.  He was already applying common sense, accountability and a real focus on getting the best outcome for the project (best for the team, the organisation and the customer).  He was also treating people like people, risks like risks and even status reports as a way of communicating status.

Yet he was still struggling.

As we worked through his issues a couple of things came out of the conversation.  He noted that he rarely gets time to sit and reflect on the project because it is too important and too urgent.  He also noted that if it is so importantly maybe he does need time to think.

But for me what came out was the crystalisation of a pattern I was vaguely aware of.

Most good project managers struggle.

  • They start out runing small projects successfully;
  • So they get bigger and harder projects; and then
  • Eventually they either get blown up or find a sustainable rhythm between nightmare project (that they often seem to want every third project) and cruisy project (that they need every third or more projects but rapidly get bored with)

Now if they blow up, they often give up or get shunted out because they failed or struggled with something really hard.  But ironically this is exactly when they can learn to be a great project manager for future projects.  I often say I won’t hire project managers who have no scars because they need to learn from the struggles of being out of their depth or making mistakes, but I would rather someone else pay for that part of their education.

Also ironically, the good project managers seem, like the one I was coaching, to feel apologetic about struggling with really difficult projects.  They seem to feel that if they were better and more experienced the project would not have been such a struggle.

This is proabably true, but then we usually don’t know until half way through what a project will be like. So is is hard to avoid being a project manager and being in trouble.

On the other hand there are also many “sub-optimal” project managers who never feel apologetic.  Sometimes they choose easy projects, usually they ask for far more time, money and resources than a better project manager would need and still struggle to deliver, and every project they blame all problems on the complexity of the project  and claim they did an amazing job simply because the project was always in trouble and they were there to rescue it.

So it seems to be the project managers who doubt themselves that become better project managers, while the ones who blame the complexity of the project and the “dumb” stakeholders who fail to learn and yet costing their projects a lot of money for having the same problems they should have learned to avoid last project.

Lifting organisational and individual capability

Rather than just rolling out various changes and reflecting on how they went, we want to continuously grow our teams and our own capability as well.

I am happy to work with you to develop a capability in any of the areas I work in.  This can be as simple as sharing the techniques I use or as sophisticated as planning and implementing an initiative across your whole team to build specific capabilities over the longer term.

I am particularly passionate about integrating the different aspects of capability growth.  These  include setting up internal mentoring, reading, training, coaching and process improvement.  I believe these should be implemented as a cohesive ecosystem that creates the capability of the team, rather than as separate and unrelated undertakings.

In some cases it might also be worth looking at the rollout of elearning, performing a formal skills gap analysis or even getting the team certified.  While I do not have the capacity to cover the full gambit of this work on my own, I do work with partners who do.

To find out more about these services, you can browse the articles in the Capability growth category.

You can also call me on +61 4 21 058 459, or email me at james@kingsinsight.com

On reflection

Action without reflection soon turns into panic, yet I don’t know anybody who has serious time to reflect each day at work.

For example, I know of several teams who run small iterations on IT projects and still haven’t had time to sit down and think through how they plan their releases.  So in addition to having the team properly trained, I now run a training game called The Agile Release Planning Game.

The game helps people to experience the process of planning releases and iterations without getting caught up in the detail of their own projects.  So let me know  if you would like me to run the game, or would like to purchase a copy to run for your own teams and customers.

Back in the real world, I facilitate post implementation reviews for projects and post incident reviews for teams who have recently responded to a major incident.

More generally, I provide coaching to individuals in how to better deliver their projects, lift their performance or make the transition to a new (or growing) role.

I also provide workshops and coaching for teams in the areas of process and business consulting, business analsyis and effective project delivery.

You can also call me on +61 4 21 058 459, or email me at james@kingsinsight.com

Help with implementation of change and projects

Even when you have an understanding of what the organisation needs, it can be difficult to implement the right solution effectively while so many other things are going on.

I specialise in supporting your team in effective implementation of a range of initiatives.  Where projects are large and complex, I also recommend trusted partners who I know have a track record of delivering the projects that I have seen others struggle with.

The specific support I can provide to you is:

  • Change management action and communication plans.
  • Change management delivery.
  • The rollout of integrated (or “blended”) learning solutions.
  • Assistance with improving team effectiveness.
  • Introducing Agile approaches to development teams.
  • Introducing continuous improvement approaches to service delivery teams.
  • Implementing process improvements in service delivery and project consulting teams.

To find out more about these services, you can browse the articles in the Implementation services category (coming soon).
You can also call me on +61 4 21 058 459, or email me at james@kingsinsight.com