Ask HN: Has anyone here saved a failing software project?
If so, how did you do it? Was the old team still there or did it need new people?
5 comments
Saved might be a strong word, but I've helped some projects get delivered over time and over budget, when four previous teams had failed to deliver at all.
That really is a significant warning sign. If you are dealing with an organization that is currently failing at something it can mean almost anything. They don't have the skills? They trusted a 3rd party supplier? They have one bad leader?
If you are dealing with an organization that has failed repeatedly on the same task, then you are dealing with entrenched issues that you are not going to easily change. If they've decided in the past that this project can be done by 10 people in 3 months with continuously increasing scope then there's a good chance that's how it will run this time too.
As far as I can tell the key is to learn to be diplomatic but emphatic about saying no.
You can only be an asshole to coworkers occasionally, and you need to recharge your karma in the meantime, so being the guy who always says "no, that's too hard. It would take too long" will just mean you'll get sidelined and routed around.
You need to be the guy who says "Yes! That feature sounds awesome! Our customers will love it! Which feature can we cut to make time for it?"
Pretending that design and scope will stay the same for 6 months is fantasy, but as it changes you need to maintain a non-negotiable climate of people working regular hours and not getting bullied into making impossible promises.
Give somebody a goal 10% out of his comfort zone and he will work harder to meet it. Give somebody a goal 50% out of his comfort zone and he will make jokes about the whooshing sound that deadlines make as they fly past.
That really is a significant warning sign. If you are dealing with an organization that is currently failing at something it can mean almost anything. They don't have the skills? They trusted a 3rd party supplier? They have one bad leader?
If you are dealing with an organization that has failed repeatedly on the same task, then you are dealing with entrenched issues that you are not going to easily change. If they've decided in the past that this project can be done by 10 people in 3 months with continuously increasing scope then there's a good chance that's how it will run this time too.
As far as I can tell the key is to learn to be diplomatic but emphatic about saying no.
You can only be an asshole to coworkers occasionally, and you need to recharge your karma in the meantime, so being the guy who always says "no, that's too hard. It would take too long" will just mean you'll get sidelined and routed around.
You need to be the guy who says "Yes! That feature sounds awesome! Our customers will love it! Which feature can we cut to make time for it?"
Pretending that design and scope will stay the same for 6 months is fantasy, but as it changes you need to maintain a non-negotiable climate of people working regular hours and not getting bullied into making impossible promises.
Give somebody a goal 10% out of his comfort zone and he will work harder to meet it. Give somebody a goal 50% out of his comfort zone and he will make jokes about the whooshing sound that deadlines make as they fly past.
I used to run a consulting practice where all we did was technical project rescues. I can say it is never really fun, almost always sucks and is never easy (which was the draw for me). The range of issues is huge, from entrenched teams unwilling to adapt, to horrible leadership to just a general lack of experience.
The recipe is almost always the same though, identify the gaps, increase communication, organize the project, reduce the initial scope, set some realistic deadlines, get some easy/quick wins and get both sides (IT and business) to the table to discuss reality regularly.
Also, quickly get rid of negativity, if you find someone that pulls the team down and out, try to pull them aside and get to the root of it. If they can't be influenced to help positively get them off the project or out of the company quickly, like ripping the band-aid off. No one likes to talk about firing people, but reality is what it is, one bad apple on a team can destroy a project by killing morale and feeding FUD. And frankly, you aren't doing that person any favors by letting them stay and be miserable either.
My 2 cents, projects need to be rescued because of weak leadership and decisions that went without being made for too long. A bad decision is almost always better than no decision, at least you have something to work with. No decision is almost always a mistake and guarantees nothing changes.
The recipe is almost always the same though, identify the gaps, increase communication, organize the project, reduce the initial scope, set some realistic deadlines, get some easy/quick wins and get both sides (IT and business) to the table to discuss reality regularly.
Also, quickly get rid of negativity, if you find someone that pulls the team down and out, try to pull them aside and get to the root of it. If they can't be influenced to help positively get them off the project or out of the company quickly, like ripping the band-aid off. No one likes to talk about firing people, but reality is what it is, one bad apple on a team can destroy a project by killing morale and feeding FUD. And frankly, you aren't doing that person any favors by letting them stay and be miserable either.
My 2 cents, projects need to be rescued because of weak leadership and decisions that went without being made for too long. A bad decision is almost always better than no decision, at least you have something to work with. No decision is almost always a mistake and guarantees nothing changes.
Yeah, sometimes. It's challenging. When I've been successful, it's usually been a mixture of ingredients: a majority of capable team members who want to succeed; some level of management support for the changes you need to make; introducing (or improving) build and test automation; and planning and tracking work iteratively, chunking work into small end-to-end slices whenever possible. I know "agile" methods often get a bad rap (and often rightly so), but if you have a project in trouble, you need to be able to understand how much work you have left, and how you're progressing towards getting that work done.
Meta: Make sure you get paid and credited for it. (And note the order in which I listed those.)
The world is full of discarded heros.
The world is full of discarded heros.