I was hired as a frontend developer to develop an administration backend for a thriving European startup. The initial estimate that they had in mind was 6 months, which was appropriate. It's a 3-person team consisting of the CEO/Owner, a Backend developer, and a Frontend developer.

Right after I was hired, they asked me instead to focus on making tests for their application. This required substantial structural changes to support the testing framework and took me around 2 and a half months.

The administration platform as originally envisioned was of the "live editing" type, so at this point I created the components that lived inside the frontend framework that would support this functionality. This, together with me becoming the sole administrator of the test harness I had developed, took me around 2 months.

Then, the scope changed and it became a full-blown administration panel. In terms of structure, this is substantially different and requires a separated platform. Developing the base for this, and maintaining the prior work I had done, took me around 1 month.

Fast forward 6 months, and we're not even close to finishing the project I was hired to do. We only have a base, at most, and they are becoming very anxious. They became more "hands on", asking for daily standup meetings. They also started to distrust my recommendations, taking the project in directions I don't think should be followed, but I'm not saying anything. They also asked me to lower my hours, and to deliver faster, and have lowered communication with me.

As I'm a freelancer that receives ratings and reviews for work, I can clearly see that they are becoming frustrated, and I'm doing my best to help and cooperate, even if given my experience I can see that the project is not going in the best direction, but I'm afraid that given their bad experience with me, they'll give me a bad review and that'll lower my reputation, so I'm trying to be compliant. I feel like just following their direction blindly will hurt the project more, in turn affecting me even more.

Is there a way I can turn this situation around?

  • 32
    What does your contract say about the case when the scope changes? If your original scope was for 6 months and now the scope is far larger, it's not you to blame. – Juha Untinen Jun 6 '18 at 17:10
  • 1
    We didn't specify. It's an ad-hoc contract and we just had a meeting before starting. I am working by the hour for them as a frontend developer, that's as much as our contract says. The rest is verbal agreement. – ajf- Jun 6 '18 at 17:12
  • 22
    So the software is NOT ready, and NOT because of you not being able to test it, but because of their request to remove 1/2 of the developers from development. How is that your problem? – Sandra K Jun 6 '18 at 17:25
  • 14
    Just curious as to where they are going to give you a bad rating – Mawg Jun 7 '18 at 7:28
  • 2
    Sounds like you were hired as a dev not a manager and this is a big project management problem. Whilst you should always make potential problems known about (you are the expert after all) if you aren't the project manager then management failings aren't your fault. – mattumotu Jun 7 '18 at 12:09


Every time there is a change of scope do the following:

  • Document the change.
  • Show the effects this will have on your work
  • Submit a new timeline
  • Have the stake holders sign off

Scope creep happens, but the only way to avoid being the one who gets the blame is to document everything, demonstrate the effect, get people to sign off so that you have a paper trail

  • 2
    @AlainJacomet It's you're only option. They're going to like the project dragging on with no end in sight and with no reasons why a good deal less than having the details laid out in front of them. It's the professional thing to do. – Retired Codger Jun 6 '18 at 17:45
  • 1
    @Alain Jacomet too late. Fingers are already pointed. What you can do is try to understand as much as possible and be flexible, but say clearly that you can't work more than you can sustain. – Cris Jun 6 '18 at 19:59
  • 7
    Also, just to extend the answer, don't jump the gun. Don't start developing things that have not yet been finalized in a document or are nothing more than an idea that is floated. Don't work on a document that can change mid development. When I start a task, I take a local copy of the document to prevent this from happening. Any changes made need to be explicitly reported/documented or I won't respond to them. This effectively requires others to document things (that relate to you) as well, which extends the idea of documenting everything yourself. – Flater Jun 7 '18 at 6:23
  • 6
    @AlainJacomet: The best you've got is a step-by-step replay of events to explain why the deadline moves up. For example: (1) You wanted [this]. It was going to be done by [then]. (2) You then said you wanted [that]. This adds [time] to the deadline. (3) You then changed the development towards [those]. It will take at least [time] to change the existing code to fit that (and so on...). This clearly proves that the deadline changing is related to them changing the requirements. You need to make that connection clear to them. – Flater Jun 7 '18 at 6:27
  • 16
    Submit a new timeline This is the most important part, every time you are tasked with doing something differently or new, adjust the timeline/deadlines and make it clear to the stakeholder what the repercussions are. – Polygnome Jun 7 '18 at 9:16

