Where do delays start?

Delays are a problem for almost everyone that has ever worked in the IT industry, even with the best team and a generous budget it can be difficult to avoid them. Especially in the highly regulated industries which we’re so familiar with. Its rarely one person’s fault, so is there something that can be done to avoid mistakes early on or tackle them once it’s too late to avoid? We’re speaking with Automation Logic’s Head of Delivery Nick Barton about what he’s seen from his extensive experience working in the field. 

Nick, you have over 20 years experience leading large projects working with enterprise companies in the UK, during your time have you noticed any common themes on how and where project delays can start?

One thing that delayed projects always have in common is that all the decisions are made either up-front or made too far removed from those on the ground. When this happens you’re not given the ability to be able to adjust as you go, things will always come up as the project progresses and that may well call for a change in tact or need a different approach if the current one isn’t working. That’s the most obvious sign.

Of course, you have to have an idea of what you’re doing and have direction, but you can’t make all your decisions upfront. 

The way to tackle this most efficiently is to get the right team stood up from the start with wider stakeholders also identified and engaged to make the decision-making process far simpler. This gives everyone a chance to compromise on requirements and move forward working in a frictionless environment.

When delays are spotted do you have an example of a right way and a wrong way to deal with the problem? 

A common mistake is when IT directors or senior people see the project isn’t on track, their immediate reaction is to put more controls and reporting and requests for updates, this tends to introduce blame, people blaming others or avoiding the blame for causing/breaking something. That’s just instinct. Often all you need to do is increase the trust you have in people and look at what’s blocking them or what’s slowing them down, then put your energy into removing the blockers. Almost always the most helpful thing you can do to speed up delivery is move the decision closer to the front line. Don’t interrupt, observe, find the blockers, and help remove. A good way of doing this is utilising the crucial role of standups and agile processes within your team. Don’t just ask for a report on the standup but go yourself. They should always be open to anyone, so attend and observe or take an active role for yourself. More generally, take a look at the outputs of retrospectives consistently and address any obvious issues that come from these. It is always easier to observe from within the team than to force things from a distance. 

Another way of looking at this is taking a step back. When you’re doing a project you have your scope, your resources, and your execution date. You can hit that date by reducing the scope and increasing resources, but often it is near impossible to hit all three when they have been set too early. There’s a limit to the number of people you can throw on, so the variable factor really comes down to scope and date, when you hit a problem you need to be ready to adapt. 

This is why a lot of delays start when people being a project saying ‘I want everything done by a certain point in time’ when really people should focus on what adds the most value first. 

When you’re working on a project, you often come into a client organisation and aren’t given the choice of how the plan is made. So when you’re on-site, what are some subtle early signs you pick up on that show a delay is likely to happen in the near future? 

The most obvious one is people working late, or working weekend shifts, things like that can be a sign that things aren’t working to plan. 

Also, it’s a warning sign if a company is talking of a hard deadline of ‘we need it all done by’ which is a red flag as they may want to roll something out in one go, which adds a lot of pressure to deliver on time, because there is no value-add until full delivery. This is why delivering a minimal viable product is often a good solution for companies to test value and build trust before committing to a full-scale rollout.

You can link back to the agile principles here, that’s what agile does if you think about it from an IT management point of view, they don’t necessarily have any idea of what people are doing, they know value, outcome, cost. 

Without a process in place, what do you typically see when it comes to teams reacting to delays? 

The team themselves, a conscientious one at least, will just put in the hours. They’ll be trying to keep whoever is responsible happy by delivering. You get burn out from this though, what will tend to happen is you end up without anyone taking prioritisation calls properly, switching your work from proactive to reactive, which will end up downwards spiralling to further delays. 

The structure we have around our projects, people will escalate to their project lead who escalates externally and we try and tackle the source of the problem and intervene to protect the team and keep delivering value, but to be completely honest at this point it’s often gone too far to avoid delays entirely, without the proper set up, everything else still has that element of reactive working. 

So if you spot those signs earlier talked about… How do you save those projects from further delays? Or how do you ensure that you’re getting on the best possible track to be adding value as soon as possible?

You often have loads of work coming into the pipeline in these situations, that becomes your backlog, get people to prioritise the backlog – those are the immediate things and then get someone to enforce that priority so people don’t constantly change that. One point of authority is the project owner. They need to prioritise the work based on the value-added to the customer. 

The caveat out of that is that it depends on the architecture of whatever you’re delivering being something you can deliver in pieces. If you’ve not architected very well you end up with something that can’t be broken down and you go with the big bang approach. You might not be able to go live bit by bit, but you can generally at least create something people can beta test in the right environment. 

So having the product owner prioritising backlog is tactical, but you might have to step completely back and make a tough decision and delay/pause the project and fix it then carry on. That can be the best way to go at times. 

So, what is your top tip for avoiding project delays as early as possible?

If you have the opportunity to get in early and be a part of the planning process: Invoke the agile process, don’t be afraid to spend a long time in discovery, which is not about defining in detail what you’re going to do but the problems you’re going to solve and how you’ll know it’s been successful. 

If you’re coming onto a project at a later date: Get the right people with the right skills, base the rest of the project on how long it will take rather than when you would like it, and start with getting the MVP.

Interested in more tech-related content? check out our Engineering Hub.