Guest blog by Nicol Cutts – Stoneseed, Head of Projects, Professional Services
Since the IT Project universe reopened after the lockdowns, I’m noticing a shortening of the gap between something going wrong in projects (failing) and that something getting fixed. What’s more, IT Project teams that are setting themselves up this way are not only more successful but more importantly – more innovative too!
As a trend, it is really encouraging.
So, my anecdotal evidence is based on the space between a client’s project experiencing a problem that would be ‘right up Stoneseed’s street’ (like governance issues, talent shortages, skills gaps, etc) and them calling us for assistance.
Of course, many clients are totally proactive in this regard and, together with Stoneseed, head off these issues before even embarking on a project – for instance, if your project is going to need PMO support, best to have identified that and have it in place from day one.
My sample group for this blog, and (again) this is just my own experience, is based on the projects that start but then hit a problem. They encounter a challenge that perhaps could not have been foreseen, for example, a change in market need forces a scope change, a key team member gets COVID, talent-demand-driven higher salaries lure away a colleague.
One client calls events like these ‘a fail-flash’ – an advanced newsflash of a potential cause of your project failing, like a breaking news bulletin about a story that will develop. I love that analogy!
Of course, the important thing is how you react to this newsflash, how you respond in the best interests of the intended outcome of this project, and the lessons that are learned for future projects. It is the speed of that response and the added value of the lessons learned where I am seeing the greatest gains right now.
As far as response times are concerned, by way of illustration, look at (or imagine) a stopwatch. The first second is the moment where the issue arises and the point at which you hit the stop button is where the issue it is dealt with, let’s say, thirty seconds on the clock.
In between these points, there are three other key events – identification/acceptance of the problem, identification of the solution and, finally, execution of the solution, you can imagine pressing the lap timer button on your stopwatch as you reach these points.
Start the imaginary clock! Before the pandemic, my experience is that most projects would have accepted a problem had occurred at around the 20 second mark (to be fair, you can’t always see what you’re not looking for). It would have perhaps taken a further 8 seconds to identify and agree on a solution and then the last two seconds would have been spent implementing and executing the solution. Stop the clock!
Imagining those stopwatch seconds as hours, days or even weeks, and you can instantly get a sense of the damage that can be done to a project when there are gaps between a problem occurring, and it being identified, and a strategy being agreed and applied.
In my sample group, of course, the client’s solution was to make my phone ring! (Which also explains why the execution part of the stopwatch was so fast!!)
Now, post pandemic, I’d say, I am mostly getting that call at around TEN seconds on our imaginary stopwatch!
I say this because there’s certainly less of a ‘firefight feel’ about most of the calls for help, increasingly they are more pre-emptive. Which means, I think, that teams are getting better at identifying issues and acting upon them.
Perhaps, it’s a cultural shift driven by tighter budgets and increased pressure on returns on investment, maybe it’s the more reactive nature of projects in this post pandemic environment – I don’t know! But I do know that it’s making teams more adaptive, responsive, and innovative.
Certainly, increased innovation is an interesting by-product and I think that this comes out of the desire to learn lasting lessons from those ‘fail-flashes’ and not just solve an immediate problem and move on.
For instance, one project team I work with never used to routinely access the talents of a Business Analyst – the BA skillset and responsibilities were sort of spread among the team members. Their first job back after COVID was to reignite an IT Project that had been mothballed during the lockdowns, it was not an easy project to just pick back up and run with and the team had a turbulent experience to begin with. Using Business Analysis as a Service (BAaaS) allowed them to reassess business need (the market and hence the business case had shifted); identify new, more relevant, deliverables that could be easily added into the project’s scope without affecting cost and delivery timeframes and re-evaluate original deliverables for market relevance. As a result, this project delivered a more market-appropriate business outcome.
The team admits that before the pandemic, they might have not noticed the shift in the market, the greater margins for error (that used to exist) may have led them to be less sensitive to changing business need and they probably would not have seen the value of a BA as they’d shared the role between them and that was just the accepted way that things were.
This team now has a Business Analyst on the team, and they’ve never looked back! Furthermore, every benefit realised by having a BA on subsequent projects can be traced back to that turbulent first project back after COVID and the ‘failings’ that they identified and addressed.
This is what I meant by ‘failing’ to innovate at the outset. Acceptance of failure as a necessary catalyst for innovation and improvement may be the silver lining that we take from the clouds of the past couple of years and there are loads of precedents.
The story of James Dyson and how he came to lead the world with cyclone vacuum cleaners by failing his way to new levels of innovation is a great example to us all. Dyson noticed the frustrations that he had when vacuuming, the blocked filters that slowed down the process are a great metaphor for the problems that slow down our projects – the failures of the existing solutions should be noticed and acted upon and not brushed under the carpet (although that would also speed up the Hoovering!)
Noticing this failure opened up a solution space for Dyson and on a visit to a sawmill he saw how wood shavings were sucked out of the mill using a cyclone – he joined the dots, and the rest is history.
Writing in his book, Black Box Thinking, Matthew Syed observes, “Dyson was not the first to come up with the idea of a cyclone vacuum cleaner. He was not even the second, or the third. But he was the only one with the stamina to ‘fail’ his concept into a workable solution. And he had the rigour to create an efficient manufacturing process, so he could sell a consistent product. His competitors confronted the same problem and had the same insight. But they didn’t have the same resilience to make their idea work, let alone take it on to a working production line.”
History is full of innovators who take a ‘fail-flash’ and turn it into a market leading innovative solution – it’s a discipline worth developing.
Ensuring that your processes run seamlessly and deliver efficiently is often about ironing out the niggles, flaws, and undesirable deviations – how can you do that without failing?
From IT Technical Advisory, Business Analysis Services and PMO Services through to Programme & Project Delivery, Stoneseed’s comprehensive range of services and resources are designed to support and enhance your project delivery capabilities in line with your demand – and all via a highly flexible and cost-efficient delivery model that we call Project Management as a Service. A true end to end service, and our costing model means you only pay for our services and resources when you use them … so what have you got to lose?
Have you noticed a ‘fail-flash’ that Stoneseed’s service portfolio can help with?
If you have, by my stopwatch, I expect your call within ten seconds!
I’m on 01623 723910 or email email@example.com.