Mea culpa

I think @Neo's answer is on the right track, but I disagree with the implementation. Consider

Since I've been here, I've made a few mistakes. One of the first big ones was that when you told me to develop a test harness for the application, I didn't insist that we scope that change. At the time, I simply agreed that a test harness was a good thing and moved forward with that. That took two and a half months. Maintaining it has also cost X months.

Not realizing that mistake, when you told me to change from "live editing" to a full blown administrative panel, I repeated it. I did not insist on scoping the change. We spent another month making that change.

I can't keep making the same mistake. From now on, expect timeline updates every time a change is proposed. Here is the situation as things stand today...

Then explain how long it will take to finish your current set of tasks under the current requirements. If they are proposing new changes, explain how they will change that timeline. Also explain what happens if you do not make those changes now and instead make them later. You can even do that with changes that they've requested but that you haven't implemented.

I'm going on what you said here, so I may be missing parts of the timeline. If I am, make sure that you write those parts out for them (we don't really need to see them unless you need help talking about them).

The advantage of this approach is that it involves you taking blame. Presumably they agree that you've made mistakes, so you're starting from agreement. And it doesn't point fingers except at you. It highlights problems and eventually moves to solutions.

Don't forget to include the ongoing maintenance of the test harness in that. If that's taking up half your time, then tell them so. They can either shift work away from you (either front end or test harness) or they can live with a longer timeline.

If you don't tell them the reality of the situation, then you will continue having the same problem.

Moving forward

When I read this, the thing that really leaps out at me is the test harness. That's two and a half months out of a six month scope even before maintenance. That's why I said X. I don't know what X is, but it sounds like it was important. If you spent even half a month on it since then, it became the majority of your first six months and possibly the majority of your time there if it was more. You really need to quantify that.

Figure out how much time it would take to do the original project from here. Maybe with some extra bells and whistles that you've already added. You don't need to take things out. But if you didn't add anything else that wasn't in the original requirements, what would your timeline be? Then show them how any newer requirements affect that schedule. Then show them how their current suggestions would impact the schedule. You never need to say no, but tell them how much time they're adding.

They can either have Agile or Waterfall. They can't mix and match. Agile accepts changing requirements because the system always works at some level. So all requirements are either in the current sprint or they don't exist. Waterfall tries to schedule the whole project at once. That means that any time requirements change, you have to change the whole schedule. In theory the project manager should handle that, but in practice if that's not happening, then that is part of your responsibility as a contractor. You need to manage your schedule.

Also consider the possibility that some work you are currently planning on doing in the front end could be done in the back end instead. If so, you should quantify how much of your time it would take. Let the back end developer quantify how much time it would take to code in the back end. Let the manager choose where it would be better to do it. Even if it takes longer in the back end, it still may make sense to do it there if you are further behind and the back end developer is currently waiting on you.

