The Joel on Software Discussion Group (CLOSED)

A place to discuss Joel on Software. Now closed.

This community works best when people use their real names. Please register for a free account.

Other Groups:
Joel on Software
Business of Software
Design of Software (CLOSED)
.NET Questions (CLOSED)
TechInterview.org
CityDesk
FogBugz
Fog Creek Copilot


The Old Forum


Your hosts:
Albert D. Kallal
Li-Fan Chen
Stephen Jones

Death March

I'm working on a fairly large development in the financial industry at the moment, it's got a budget of around $4M and a team of 12 (in total) developers/testers/BA's etc.

It's a 9 month project and we are about 3 months into it and already things are starting to slip, we had planned a team lunch last week to commemorate the finishing of the first phase of it. However, as things are slipping the PM decided that we haven't 'earn't' the lunch, and that also we may have our internet access suspended because he has noticed a few people looking at non work related web sites etc. Also at our last project meeting a the first beginnings of some potential finger pointing were starting to reveal themselves, with certain people who were on time with their work getting pats on the back and the rest of us (yes, me included, sob) getting told that we may need to 'do more hours' and 'be more professional'. The really annoying thing is that the time estimates were imposed on the developers, and the requirements/design documentation used to determine the estimates is full of holes. For each documented chunk of work their is usually at least one other piece of undocumented functionality required, typically 'discovered' as a result of the development process. Also, as most of the development team are contractors without specific industry knowledge, and with some parts of the business washing their hands of responsibility, and some emerging arse covering behaviour patterns - it's shaping up as a death march. 

Which actually, I don't mind. This type of project can be very interesting as the pressure starts to rise, there are the beginnings of some rumblings amongst the developers/testers and the business already.

Does anybody have experience of working on this type of project and what to expect, what types of responses to expect from management and the technical team etc?

Also any reading that you know off would be appreciated.

It's going to be an interesting 9 months!
Alberto
Friday, October 07, 2005
 
 
Communicate your concerns and possible solutions diplomatically with the PM.  Use email as a way of recording the proactive communication of your concerns.  If that doesn't have a positive outcome, only work 40 hours a week and start looking for another job or contract.
cipher
Friday, October 07, 2005
 
 
Your project is very badly managed and you are going to face serious problems. You won't win this by doing good work or anything like that so listen up, this is how to play their game.

1. Tell your project manager that he is right, you are not professional enough to keep up with the schedule, and that he should assign one of the golden boys to do your work, while you do the golden boy's work.

2. Alternatively, tell the project manager that you are having trouble and ask for his detailed guidance and assistance to complete work on time. You want him to give you a detailed set of tasks that you can follow easily. Then he can't bag you without exposing his own incompetence.

3. Put down in writing that you have serious concerns about the scheduling of the work assigned to you, and break it down into details. If you've previously raised these concerns, include that in the memo. "I discussed this with the Project Manager at the project meetings on 10 May and 16 June." Then send the memo to anyone you think useful, and print it out and take a copy home.
been there
Friday, October 07, 2005
 
 
Learn what you need to learn and don't let anyone put any pressure on you. If your "superiors" make it impossible to deliver, at least love the one you are with.
son of parnas
Friday, October 07, 2005
 
 
Nothing you do will be good enough. So acquit yourself with pride, and document everything (per above) so that in the future a reasonable person can see that you weren't the problem.
Philip Prohm Send private email
Saturday, October 08, 2005
 
 
I was in that situation. I took option #3. It didn't take me long to find another job.

Philo
Philo Send private email
Saturday, October 08, 2005
 
 
Just out of curiosity; did the development staff (coders and QA) have a chance to inspect the requirements prior to signoff? Was there a formal requirements review process?
Master of the Obvious
Saturday, October 08, 2005
 
 
"However, as things are slipping the PM decided that we haven't 'earn't' the lunch, and that also we may have our internet access suspended because he has noticed a few people looking at non work related web sites etc."

I've seen this at other places too.  The thing is, if people are abusing their Internet access, it should be addressed even if the project is on schedule.  If occasional nonproductive browsing is tolerated as long as the schedule is good, but not if the schedule slips, then it (and those who do it) are being used as scapegoats for what's really due to poor project planning.

Cutting off the access completely strikes me as extraordinarily stupid.  I use the Internet (most particularly Google Groups) all day as a technical resource.  Not having it would just make some things take much longer.
Kyralessa Send private email
Saturday, October 08, 2005
 
 
"what types of responses to expect from management and the technical team etc?"

Unable to see the problem lies in their plan, the management will keep increasing calls to work harder, and increasing the blame game.

However there is also the chance that someone will "sell" them on a grand solution of some sort; a panacea mirage that they will lunge for. One of their pet developers on the technical team may present them with a "way out." Alternatively a vendor might wine and dine them into jumping into a new framework. This can result in management swinging the project into a new and useless direction, and more increasing calls for the developers to work even harder.

Typically, when management did not choose an architectural design that lends itself to the project in the first place, everything the managers do from here until death will reveal they live in a fantasy.

