I've been working on a project for the past six months at a client site, since they require data confidentiality and didn't want us to work at our own office.

When I showed up alone to this client site, I was told that I needed to finish the project in two months.

Since the client is not a software company, and because of various policies, it took around 20-25 days just to give me rights on my machine to install stuff like Eclipse, Tomcat, etc. Even after the delay in getting the environment setup, they were still expecting me to complete the project in the same two month period.

They did not give me any requirement documents, but since I'm working at the client site, we used to have meeting regularly to discuss the requirements.

After six months the application is still not finished, and everyone is blaming me, but they fail to realize that we have added many more features than those discussed in the first few meetings.

I've had to redo many things during this period, e.g. separate a form into two sections; a few weeks later, they asked me to merge the two forms again as it's confusing, and so on.

The scope of the application is increasing every day but they still think it's a two month project that got delayed. When I told them that scope has increased they ask why I didn't ask for requirements at the beginning.

I already work 11-12 hours everyday and travel 3-4 hours, and now they expect me to come on Saturdays also.

I have to do everything here: take requirements, design, code and test.

Please advise me what to do in such a case?

Additional details: We did have a list of deliverables, but then they added a few more things to it saying these are also important. They also changed a few deliverables. They don't even have their UAT server, they test on my development machine itself via its IP address.

  • 11
    You will actually get it done faster if you only work 8-hour days and no weekends. Exhaustion is sapping your productivity. alternet.org/visions/154518/…
    – HLGEM
    Commented Jul 25, 2012 at 13:44
  • 10
    Sounds like you are being the scapegoat of somebody Else
    – user1249
    Commented Jul 25, 2012 at 14:27
  • Could you add an edit explaining how this situation got resolved ? It may help future readers if they find themselves in a similar situation. Commented Mar 24, 2015 at 14:09
  • Where did you find your new job?
    – Mawg
    Commented Dec 22, 2016 at 15:47

7 Answers 7


This is a failure of your manager. You, as a contractor, should not have been placed into a situation with such a tight deadline by your company without a firm set of requirements up front, in writing. None of this 'they added features' afterwards nonsense - each time that happened, they should have signed off on an updated schedule that you gave them.

Your manager, since they are planning on meeting with him, needs to get from the customer a specific set of requirements - the project should do A, B, C, D, and E. And after it does, it is complete. The customer's signature needs to be on that document agreeing to that list. You should have had that from the beginning.