It's possible that the back end developer should take over the test harness. If there's only two developers and it's taking too much of your time, there aren't many other options. And you would be far better off if you could focus on your original project. If the backend developer has been waiting on you, then this gives work to do in the meantime.

  • 12
    This answer gets my vote. The other answers say a lot of good things about how to prevent the scenario described in the question from occuring in future, but this one does far more to explain how to proceed right now, to get from the current scenario to one where the other answers can be applied. – anaximander Jun 7 '18 at 11:00
  • 2
    With more bids (each with independent estimation error), it is more likely that the buyer will pick one which under-estimates the effort required. More bids (be they more than one bid on one problem, or bids on a set of problems) means a higher load factor to account for that. But +1, this is well done. – Yakk Jun 7 '18 at 14:03
  • 1
    Along with taking responsibility for your actions, you're relieving the implied blame that they might not even be aware of. You make it easier to take responsibility for what they've done; it tends to encourage the other parties to "let their guard down" – theGleep Jun 7 '18 at 14:14
  • 1
    This is great. As anaximander said, not only does it address avoiding it in the future, but it gives an immediate action for improvement. One thing you bring up that I want to expand on is the idea of Waterfall vs. Agile. You touch on it, but I think that switching to Agile (or an Agile-like system) would be a major step for improving the current situation. It gives them more control, transparency, and feedback on project status. I added an answer to go into this more in depth. – Jonathan Jun 7 '18 at 18:43
  • 2
    @Brythan OP should consult a lawyer before taking on any blame. depending on the contract and the country this can have serious ramifications with regards to contractual penalties and liability in the case of the clients loss of profit etc. due to OP missing the deadline. It is more prudent to not play the blame game and remain neutral in stating circumstances leading to the current situation as well as presenting immediate solutions. – DigitalBlade969 Jun 9 '18 at 21:40

Is there a way I can turn this situation around?

I think your in a bit of trouble here as it doesn't appear to me you have managed their expectations.

The best thing you can do this late in the game is document the entire scenario including the time line, just as you have with us. Sometimes customers have short memories and only recall the immediate (now) or short term past. I doubt they recall what they asked you to do several months ago.

Remind them

Make sure when you spell out the work, you note each and every decision that caused you to have to dramatically modify the architecture.

Beyond that, I am not sure what else can be done.

For your future

Make sure you document everything you do, and if you have a change request (change in the original statement of work), be sure to document the change and the impact to the timeline.

  • 7
    No one likes a person that starts pointing fingers and saying "it's not my fault" when things are on fire. If anything, I would like to do something that is productive. – ajf- Jun 6 '18 at 17:14
  • 12
    @AlainJacomet I am not suggesting finger pointing at all, just outlining what has been agreed upon and the impact the the changes the client have asked for have caused. What other option do you have at this point. ( Damage control if you will ) – Mister Positive Jun 6 '18 at 17:16
  • 3
    Damage control does sound appropriate, maybe in conjunction with the other points you outlined. – ajf- Jun 6 '18 at 17:27
  • 1
    @AlainJacomet Been there, done that. I could not find another way to salvage it in my case. – Mister Positive Jun 6 '18 at 17:28
  • 1
    @AlainJacomet A small correction. No one likes a person that argues "not my fault" when things are on fire AND when that argument is pointless. For example when it's obvious whose is the fault or it's everyone's fault. But if you argue "not my fault" and it is truly relevant, it doesn't really matter that someone will be aesthetically opposed to that. – kubanczyk Jun 7 '18 at 15:29

but I'm not saying anything

Isn't that a large part of any developer job, especially freelancers ?

Your managers are not developers, they can't tell heavy requirements changes from lighter ones, nor good (from a developer viewpoint) directions from bad directions (They still can have good marketing reasons to try those directions for example).

Every time you are discussing new things to do, you have to tell them how much time it will take (or how unpredictable this time is), even if they don't ask.

  • Exactly! The asker appears concerned about timeline and budget. Someone who has any responsibility in these topics cannot hope to achieve a good outcome in them without offering guidance. – Dennis Jaheruddin Jun 7 '18 at 7:46

You need to do damage control because in my opinion a lot of this is your fault.

You should have managed the changes faster or made sure it was clear that the 6 months would no longer apply if they wanted something else done. Instead you just collected money while watching the timeframes fly away.

Is there a way I can turn this situation around?

Option 1: Do the work and stop messing around.

Option 2: Inform them of reality based timeframes, reasons why the original will not be met and go forwards from there. Intelligent people will understand, they may not be happy or impressed but they'll understand.

