Coping with uncertainty during a major project – climbing the mountain versus Brexit

IMAG0844I had a hip replacement last November, 27 years after I broke it in an accident. The surgeon who set it then explained that though they’d done a good job, it wasn’t a perfect job and eventually the hip would wear out.

Last week I was walking with friends in the Pyrenees, just 3 months after being discharged from the hip replacement. This was a tremendous occasion for me – would I still be a partial cripple, or would I find myself as good as new?

We set off to climb the pic de Saint-Barthélemy, at 2348m the second highest in the Corbieres region, ascending steadily through mist and low cloud from 1300m. We debated options – ascend by the “scenic” but rather harder route, or just go straight for the summit. Given the dull grey cloud we were in spoiling any view, and my natural concern about not overdoing things, we decided to split up; 2 of us went direct for the summit, the other 2 went the harder route (taking the guide book).

So two of us set out for the summit with 50m visibility and no guidebook or map. We just put our heads down and slogged upwards, eventually bursting through the top of the clouds into brilliant sunshine. As we continued up, we then saw the summit, and realised how far we still had to climb, but trudged on steadilyi

The view from the empty summit, when we finally got there , was breath-taking – the tallest summit was before us (just 20m higher) and other mountain tops peeking from the sea of cloud. 15 minutes later our friends arrived, seriously tired after an even harder grind, especially the final ascent.

What has this to do with project management?

Many projects hit a period in their life where leadership changes or vanishes, visibility of the overall objective is obscured or challenged and the team starts to fragment, pulling in different directions.  Brexit is a fine example of this happening from the very start!

When this period is entered, it is easy to panic and start a blame storm that quickly leads to the project stalling and potentially failing – David Cameron resigning and Theresa May stepping up to take the poison chalice was an example of this, the huge swing against the Conservative party at the subsequent election another.

What is needed is, as on my climb, to keep slogging on while things become clearer before making critical decisions, because hard work and progress almost always provide more clarity on the way forward. The objectives may flex, but a project that is making good progress in difficult circumstances is far more likely to succeed than one that stalls and flaps about.

Again, Brexit shows what happen when steady hard work is replaced by dogma, rhetoric and outright lies – the government “demanded” a deal that is worse than was already on the table from the EU when negotiating on citizens’ rights.

Where the Brexit project will end up, no one knows, but we must all keep slogging along to make the best of this farcical project.

 

 

Advertisements

Teamworking: wishing you peace and happiness at Christmas and in the new year.

Just over 4 weeks ago I went into an NHS hospital for a hip replacement. I was stunned by the efficient and effective way I was treated, and how quickly I was discharged to go home – 30 hours.  What really struck me was that the staff were working together as a team, despite the usual NHS pressures, and I was treated as a human being, not  a number.

Has that  stayed the standard? Well, not quite – when I went to see Outpatients Physio, the handover and integration were less slick and integrated.  After, I felt less comfortable both physically and mentally than I had done. My GP surgery has done a lot to balance that out though, whipping out a couple of undissolved sutures at less than 24 hours notice.

Teamworking is something that makes everyone involved feel better, which directly and indirectly boosts performance.  I spend a lot of my time building up team behaviour in the early days of the projects I lead as I know the investment will repay huge dividends.

So why is it that the wreckers and tearers-apart are in the political ascendancy? People are feeling under pressure, for whatever reason, and this forces behaviours towards the extremes of the build up/split apart spectrum.

War is a major pressure, obviously. I’ve just finished reading a reference work on the British invasion of Madagascar during the Second World War, and it revealed to me the huge political impact of individuals’ relationships; Churchill and de Gaulle couldn’t get on together, which led to decades of Anglo-French acrimony after the was was over, and the UK’s delayed entry to the Common Market. Churchill didn’t trust the Vichy regime to stand up to Germany and Japan and stay truly neutral, leading to tragic events like the shelling of the French fleet at Mers el Kebir and the consequent vicious fighting by the Vichy French forces against the UK and its allies.

However, we are not at war, and the UK hasn’t had to fight a war locally within the lifetime of many people.  It’s something that others fight and suffer through – we just have to pay taxes to support our forces. The paradox is that the apparently despised EU, with NATO, has reduced the level of military conflict in Europe almost to zero as more states appreciate that membership means stopping fighting their neighbours and minorities.

