

Ask HN: Has anyone here saved a failing software project? - jmilinion

If so, how did you do it?  Was the old team still there or did it need new people?
======
voidvoid
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.

------
davismwfl
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.

------
projectileboy
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.

------
pasbesoin
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.