As a freelancer your reputation is your biggest asset, you need to be better, more organised, faster and more professional than normal to build a reputation, sometimes this means working a few extra hours gratis in pressure situations.

  • Comments are not for extended discussion; this conversation has been moved to chat. – Masked Man Jun 8 '18 at 14:02
  • 1
    @Jon The comments have been moved, not deleted. We don't have the option to selectively move them. Extended discussions in comments will almost always lead to the full set getting moved. We could selectively undelete some of those comments, but there should be a strong reason for it. Moreover, there should be no expectation that comments will remain forever. The pop-up suggests leaving a comment to improve the post, not to explain the downvote. The OP clearly saw the suggestion, and chose not to change the answer. The comment is thus obsolete. Not sure why you want it to stick around. – Masked Man Jun 9 '18 at 8:13

To put it bluntly, if this is your fault, you will end up either taking the hit to your reputation, or your wallet.

As a professional you are generally expected to be able to provide reasonable estimates for how long work will take, and to notify your employer straight away if the timeline stops being realistic.

I am not saying you are solely to blame, but if there is something that you really should have told them 4 months ago, then you made a mistake that is costing them. And the longer you stay silent the worse the situation becomes.

That said, as I understand there is already a Frontend and Backend developer on the team who should also have a reasonable idea of the impact of scope changes. So it sounds like everyone is panicking and squeezing everyone else, or maybe they just trust each other more than they trust you so they are squeezing you.

One thing to remember that a lot of the time when everyone is stressed, people get totally out of sync and completely misinterpret what others are doing. For instance, maybe what you see as being "hands on" is them wanting to get on top of stumbling blocks quickly, and what you see as "lowering communication" is actually just everyone being in a rush. By the same token, they may be taking things you do the wrong way. The solution to these problems is COMMUNICATION.

What I would do

This is based on a number of assumptions I'm making about the situation so adjust as necessary.

First, I would quickly come up with a realistic timeline for the project on paper, and figure out the maximum time you can work and the minimum money you will accept if the alternative is losing the job and a very bad review. You need these types of figures in your head because things may quickly blow up into a negotiations process. And figure out if they are more worried about the budget or about the timeline if you can.

Then go in and say "Guys, this project is obviously stressing everyone. Can we just take a step back and have a calm discussion about it? I want to understand and maybe contribute to how we are going to approach it from here."

If they refuse, then tell them that although you'll continue to give your best effort, you can't fulfil the expectations they have of you right now as there is too much work and not enough time.

Otherwise, you can have a discussion with them about the project. Don't be confrontational. Stress that you understand there are complex business pressures and the ultimate decisions are up to them, but present what you think is the best course of action from your viewpoint. If they throw you a curve ball (e.g. a feature that you are unsure of how much time would be needed) tell them you will have to look into it before you can confirm that it is realistic.

Most importantly, present solutions, not problems. Instead of "I wasn't told about blah", say "Could you please inform me about blah in future?"

  • 1
    The reputation would be hit, exactly in who's eyes? Lots of developers have seen badly managed projects so they would recognize one if they even hear the first few symptoms of it. – mathreadler Jun 9 '18 at 11:25
  • @mathreadler "Oh don't hire that freelancer. He told us it would take 6 months to do our project and it really took 1 1/2 years!". Most freelancers work for clients and not directly for other developers. The first thing a freelancer should learn is that they're not just a developer. – Voo Jun 11 '18 at 8:20
  • @Voo you could easily respond to that by "well the requirements were continually changed, so of course estimated time to finish changed as well" – mathreadler Jun 11 '18 at 8:23
  • @mathreadler Apart from the developer not informing the client about that time frame change before implementing it (a mistake that has been discussed in detail so not worth going into), the point is as a freelancer you live by word of mouth. If a prospective client talked to your ex-employer and heard the above sentence you would never even get the chance to tell them that, because the client would go to one of the dozens of direct competitors. – Voo Jun 11 '18 at 8:27
  • @Voo does a client just assume that changes in requirement does not cause changes in estimated time to finish? Well I guess they had it coming then... – mathreadler Jun 11 '18 at 8:33

You wrote, "We didn't specify. It's an ad-hoc contract and we just had a meeting before starting"

This is your root cause. There is enough work out there that any hit from this project will cause only slight issues for you, IMO. Further, many companies also understand how this came about and not blame you for it.