Are we just bored with peace and prosperity? In 1957, just 12 years after the end of WW2, the PM, Harold Macmillan, had to rally the country and remind them that most people had never had it so good, following 6 years of war that bankrupted the country and 12 years of austerity.

People are often quite bad at comparing where they are now with where they were in the past, and are disillusioned they don’t have everything they could possibly want, when in reality nearly everyone has FAR MORE now than when I was growing up.

According to Oprah Winfrey, “Be thankful for what you have; you’ll end up having more. If you concentrate on what you don’t have, you will never, ever have enough”

At this time of year, with the awful prospects facing the word from the “votes of hate”, and the very real  fighting destroying the lives of so many, please relax for a moment, think of everything you have achieved in your life, and decide whether you can step back from our society’s obsession with accumulating yet more money and possessions and focus on working with people in peace and harmony as teams.

Oh – and stop buying newspapers. They lie to make money, and make you miserable and dissatisfied without any basis. You won’t find anything in the papers praising the NHS!

 

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!

The Elephant in the room – delay in project start

Isn’t it frightening that we take delays to project start so much for granted that we don’t recognize one of the most common causes of “failure” in projects?

Over the last 2 weeks I’ve been talking to many project professional, at the University of Manchester, in a major construction company and at the recent APM conference on Risk Management at Alderley Park (which was excellent, by the way).

We were all discussing the things that go wrong with projects, but the startling point that everyone was making is that late project start against an agreed plan is the most common problem, and that it usually threatens project success before it even starts.

It’s bad enough when the start date slips and the end date matches it, as the context of the project has changed (summer becomes winter, resource is redeployed while waiting etc) but what is even worse is that the target date often slips less than the start date, if at all.

As project professionals, we give realistic estimates for the cost and duration of our projects, only to find that we have to do most of them more quickly with less resource, in more demanding circumstances.

Late starts to projects are not a project management failure, they are a commercial issue, and project managers rarely have any influence over this, but we have to do the best we can and are accused of failure if we fail to do the impossible.

This is due to poor accountability within organisations – if Procurement were held to account for delaying the start of the project  and its consequent failure,  instead of being measured on penny-pinching and trying to squeeze out the last penny on price, things might get better. The cost or project delay needs to be understood and measured, and commercial teams held accountable.

None of that helps the project manager, of course. I’m currently working up my thoughts on this as part of a new programme for the University of Manchester and some industrial clients.

 

 

Business Readiness for “IT” projects – the final frontier?

For many years, the most satisfying experiences I’ve had professionally have come not from the investigation of some wonderful information technology (and I’ve done some amazing technology!), but from the successful application by business users of that technology to make a real difference to their effectiveness and efficiency.

IT projects have far and away the worst track record for project failure, and there are some good reasons that success is challenging:

  • The rate of change of technology is phenomenal
  • The complexity of IT solutions is often orders of magnitude higher than other projects

However, there are some less-good reasons that seem to come up time and again:

  • The demographic profile of both IT and business leaders is drifting towards the younger end of the spectrum, reducing experience of managing the art of the possible
  • Abdication of responsibility for project success to the IT project manager
  • Limited engagement between end-users and IT staff
  • Failure to ensure that the IT team understand what the business is all about, so design something truly good and fir for purpose
  • Delivering a “solution” to business users that haven’t been trained how to use it, don’t know what it can and can’t do, and worst of all, don’t understand it imposes changes to the BAU way of working

To a certain extent, Agile approaches address the first 4 points, but it’s the last point that makes me weep, because it happens so often and is completely unnecessary – it really isn’t rocket science, just planning.

Where does the problem arise?  Business readiness falls in the gap between the senior business management and the IT team.

  • The business managers are focused on their targets and BAU of their team, expecting the IT PM to sort out business readiness
  • The IT team don’t understand the needs of the business is getting ready for change, thinking their management is dealing with it
  • There’s no point just automating the existing process – computers can make the whole thing slicker, and this requires change in BAU processes

Business readiness requires special skills:

  • the ability to speak “business” to the business managers
  • the ability to speak “IT” to the techies, and explain what the business is all about
  • the ability to create a plan that fuses user needs with IT needs for implementation

With one client, I was able to completely transform the performance of 2 critical  IT staff simply by helping them understand the business paradigm their “customers” were working under. These were “lightbulb” moments for them – no gradual transition but sudden understanding.

So long as business and IT functions are treated separately, business readiness may well be the final frontier!

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.