Deadlines – the great motivators

I went to “Joint School” on Friday, our local pre-surgery induction for hip replacement patients.  I came away really fired up with all the things I need to get done before I go in for surgery in 2 weeks.

So what is it that this deadline has triggered?

  1. Priority – I now have a list of things that must be done, a list of things that should be done, and a list of things I’d like to do.
  2. Focus – I’ve immediately cancelled all the “nice to haves” that require significant time and distract me from hitting the deadline
  3. Timeliness – I’ve already done lots of things that I’ve known needed doing for months but kept postponing due to “high priorities”
  4. Energy – I will be the one to suffer if I don’t hit the deadline, and  I’ve discovered that lots of “huge” tasks have been finished pretty quickly and easily because they have to be done now, rather than shuffled off into the future
  5. Personal effectiveness – because a change is BETTER than a rest. Swapping to another task when I run out of steam re-energises me while doing something useful

Setting deadlines is a key skill in project management, and if done well can stimulate the team very powerfully.

Are deadlines always so effective?

Well, no. Deadlines can be hugely demotivating when:

  • They are not real – they have been created by an executive or manager to “motivate” the team
  • They are too tight:
    • perhaps they are labelled “stretch” but failure to achieve them is unacceptable
    • perhaps they’re simply impossible
  • They are too far in the future:
    • breeding complacency and indolence
    • relying on staff to create their own interim deadlines and motivate themselves
  • They are too abstract – the team can’t relate emotionally to hitting or missing the deadline, so their energies are not tapped into.

Ensuring these do not happen is the responsibility of business leadership, portfolio and programme management, and a critical requirement for such leaders is to have their fingers on the pulse of reality, and occasionally lift their noses from Excel spreadsheets and abstract numbers.

Over the last few years I have seen 2 glaring examples of deadlines being set without a sound justification for considering them viable, then the leaders going ballistic on being told, when the feasibility studies were completed, that the targets were not achievable.

The other end of the spectrum is as bad – many years earlier, I saw a project team that had been set up 6 years before the regulatory deadline, and had spent 5 years making very limited progress. This demanded a huge effort to rescue the project at the last moment

Business leaders need to think very hard about using deadlines to motivate teams – they can work very powerfully both towards success and right into failure!

Advertisements

Simple or complex? The dilemma

Lysanne Currie’s editorial in the April 2016 issue of “The Director”, entitled “Keeping it Simple”, cites a TED talk by Harvard’s Professor George Whitesides, highlighting that the vast majority of people crave simplicity, and it’s mainly academics who relish complexity and emergence.

The article goes on to promote strategic simplification as a strategy to achieve great results, pointing to Sacha Romanovitch of Grant Thornton as a leading example of its success. My personal experience of this was at Centrica, where they executed a complete U-turn from acquiring multiple brands and business to divesting the AA, Goldfish and One.Tel UK to focus on British Gas.

This doesn’t mean being simplistic in your thinking, though. Churchill famously apologised for writing a long letter as he had no time to write a shorter one, and Lysanne quotes Steve Jobs; “Simple can be harder than complex. You have  to work hard to get your thinking clean to make it simple”.

Problems are often complex, and the reality only emerges with time and progressive analysis. The whole of Chaos Theory is about understanding how simplicity generates apparent complexity. When people are involved,  we need to add emotion, contrariness and sheer malice into the equation too.

Solutions are where the benefits of simplification really come in – solutions must be “sold” to, and applied by, many and so must be easy to communicate. Given most people’s need for simplicity, it becomes essential to present the solution as simple, even if it is complex.

There is a process here:

  • probe complexity and emergence during the investigation of the problem, to ensure you get your understanding right
  • invest time end effort to simplify the solution, making it robust
  • If the simple solution doesn’t match “the way we do things”, seriously consider changing the way things are done too

Trying to keep it simple throughout by simplifying the investigation and analysis of a problem creates a grave risk of getting it wrong. There is a sad trail of government initiatives that have had diametrically the opposite effect to that desired, not least government borrowing going UP under the last government.

Embrace complexity, but make it sound simple :o)

 

 

Agile – the way forward for projects?

One of the biggest flaws with the traditional “waterfall” model of software development is that the customer requirements are only validated at the end.

Of course this reveals two types of flaw in the documented requirements:

  1. They were simply wrong/inadequate in the first place
  2. They have been overtaken by events

This is particularly obvious in long defence projects like the F35 replacement for the Harrier, or public vanity projects like the Millennium Dome and Scottish Parliament Building.

Much of the cost-overrun of big projects results from the delays and rework costs of enhancing the finished product to meet the newly-clarified/revealed requirements.

So – if you get the requirements right and build to meet them right first time, the project will stand out as being cheaper than normal. The Rion-Antirrion Bridge in Greece is a fabulous example of getting it right first time, and Cross-rail is looking good too.

The huge strength of the Agile approach is that it validates requirements as it goes along, by integrating end users into the development team, and for software development projects this is great (with a couple of caveats). This means that Agile projects have a tendency to be more successful and better value for money.

So is it a no-brainer? Should we do all projects as Agile?

Agile isn’t necessarily cheaper – the Rion-Antirrion Bridge wasn’t Agile, and there are Agile projects that have gone badly wrong.

