Gauging project delivery in the thick of business-as-usual

One of the hardest things for a new Chief Delivery Officer is to design and execute a delivery strategy as the organisation, necessarily, continues with all the stuff daily business, with all the bad habits and problematic practices that are the reasons for having the CDO in the first place, often with a lack of planning or adequate governance.

I've been dropped into the middle of plenty of projects without a meaningful handover, without the documentation or digest needed to keep track of progress, the decisions made along the way.

At times, it felt like trying to perform diagnostics and essential maintenance on a rally car that's in the middle of a race, speeding along a forest track taking a bunch of near-misses with trees and hidden dips.

Peak under the bonnet and you may find the engine of a family car, or discover the tyres are bald or too small for the task … or some other way of pushing the analogy too hard.

In reality, you may be fixing a puncture, putting gaffer tape on the bonnet to stop it flipping up and obscuring the driver's view, and pouring petrol into the tank, all while driving the course with a map that only shows roads, not forest tracks.

Right, the analogy really is worn too thin now.

Suffice to say, when taking up a new position you're likely to find an organisation that's become accustomed to its ways of working and has been carrying on quite happily for a surprisingly long time. And they may well be unaware that they have problems that need tackling … or maybe don't understand the problems that they have, which will explain a low level of delivery maturity.

When this is the case, get ready for the sensation of holding your hands on your head, for a permanently accelerated heart rate as you're rushing from one chaotic situation to another, or for comments like, 'yeah, we tried that before and it didn't work for us,' or 'marketing/finance/whatever won't like you doing that,' or even the classic, 'that's not the way we do things here.'

So, what are we really going to be stepping into with business-as-usual in project delivery?

In most contexts when taking up a new post, you're likely to see issues related to these areas:

• Legacy practices
  • processes and procedures that worked for a smaller business still being used in a larger one
  • working in silos, little sharing across teams or units
  • feels like things are frozen in time
  • limited evidence of adapting and improving
• Legacy systems
  • bespoke things being created or invented each time, leading to chaotic projects
  • lots of work-arounds, rules-of-thumb
  • dependencies on toolkits of specific people as founts-of-all-knowledge, spreadsheets, etc.
  • limited learning and re-using tools or approaches
  • technical debt
  • dependency on technology, poor use of data
• Legacy governance
  • delivery teams and tasks subservient to customer demands
  • unable to push back, say no, position the business as experts, etc.
  • lack of status, standards, observability, analytics
  • 'one team' delivery practices missing — with clients, within the team, etc.
  • dependent on waterfall practices, struggling to implement agile, or attempting a hybrid
• Thinking fast, acting slow
  • too hasty to get going on doing stuff, matched with …
  • … lack of (or obviously thin) planning or structure
  • not asking 'why' and/or not taking note of the answers
  • missing details on outcomes, risks, must-haves, nice-to-haves, and other requirements
  • bogged down in delivery long grass, having to re-engineer earlier stages
• Legacy transformation processes
  • organisational culture that's overbearing or rigid, or conversely
  • organisational culture that's incoherent or absent, subject to change with review
  • organisation structured in silos
  • little room left for change or adaptation
  • lack of trust or respect for accumulated wisdom in wider team
• Multiple suppliers
  • many software tools, systems, platforms, often for bespoke uses
  • lack of coherence or rationalisation
• Team dynamics
  • Where are the master builders?
  • Do the master builders have the right team to work with?
  • Are teams in unhealthy competition with each other?

The business will be functioning, delivering stuff, busy people doing things to get stuff done. But just throwing bodies or resources at a problem is not an adequate way to deal with things, and it may well cloud your view of the state of play.

Many of these things overlap, of course, so it's worth taking a deeper look to understand these in the context of business-as-usual.

BAU and ownership #

Ongoing client projects and existing customer relationships create the biggest challenge when you take up a CDO position in an organisation. But at the root of that issue is likely to be a lack of process authority or ownership.

Delivery or project managers may exist in the organisation so that individual client engagements can go from beginning to end. But the existence of a delivery manager or two is not the same as effective ownership of a coherent, high quality customer experience.

Indeed, it may well be evidence that delivery ownership has been shrugged off into a void, with responsibility hanging in a no-man's land between CEO, commercial director and chief operations officer. You may even discover that technical architecture or solution design has a fundamental lack of delivery leadership expertise or authority behind them. Why would the expertise exist if no one has ownership?

Asking this question of your CxO peers would be instructive — who owns the customer experience?

Review recent work #

At this point it's probably worth taking the temperature of recently delivered or closed projects. A close look at the outcomes, the value delivered (to both the customer and the business) plus any documentation about the journey from start to finish, and any things learnt or actions taken — all will be instructive and give you a fairly quick assessment of the maturity of delivery practices and processes.