If your manager does not back you up and support you in this - and I don't say this very often - start looking for another job. Because you'll probably end up being the scapegoat for the whole mess. And if you are willing to work 11 hour days & 3 hour commute, it's apparent you're a very dedicated individual who deserves better.

  • When I talked to my manager about this, he was supportive. But it all depends on what happens in meeting now :(
    – ajm
    Commented Jul 25, 2012 at 4:29
  • 1
    In my experience, Programmers are very quick to blame management for everything that goes wrong... The Bold first part nearly put me off reading this otherwise very good answer. If the manager was unaware of the issue, it is hard to completely blame him (Although a good manager "just knows" whats going on no matter what he gets told). It is up to a developer to bring issues such as this to the managers attention sooner rather than later.
    – mattnz
    Commented Jul 25, 2012 at 22:35
  • 1
    I think in this case he was either placed into a situation without the necessary requirements at a sufficient level of detail being agreed to, or at the very least, without clear indication of what authority he had to deal with the customer's changes to the project scope. Both those are management issues. In the latter case, if the intent was that he would handle the customer, it should have been made clear to him that was the case and to what extent he could adjust their quotes and delivery dates for the customer. Commented Jul 26, 2012 at 6:39
  • 1
    @GrandmasterB. Almost a week after meeting, lot was said about doing things in more organized way but nothing has changed. I tried to list all the things we discussed in requirements meetings and email to clients. No one bothered to read them and instead I got this from clients "You must have wasted an hour on writing this email". :(
    – ajm
    Commented Aug 3, 2012 at 3:31
  • 1
    I'm curious to how this ended. Your client is ignorant and selfish. They don't listen to you because they don't have to. You have to make a firm statement that you can no longer work this way. So did you walk away? Or did you complete the job nonetheless?
    – Forza
    Commented Jul 5, 2014 at 11:01

The important thing in such situations is to build a CYA paper trail. Nothing should be done without having it written, especially in a complicated business relationship. Sticking to the initial schedule though they needed 20 days to even let you work is a big red flag that it will become complicated.

You hold a meeting where additional features are required? Write it down afterwards, tag "+X days to the current schedule" on each item and mail it to everyone involved. If you only use the internal mail system of the customer, additionally print it out, including the to:, cc: and bcc: recipients list and carefully archive it away. Beside that, as GrandmasterB said, the customer should sign off such changes to the original requirements.

If the required schedule can't be held, write it to them. If any change occur, write it to them, including the consequences. And so on.

This is not for "I've told you so." when the mess finally hits the wall -- they won't listen to it, anyway. This is your insurance when the customer sues you because he thinks that you didn't fulfill the contract, or when your company sues the customer because he denies payment.


From what you describe, it appears that you are participating in a classical Death March project:

In project management, a death march is any of several types of pathologic projects involving a dysphemistic, dark-humor analogy to real death marches, such as being gruelingly overworked, and (often and most especially) being gruelingly overworked for ill-founded reasons on a project that is obviously at high risk of bad outcome (i.e., project failure, and possibly threat of personal and group reputation damage). Thus the name "death march" may be applied to a project that is ultimately successful but involves a home stretch of unsustainable overwork, or (perhaps more often) to a project that any intelligent, informed member can see is destined to fail (or is at very high risk of failure) but that the members are nevertheless forced to act out by their superiors anyway...

Phenomenon is well known and there are a lot of literature about how to proceed - including of course the seminal Edward Yourdon's book Death March: The Complete Software Developer's Guide to Surviving 'Mission Impossible' Project.

Wikipedia article quoted above makes a good starting point to look for more information, research and recommendations for those involved / interested in death march projects.

Walking in your shoes, first thing I'd consider would be passing a reference to above article to my manager.

That way would let them know I am aware of what is going on, and possibly even help them guide me in terms of framework provided for this notion, like "Look, our current state is close to one described in chapter X at Yourdon. Check it out, along with closely related chapter Y etc..."

In (not very likely) case that manager is not aware about this field of study, referring could give them plenty food for thought helping to identify the situation and decide on how to handle it.


Honestly, if it's possible for you to do this, the best solution is to quit. Situations like this one are toxic for you and they rarely get better with time, no matter how hard you try.

Best to cut your losses and find a different gig. But, do reflect on your experience and take the advice from other answers on this thread.

  • 2
    This is not a bad answer, please don't downvote it without explanation. Yes, it is like cutting the Gordian knot, but judging from the situation OP described (and his desperation) this might be the best thing he can do. Work+travel 14 hours plus work on Saturdays? Sounds like your physical and mental health is at a serious risk. Commented Jul 25, 2012 at 10:33
  • 1
    By experience, this type of situation is indeed due to company culture, and will require individuals that are not currently suffers from the situation. It will be close to impossible to change such culture.
    – deadalnix
    Commented Jul 25, 2012 at 18:33
  • Why is this not the most up-vated and the accepted answer? quit++;
    – Mawg
    Commented Dec 22, 2016 at 15:51

It is a serious issue in project management. It looks like your Project Manager should work on deliverable list and prioritize them with client.

Most important, your PM should discuss and agree with Client the time frame (including design and analysis of problem/solution) in your estimations.

Having clear estimation of your work load and deliverable items of the project will relieve you from stress, As well as, add peace of mind and confidence in your work.

Try to use Agile approach by delivering your items in sprint (2-3 week) and making UAT (user acceptance test) with client. Remember, always do your sprint planning before starting the sprint.

enter image description here

Edit: From comments it is clear that this is indeed failure of your project manager. Not having proper testing and/or development environment set for a serious project like yours is a big Hole for the project and to SDLC process.

  • 2
    We did have the deliverable list. But then they add few more things to it saying these are also important. They also change few things in the deliverable list. They dont even have their UAT server, they test on my development machine itself via IP address.
    – ajm
    Commented Jul 25, 2012 at 3:52
  • These are business people. They dont understand the design etc stuff. Initially i tried to explain them this but all they said we dont care how you do it but ust do it as we want it.
    – ajm
    Commented Jul 25, 2012 at 3:55
  • 2
    +1 for Agile approach. Do it, and stick to it, by all means. Commented Jul 25, 2012 at 6:28
  • 1
    @Vain Felloman - "+1" means that you upvote the answer.
    – mouviciel
    Commented Jul 25, 2012 at 7:41
  • @mouviciel Yap. didn't I? As far as I can see I did.. Commented Jul 25, 2012 at 9:20

While I agree that this is a management failure, it is also a failure on your part. At this stage it will be very hard to fix, so some of what you need to get out of this is how to handle future projects.

First, you need to insist ona a requirements baseline document at the start of the project. Doesn't have to be fancy or formal, but you cannot successfully build anything until the client specifies what is expected. If you don't have this in writing, the chances of the customer being pleased with the end result are aproximately 0%. So this is critically important. It is also your job to look for the ambiguities in this document and get them cleared up as soon as possible. When you come across one of these and you aren't sure how to interpret it, don't make a guess as to what you think it means, make sure you and the client are on the same page about what it means. Yes this means more talking to people and more meetings and less coding. But it takes much less time to clear up an unclear requirement than to code it wrong and then have to recode it. Further, you often have to give them the re-coding for free and that is not good for the company you work for.

Next, you tell them how long it takes to do the work and that sets the deadline. You do not ever accept a deadline that is based on anything other than the amount of hours it will take to do the work to meet the requirements. If you do, you will be in a death march again. Show them how the deadline is not possible to meet by having a detailed explantion for the hours it will take. You can't fit 200 hours of development time into a week with only 1 developer no matter how much the client wants it. At that point when the deadline is immovable, you ask what items should be moved to the next iteration.

Do not forget that devlopment time is only a small portion of project time when doing project time estimates. You also have to account for meetings and email/phone communications, testing, deployment, documentation, physical set-up of servers, workstations, software. Further, in planning the deadline, you can only assume that you have 6 hours a day available not 8. This is to account for leave, bereavement, sick time, unavoidable delay (such as when you had to wait for them to get you permissions on the network etc.), training, non project-related work (time sheets, HR meetings, etc.). One of the biggest reasons why people don't meet their deadlines is that they make the assumption that they will be only doing development and working 8 hours solid at it every single day. This is simply not a realistic assumption.

And every time they add another piece on, you tell them how much longer it will take and how much the additional work will move the deadline. You don't ask to move the deadline, you tell them that is is moving due to the new requirement. Now you should go through your manager for this, but it is first of all your reponsiblity to make sure your manager knows every time the requirement is changed and how much that will add to the project. Make sure all of this is in writng, so you can defend yourself if need be.

Next, do not allow yourself to be abused into working 11-hour days and weekends. This is OK in short spurts (Of less than 1 week every six months or so), but for the long term this is simply not acceptable. Tired people code slower and they make more mistakes. You can get more done with higher quality working regularly 8 hours than regularly 11 hours. and weekends.

  • 1
    Thanks for the reply. Very good points for me to look into.
    – ajm
    Commented Jul 25, 2012 at 14:22
  • +1 for "You don't ask to move the deadline, you tell them that is is moving due to the new requirement." This points out that the deadline is not something you made up, but an intrinsic property of the project.
    – sleske
    Commented Jul 26, 2012 at 7:02
  • 1
    you need to insist ona a requirements baseline document at the start of the project, Next, you tell them how long it takes to do the work and that sets the deadline., And every time they add another piece on, you tell them how much longer it will take and how much the additional work will move the deadline. Great advice but being in such a situation once I was fired in less than a month for being impossible to work with apparently. The real situation is how others put it, these kinds of companies want scapegoats and excuses, not productive realistic software developers.
    – maple_shaft
    Commented Jul 26, 2012 at 12:44

I've found Gantt Charts can be very good in these kind of situations. They can illustrate to clients the current schedule and can be useful in illustrating the effect of adding in any new features/changes. Sometimes telling a client that feature x will effect the delivery by y days doesn't register with them. By having it clearly on a graph they can grasp it better.

Ideally this should be done from the start of the project. It might not be as useful to explain the "delays" up to this point, but might help with the project going forward.

From Wiki:

Gantt charts illustrate the start and finish dates of the terminal elements and summary elements of a project.

  • If this answer is being down voted, please let me know why. Thanks.
    – AidanO
    Commented Jul 25, 2012 at 15:17
  • 1
    +1 - Gantt charts may be old school but it sounds like the client is not buying into the project so something as simple as a Gantt chart may show them the effect of their extra requirements.
    – dave
    Commented Jul 26, 2012 at 1:14

Not the answer you're looking for? Browse other questions tagged or ask your own question.