In my experience, the Achilles heel of Agile is that if the fundamental requirements are not adequately understood at the start, the wrong “architecture” of the solution can be selected and only when a lot of time and effort has been invested does it become clear that you’re on the wrong horse. Swapping horses in mid-stream is difficult and risky, and usually hugely expensive, so the pressure is on to struggle on and make do with what you’ve got.

I prefer a multi-stage approach with rigorous feasibility assessments in managing major strategic projects, where the architecture is really sorted out first. The Rion bridge needed to be tackled as a single entity, because that is the way it functions. Picking the wrong ERP system crippled the business and IT strategy of a FTSE 100 company, leading to a complete U-turn in its IT plans.

Agile approaches have some real benefits, but need using with care, and must not be used as an alternative to thinking the problem through first.

Coaching Project Managers is great value

Business coaches are legion, executive coaches are everywhere, so why is almost no one coaching project managers, the people delivering the vision?

I’ve compiled some case studies of the work I’ve done with project managers in a wide range of industries and the huge benefits resulting.

I’ve done a comparative analysis of  traditional face-to-face training courses, e-learning and coaching:

Picture1

Ah, I hear you think, coaching is much more expensive! Some of the executive coaches (and some of the business coaches) may be; I was shocked to hear the fees charges by one franchise.

It’s not the case for our offering, certainly – some project management courses are very expensive for the limited value they deliver.

It seems a no-brainer to me!

If I’ve got it wrong, please tell me.

 

Workload management – the 3 Ds

It’s a common saying that if you want something doing, give it to a busy person, but accepting work can quickly take you beyond your capacity for sustained performance, disappointing everyone and making you ill.

As we surge back into the whirlwind of work after the relative peace of the Christmas break, I thought it would be a good idea to recap on my disciplines for holding workload in control, the 3 Ds:

  1. Decline: the simplest, though not the easiest, is to say “No” to extra work. If you are not accountable for this work, and don’t have the best specialist skills, you should reject responsibility for it and recommend who it should go to
  2. Delegate: if the work naturally sits with your responsibilities, ask whether it needs your personal input, or whether it can be delegated (limiting your input to tasking and monitoring).  Teaching one of your team to do it may be the right strategic choice, but that is more time-consuming, so do that when you have the chance
  3. Defer: be effective in prioritising work – when does it really need to be done by? When can you realistically do it?  I worked in one organization where all IT work was prioritised “1” i.e. all top priority, so they introduced the “1*” priority – higher than “1”. Within a month, all requests were priority “1*”.  Work must be spread out over time when there are finite resources – push back those tasks that can be

Of course, this doesn’t mean what is left is always achievable, but if you don’t try, things go pear-shaped much quicker!

Clinging to the Greasy Pole

I just read an interesting post on great leaders knowing they are imperfect. It is mainly about people who are NOT great leaders, discussing the over-compensation that can result when people feel out of their depth.

I think the truth is that all of us know we have our weaknesses – the issue is whether we have the courage to forgive ourselves for having weaknesses, and having faith in our colleagues to recognize that our strengths far outweigh our weaknesses.

It is a characteristic of many heroes that they are flawed (and this is most clearly portrayed in comic book superheroes, which Hollywood is currently obsessed with). It is their flaws, paradoxically, that makes us love them as it allows us to empathise with them.

It is sad and worrying to see (highly-stressed) managers, having shinned up the greasy pole of promotion, trying not to delegate any responsibilities because any lack of control by them would be a sign of weakness. Once they reach their limits, this has a number of serious consequences:

  • Things get done slowly and badly, as that manager is a key pinch point on everything
  • Some things don’t get done at all
  • A defensive position means positive changes/opportunities are rejected
  • Staff have no opportunity to develop and grow, so the good ones leave
  • The staff that stays switches off their initiative and just turn the handle when they are told to
  • Everything falls apart when that manager gets sick or goes on holiday
  • Their defensiveness is fed by the cordial dislike of their staff

Of course, this manager goes around claiming to be a great hero – single-handedly coping with the inadequacies of their useless team and taking all the credit for any success. They may get promoted for it, but it cannot last forever, and it’s no fun for anyone.

The really great leaders are loved for their human failings, as well as their super-human strengths.

(I’d like to thank Video Arts’ video on coaching (Robert Lindsay, John Cleese and Jan Ravens) which I saw many years ago and which left an indelible impression on me!)

Good News – a learning organisation!

I posted back in April about how few organisations seem to learn from their mistakes, with the same errors happening time and time again as people rush into starting the next project.

I was delighted to meet the head of a business unit in a global organization who was not only fed up as well, but has done something about it.

He has introduced a step at the start of setting up a new project that requires the project team to research similar projects and read their “lessons learned” reports!  This is fairly recent, so he’s promised to keep me posted on how successful it is.

I may well have commented before that “Lessons Learned Report” is a misnomer, as very few of these lessons have been learned – they are more correctly labelled “Lessons identified and forgotten” reports.

I have had this discussion with many people over the years, and what I now advocate for the “learning organisation” is that they work out who needs to learn what, from whom, and incentivise people to do the relevant teaching and learning. This needs recognition that learning lessons takes time and effort, but saves far more time and money squandered on expensive mistakes.