Hunker down, and do your best to learn some cool technology for your next job.
Ben Bryant
Saturday, October 08, 2005
 
 
Indeed, cutting off Internet access is just childish. It's the most basic knee-jerk reaction of an incompetent who is put in charge.

"Nearly all men can stand adversity, but if you want to test a man's character give him power" -Abraham Lincoln
some guy
Saturday, October 08, 2005
 
 
One would hope even a very stupid company would know better than to completely turn off net access for their programmers.  Might as well solve the problem of daydreaming at the desk by giving them all lobotomies, too.
Matt Conrad Send private email
Saturday, October 08, 2005
 
 
"did the development staff (coders and QA) have a chance to inspect the requirements prior to signoff? Was there a formal requirements review process?"

All requirements/design doco were signed of by the management team with developers forming part of the review process, time estimates were completely imposed and any questions or concerns raised by developers raised ire and eye rolling , tongue clicking responses from management.

A few people have mentioned keeping email responses to concerns raised, do you think that it actually matters, I mean if you turn up on time, work hard, and try, even if the project fails, isn't that enough?
Alberto
Saturday, October 08, 2005
 
 
>>I mean if you turn up on time, work hard, and try, even if the project fails, isn't that enough?<<

No. If the project fails, "trying" isn't enough. You failed. Learn from it and move on.

That being said, as others have said, document everything you can and keep a record of it at home or somewhere else off site. This sort of documentation could come in very handy should somebody be looking for a scapegoat and they choose you. As long as you can back everything up with something in writing and what you have documented jives with your version of the story, you shouldn't have much to worry about from a professional standpoint. This is, sadly, a necessary evil.
Bart Park
Saturday, October 08, 2005
 
 
Bart et al. are so right.

Besides, on your CV it's a real challenge to portray your part in a slowmotion disaster in a positive way.
trollop
Saturday, October 08, 2005
 
 
> Also, as most of the development team are contractors ...

As [independent?] contractors, what is your liability if any in the event that the project fails?
Christopher Wells Send private email
Sunday, October 09, 2005
 
 
If they are contractors, there is a liability that they did not deliver what they said they delivered when they said the delivered it.

Also, there is the question of reputation. If you, as the contractor, can show that the project went south because the customer ignored or disregarded your professional assessment of the situation, that goes a long way toward countering the bad mouthing that some people are likely to do saying things like "Alberto? He couldn't deliver a birthday invitation next door, never mind a software project. He signed on to do X for us and it was a miserable failure." That sort of thing happens all the time. The company I work for almost lost a significant prospective customer recently because of that sort of thing. The prospect was told by another customer that our software couldn't perform a certain task. Turns out it can, so I was able to deliver the functionality the prospect wanted and I was able to save the deal, but it was a tremendous hurdle to overcome.
Bart Park
Sunday, October 09, 2005
 
 
The floggings will continue until morale improves.

This has been a management failing since the dawn of time. You should go with the flow, but shine up that resume right now. You may need it sooner than you think. There is nothing to be gained from confrontation with the PM, only constructive feedback could help. Be careful how you phrase your suggestions and complaints.
SumoRunner Send private email
Monday, October 10, 2005
 
 
It has been mentioned, but can not be emphasized enough.  Document things in writing as you go.

[conversation at 'end of project inquisition']

You: "but I told you, back 6 months ago, that it is not possible to write 5 million lines of code in 8 hours and you said be professional and do it anyway"

PM to Senior Manager: "No he didn't say that, he is lying.  Its all his fault not mine, off with his head!"

You: "Ahh but see in this email dated..."

[and yes, it is unfortunate]
Scot Send private email
Monday, October 10, 2005
 
 
>>You: "Ahh but see in this email dated..."

I have done this many times and have it not work.  The one that prominently sticks out in my mind is a request for a certain feature. A certain someone came back later and asked me why it was all f***ed up.  I looked at it and came back and told her it was designed that way.  She then asked me what idiot came up with that.  I said I would check and see see if I could figure out where the original request came from (all the time knowing exactly where it came from).  I found the offending request in an e-mail from her. 

Her defense..."that is not what I meant."

You see...I failed to understand that when she asked for X her intent was Y.  I should have known because I should have known.

So, I immediately deleted my CYA file because there is no CYA.  In these situations you are always wrong, in fact there is no way to be right.
Mark Flory Send private email
Tuesday, October 11, 2005
 
 
..."that is not what I meant."

At least then you have equal footing with that person and can equally say "you requirement description was inadequate" so it's a tit for tat blame game rather than a one way street ending at your door.
Alberto
Tuesday, October 11, 2005
 
 
Yeah, I would agree that it is better than nothing, and many times sufficient, but not always.  Also it is helpful when some third person/party is reviewing the "project history" to determine what happened, because the "thats not what I meant" response, given to a third party, will be met with:

a) it sure sounded like that was what you meant

and/or

b) your employee obviously thought that was what you meant, whether you did or not, a PM needs to do a better job of communicating
Scot Send private email
Tuesday, October 11, 2005
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz