Comment by powatom | Hacker News Reader

Comment by powatom | Hacker News Reader

I was fortunate enough to experience this exact kind of death march over a period of around 18 months.

Unless you have the authority to guide the project back on track, there are only so many options available to you:

1: Document your concerns and any problems you've identified. Be objective wherever possible (i.e don't bitch about your co-workers even if the reason the project is failing is because they're fucking it up). Any problems that you've spotted and are worried about, WRITE THEM DOWN and email them to your project manager.

2: Keep a cool head. This is incredibly difficult once endless frustration sets in. Bite your tongue, and don't get personal. You will probably fail from time to time, because knowing that you're going to fail is a horrible, insomnia-inducing feeling, and your patience will almost certainly be tested.

3: Offer solutions. If you think a particular decision is to blame for some aspect of the failure, then document it, what went wrong, and what any alternatives may be.

Unfortunately, in my experience and from what I gather from other people, these kind of things tend to come along with ridiculous company politics and emotions. If your gut feeling is that it's going to fail, then your best approach is to try to raise the alarm as soon as you notice. You may be ignored or brushed aside, but you must document everything you do. Don't raise the concerns in conversation, make sure there is a paper trail.

In my own case, the project failures ultimately led to me and several other developers abandoning the company. The project could have been saved if our concerns were taken into consideration and acted on. We even presented a proof of concept redesign which solved all of the existing problems AND presented new opportunities for growth, and were told that our new design would not see the light of day. Keep in mind that we had working code, schemas, deployment plans, addressed scalability concerns, and even had a development roadmap for the new design. Some battles are un-winnable.

You beat me to it ;) This is my list:

I'm in a similar situation and the pressure is mostly caused by a lack of management.

I've been appointed project leader halfway the project and I did my homework by reading the Software Project Survival Guide. We are also supposed to work in a scrum system, but on going business causes scrum to be just an extensive time management tool.

We're nearing the deadline and a few things I picked up are:

1) You need to have a hands on approach and come up with solutions yourself. Show a lot of initiative.

2) Have clear roles of who needs to do what.

3) Don't change roles halfway a project, it only causes confusion and someone needs to clean up the mess.

4) Be frank to your business owner about the current reality . You don't want to be the guy, who didn't say anything and pass the deadline. And don't wait too long with saying it.

5) Make it very clear to the business owner, all changes cause a delay. And whatever you do, do not let the business owner decide how long a change will take.

6) Don't fight with the external guys, even if they are trying to run the show. If they start pressing for decisions (framework/system/etc) without a good reason, other than their own comfort, be warned... Get ready for a sticky situation. If you can, stick together with your current team to have some counterbalance.

> 5) Make it very clear to the business owner, all changes cause a delay. And whatever you do, do not let the business owner decide how long a change will take.

This, unfortunately, seems to be a rather large factor when it comes to figuring out why a project failed. Unrealistic expectations are absolute killers.

make sure there is a paper trail

Unless the situation results in criminal prosecution, when the time comes to use that paper trail nobody will care about it.

> nobody will care about it.

I disagree. If the company in question is large enough having documentation that you were actively trying to avoid disaster, were competent enough to raise concerns and suggest solutions, etc. can be helpful when people come trying to assign blame after the fact.

If the company as a whole will survive the impending train wreck then having evidence of competence, however meager, is certainly useful in many situations short of criminal prosecution.

I'd like to hear from anyone who kept a paper trail which was, in fact, used as so intended. I'd also like a show of hands where it was kept to no avail.

I've been on a lot of projects. Where a paper trail seemed warranted, those who came to assign blame had already chosen their targets without consulting with them first.

Having conversations documented in emails really saved my keister on multiple occasions.

Admittedly on one of those occasions, the effect wasn't immediate -- the manager in question basically rage-quit the conversation. But she put a lot more thought into getting confrontational in future disputes.

(Although I have to clarify that this was a fairly dysfunctional environment (and had been for a while), due to which I figured getting things in writing was the safest choice. In future more cohesive settings, I didn't bother with this as much, as the teams tended to have more integrity.)

> Unless the situation results in criminal prosecution, when the time comes to use that paper trail nobody will care about it.

That's true. Pointing to your paper trail when the shit hits the fan might actually label you as being uncooperative during a critical project; most likely, the manager doing any personnel "cleanup" will be the same that was responsible during the project (line manager vs. project manager). Besides, if a project is doomed, you are not the only one to notice it, so the fact that you pointed it out does not single you out as especially perceptive.

If the person doing the cleanup is the same as the person who was directly in charge of running the project, then you have different problems.

Possibly, but it depends on the project - the level of investment, and the structure of the company itself. If the project's failure is a threat to the company at large, then it's likely that an internal investigation will take place. The paper trail will help defend you.

Reply on news.ycombinator.com