I briefed a developer on some work first thing this morning. We went through it together and discussed all of the tasks that needed to be done. The developer told me he would have the work finished by the end of the day.
At 3pm we had a check-in and he was only half way through the list! He said he’d hit an issue and wouldn’t get everything finished today.
How should I handle this situation? Should I let it slide or let him know he should have got the work finished on time?
Mark – Junior Digital Project Manager
Great question, Mark. This is a really common situation that project managers find themselves in. Lots of our job is managing expectations, and that doesn’t just mean managing our team’s expectations about the pace of the project and their own work, but also what happens when this expectation isn’t met.
There’s a couple of ways you could handle this, depending on the person, the work and the impact:
The first thing I’d consider is if this is common behaviour for this person. Have you found this developer is consistently late in delivering work no matter how complex or easy the work is, or how much time they have?
If working with this developer is like groundhog day and always ends without a delivery you definitely shouldn’t let it slide. Not only that, but you should raise it with the developer’s manager or the project’s technical lead, in addition to your manager.
But, before you go charging off to put things right, stop and think for a moment about whether this person is always missing deadlines because they don’t have the skills or support to deliver the work or the knowledge to size tasks correctly. Or, has this person checked out and doesn’t care how their work impacts the wider project and team. Having a view on this will help you frame the conversation with your seniors in the right way.
If your developer usually delivers well and on time, and you feel they have done their best and have been upfront and honest with you, think more about the work and project before making your decision.
You don’t mention what the work is that you briefed, but there’s a huge variance in the type of tasks we ask our developers to complete and the complexity of them – all the way from making changes to a legacy system with inconsistent and unintuitive naming conventions, to architecting a brand new solution, or BAU bug fixes.
If you were to draw out two intersecting axis, one axis representing time (quick, lengthly) and the other complexity (routine and easy, or novel and difficult), which quadrant would the work your developer was tasked with fall into? For more difficult or lengthy tasks it’s much harder for team members to estimate accurately.
If it’s legitimate that the work was straight forward, routine, easy to understand and execute then you can fairly challenge why it wasn’t completed. If the work is unknown, novel, or difficult you should be a little more sympathetic and assess the impact of late delivery.
When considering if you should let late work slide I would consider what impact it has to the project. Has this incomplete work meant, a missed client deliverable, a reasonable impact to the project budget, an alteration to the project timings, scheduling conflicts for other projects, or a cumulative impact of two or more of the above?
If the unfinished work means an impact to your agency, the client, other projects, or other people on the project you should at the very least make the developer aware of the knock on effect. They are part of the project team and they should know how their actions or omissions impact the wider project and delivery. If the impact is minimal or non existent then I would be inclined to let it slide.
People aren’t robots and they can’t do everything perfectly every time. Sometimes we make mistakes, have an off day or just get it plain wrong.
Team transparency and the ability to be up front and honest is paramount to running a successful digital project. Within reason, you should encourage (and never punish) this when it happens.
If you find however that you have consistently missed deadlines and apathy for straight forward work which is impacting your project (or any one of these things) don’t let it slide – start the conversation about why this is happening and how to resolve it.