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.

 

 

Advertisements

Coaching project managers – light at the end of the tunnel?

There are 2 wonderful things that have happened to me this week.

The first is that my car key turned up 3 days after I lost it – and it still works after sitting in the wet grass next to our drive for all that time!

Much more importantly, I explained about project management coaching on Monday to a senior manager in a large organisation, and  they agree it’s a good thing and they should have it!

After my previous post on why it’s such good value, it was great to be heard.

Attending  a session at the BCN on Situational Leadership (Ken Blanchard’s work) recently, provoked a discussion last night with a friend and colleague who’s a highly-qualified coach. This revealed a potential issue with the term “coaching” itself, in terms of attracting customers for coaching PMs.

In Blanchard’s model, Coaching is the name given to the quadrant where both direction and supporting behaviours are high i.e. the “coach” is both encouraging the “coachee” to do what they can better, but also provides advice and direction to ensure the job gets done. With 30 years experience, this is where I operate; part consultant, part teacher.

However, many schools of coaching thought do NOT operate in this quadrant, their coaching is non-directive, and falls in Blanchard’s “Supporting” quadrant, with high levels of supporting, and no direction. Confusing, isn’t it? This might be OK for CEOs, but is of limited value to accelerating project success through better-performing project managers. If I thought coaching would be non-directive, I wouldn’t buy it for PMs.

Labels have huge power, terminology is always a risk – the benefit of many methodologies is simple to provide everyone with a common language – and the area of coaching and mentoring is particularly fraught.  I even coined a new term for my offering, but no one understood that either.

It’s important to power through the misconceptions to deliver a true picture;

Report card: C- must try harder!

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!

Hope for the best, plan for the worst – the art of contingency planning

Recent events in UK government suggest that no one seriously expected there to be a majority vote for the UK’s exit from the EU. There doesn’t appear to be any Government plans for the withdrawal of the UK from the EU ready to swing into action. It seems likely that no one in the Brexit camp had really thought through the consequences and requirements  of exit, and the Government was firmly “Remain”.

Contingency planning is an uncomfortable thing to do, as it’s about thinking through things you don’t want to happen – “thinking the unthinkable”. That doesn’t mean it doesn’t have to be done, though, because when things do go wrong, it’s often too late to work out what to do. In developing business continuity plans for one organisation, they realised that one system was so efficient, and so difficult to reintegrate any manual working, that if it went down they would wait more than a month before invoking any contingency actions. Another organisation’s disaster recovery plans, when audited, revealed that  no one would be able to do anything for 4 days, then could start to operate again in the DR site – this was swiftly changed!

Thinking through things that might go wrong, in a realistic way, requires imagination and planning, and is incompatible with working hard on the day job. It takes skilled facilitation and time out, but most importantly a refusal by the leadership to accept a shrugging of shoulders. A system I delivered to the NHS underwent 3 disaster recovery tests before the client was confident, and we’d already ensured that it met the SLA with a 200% safety margin. The system (NHS Direct website and symptom checkers)  hit the SLA level within 5 weeks, much to everyone’s astonishment, leaving us with the warm feeling that we’d addressed that contingency.

Perfect Planning Prevents P**s Poor Performance!

We can continue to watch the current comedy in wonder.

 

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.