How to blame developers for missing deadlines
Blame the devs
How to blame the developers for missing deadlines
Yet another deadline for development missed. Are you surprised? It’s not really a secret that IT projects run over budget.
On average, large IT projects run 45 percent over budget and 7 percent over time, while delivering 56 percent less value than predicted. Software projects run the highest risk of cost and schedule overruns (McKinsey Digital)
Software projects and their related cost over runs has been a constant thorn in my side for over 20 years of my professional technology career. I have lost countless nights to stress related to software projects and their respective deadlines, both as a developer, project manager and now company leader.
I have learned a secret that seems to help IT and software related projects run more smoothly. At the core it is key to understand how to blame developers when they are late on their project delivery. It’s quite simple.
Here’s the 1 step process to blaming the developers for a late deliver: You can’t.
I have been on both sides of the “blame the developer” game; and it’s a game neither side can win. My assertion is based on an assumption that you’ve hired qualified people to be your developers. However, if you did not then that is also your fault - not theirs - so devs are still in the clear.
So what is the secret to improving better budget process? Keep reading!
There are two basic factors that I have seen derail a software project.
One is something you can’t directly control - the optimism that developers have over doing simple things. For example, if you hear a developer say “oh there’s a third party module I can plug in that will take care of that requirement”, you should be raising a red flag. In my experience as a developer it was always the easy things that I took for granted that blew up in my face. I have seen this pattern in my colleagues as well.
The second big factor is clarity of requirements. I have been in projects and worked with organizations that try to solve this problem by having ages and pages of detailed requirements. And yet the software still fails. In my experience this is because most requirements tell developers what the software should do and frequently leave out why the function is important.
The secret that I have found is that the more articulate the goals are for the module, system, or project, the better the outcomes for the project. In my experience developers are generally intelligent, creative problem solvers. If you give a developer requirements, you present them with a solution rather than a problem to be solved. A good developer will deliver exactly what you asked her to build based on the specifications provided. A great developer will ask you why you need the functionality in the first place.
Consider the following scenario. It is a parable for many, many encounters I have had in project management.
A Senior VP (SVP) tells the Marketing Manager (MM) that the big boss (CEO) wants a button placed on the website to make a “ding” sound.
MM goes to his CTO to ask what it will take to get the button placed on the website.
The CTO asks her developer how long it will take to add the website.
CTO tells MM it will take 3-4 days, including deployment.
MM gets the approval from the SVP and green-lights the project.
Developer creates a button on the site using corporate colours that makes a “ding” sound, is done in 2 days and is well ahead of schedule. She is happy.
MM looks at the button and says “Oh, can we make it red? I think a red button would stand out more.
Developer changes button to red and ships a new version the next day.
MM sends the project to the SVP for feedback. [ Note: there’s probably a cycle of feedback here as well, but moving in for time’s sake.]
SVP sends to CEO for approval.
CEO sends a scathing email reply, copying the SVP, MM & CTO: “This is not what I want. I want it to only show up if it will help make people happy!!”
SVP rolls eyes, calls a meeting with the MM and CTO.
SVP, MM & CTO brainstorm a new solution: we will only show the user the button if they are not already happy.
CTO asks Developer to make it so that “the button only shows up when people are unhappy”. She also discloses that the CEO is super upset and this button needs to be the Developer’s top priority.
The Developer goes on a Herculean development arc, figuring out how the user’s mouse movements can be extrapolated into their relative mood. The solution takes 2-3 weeks and the Developer feels they have advanced computer science with their solution.
CTO feels similarly chuffed with the brilliance of the solution and sends it to the MM and SVP for feedback.
Elated, the SVP sends the new button design to the CEO for final approval. The CEO’s excited to see the new round. “I can’t see the button,” comes the quick terse reply in email.
The SVP responds “That is probably because you are happy. Try being angry, you will see the button then!”
The CEO is once again livid (although at least now can see the button): “All I want is a button on the site that will make people happy, why is this so hard?”
The project is now 3-4 weeks instead of 3-4 days, everyone’s frustrated, and the developer gets another set of requirements that may or may not make things better.
If I were in the Marketing Manager’s position, the first question I would have asked my Senior Vice President is: “Why?” Why are we building this button? If it’s to increase the happiness of the user then is the button the right way to do that? How should we frame the button?
If the project came structured as follows then I believe the team would have had an easier time:
SVP: “We need to put a button on the website that goes ‘ding?’
MM: “Why?”
SVP: “I… don’t know.”
SVP goes to ask the CEO. CEO responds that she feels it’s important to be able to help improve her user’s mood - and she saw a button on someone else’s’ website that went ‘ding’. It instantly improved her mood so she would like that experience for her users.
SVP clarifies: “It sounds like you want a button that, when pressed, could increase the happiness of our users?”
The CEO says, “Yes! Of course! Why do you think I asked for the button?”
The team now knows the problem that they’re trying to solve. The Developer realizes that they can whip up a quick prototype to see if her idea works for increasing happiness. The MM decides to put in some analytics to measure the results. How’d they do when the goal was articulated?
Let’s see: “Having a tough day? Press this button to feel better!” [Warning: Plays actual sound]
Based on the results of the poll, we will know if our MVP solution met the goals or if we have a new idea (the prototype took me about 25* mins to build).
My experience is that if you can be more clear bout the ‘why’ and the goals you’re trying to achieve you can end up with better results and productivity from the creative, problem solving developers.
* My first draft of this post had 5 mins here; unfortunately the first poll software I use didn’t work with SquareSpace. 20 mins was spent trying to find other software that works. Old developer traps die hard.