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.

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.

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.

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.

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.

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.