Remember, while they have leverage over your reputation, you have leverage in that they've spent a great deal of money and time on this and would spend more on someone else. You've learned your lesson also in planning. 80% of a project should be in planning, and 20% in implementation.

You've learned your lesson about using a good contract in contract work, and as long as you meet your contractual obligations you shouldn't need to worry about your reputation. Indeed, as long as you meet your requirements they are at peril if they give you low marks or review.

In short, create a good contract and do real planning meetings! You can recover from this, but now you need to do it the correct way which is to protect yourself and your client by using a contract and a real step-by-step-by-step-by-step plan that covers everything from the overall idea to the exact placement of window elements.

Still, in my experience I would consider this a good lesson learned and look for a fresh start elsewhere, taking my lumps in stride.

  • Or adopt a more agile methodology and avoid the planning step but replace it with constant communication cycles. – Tim B Jun 9 '18 at 21:38

I'd like to expand on Brythan's answer a bit. One of the points brought up, but glossed over, was the use of Waterfall or Agile. From your description, I seriously doubt they're using Agile, and from the description of their company, they probably don't even know what it is. I'm going to write my answer out assuming whoever reads it is not familiar with Agile (or Waterfall for that matter). At the very least, it might be helpful in explaining to the company what you want to do, since Agile can be complex, particularly if they're used to Waterfall. Which if you're not familiar with this term, Waterfall is the old "plan out everything at the start, give the whole thing a time frame, and pray nothing goes wrong and that you've been accurate with your guess as to how long it will take" method of managing a project.

In the example of what to say in Brythan's answer, I would change the closing paragraph to something like this:

In an effort to avoid this situation in the future, and to bring more transparency to the project, I would like to propose the following:

First, every two weeks, we would have a meeting to decide what needs to be done in the following two weeks. I'll provide a list of tasks that still need done, and we can decide together what the priority is, and what I can reasonably accomplish in those two weeks. At the end of the two weeks, we would have another meeting to demonstrate what has been completed so that you can sign off on it.

Typically the process of splitting a project up into "tasks" (or User Stories as Agile calls them) would be done by you and the project manager, but you might have to handle that yourself. Split them up into pieces that can be completed in two weeks or less. And at the end of those two weeks, each task should be something that you can demonstrate to the company as a fully working component. Sometimes what you create isn't something that you can actually deliver standalone, but even then, try to figure out some way to display the functionality. The idea is that they see progress.

In addition, I would like to have a daily meeting, of no more than 15 minutes, to discuss daily progress. This way you can always know exactly what the status of the project is, and if any issues come up, they can be addressed immediately.

This is a very basic implementation of Agile, but it's a vast improvement over Waterfall, and gives the project owners immediate and continual feedback as to where the project is.

  • waterfall would be much much better for them - as it appears they don't exactly know what they want and large changes, even using Agile, in a limited time constraint never works. Waterfall would have made them think up front, and this is what is really missing. – gbjbaanb Jun 8 '18 at 18:00
  • 2
    @gbjbaanb that's wrong. Agile would actually be much better for discovery and understanding. OP's problem is that he/she did not update them on time it would take to get things done as they changed expectations. Waterfall would have just guaranteed that the people who hired him were unhappy with the product. Really, this is just an unfortunate mistake with agile. – Steve Jun 8 '18 at 19:50
  • @Steve for a 6 month project, knowing what you want is more important than being able to adapt to change - you don't have enough time to change in that timescale, given what the OP said. Of course, if you're paid by the day.... but this seems to be more freelancer paid by the project. – gbjbaanb Jun 10 '18 at 22:40
  • 1
    @Steve sure, but as a freelancer, your job is to build what they ask for, that's what they pay you for, and if you build something else, there's the chance you won't get paid (even if it is what they wanted). Its up to them to sort out what they need, and can re-hire you to do it again if they choose. – gbjbaanb Jun 13 '18 at 13:11
  • 1
    @gbjbaanb You're right, but that wastes considerable resources. I feel like agile is a better approach. I guess this is why we write functional and object oriented code though. – Steve Jun 13 '18 at 13:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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