How do I push back on an impossible scope?

Oh, you're new? With utmost respect to you, I'd say you might want to quit trying to be Superman (or Supergirl), for starters.

The whole conversation on killing off licenses for the third party product has predated your employment by a long, long time. It's gone way up the chain. Your manager and others have decided to take on this project, and have nailed it into the ground with the stakeholders that the things are gonna be what they're gonna be. Now, here comes you. Whether you are 100% right or not, nobody's trying to hear you because of all the promises that have already been made, and you're the FNG (NG = new guy / new girl) so the instant perception is going to be that you don't know what you're talking about.

I have seen this play out SO many times.

What you do right now is shut your trap. Decide how YOU are going to deal with the situation, and be effective for YOUR own sake in your OWN life. You can't save them. Allow them to carry out this course. But make boundaries and a routine for your own life so you don't get trampled when their short sightedness doesn't work out. Come in to work every day. Take ALL your breaks. Arrive on time, and leave on time. Use your vacation and PTO in reasonable fashion. Entertain yourself in your free time and make sure you have a healthy lifestyle outside of work, and something in your personal life that gives you a sense of accomplishment (as you will not get it from the job!). As you work, lean on your boss as often as is reasonable to make priorities clear, because I guarantee you there will be a point where there are ten things that folks will tell you are all priority #1. Overall, don't lose yourself in the madness.

There will be shortcomings in the plans. You might document them as you observe them, but only escalate the ones that block you from doing work. Other than that, relinquish the idea of fixing an idea that was broken long before you got there. Get your money from the work you do on the job each day, and GO HOME. Heads may roll. Allow them to do so, because misplaced ambition is going to put you in the crazy house right now if you do not.

Best of luck.

My question is: how can I communicate this effectively to my boss, who is also the more experienced developer on the project? He does not understand there is an issue with the timeline.

How are your timeline expectations so different? I would assume the two of you are sitting in the same technical meetings, hearing the same feature requests, and thinking about the timelines together. I totally believe that you could have way too much on your plate, but what's causing him to think you don't?

• Is he simply an optimist?
• Does he know you have extra tools that will make the process quicker?
• Is the "must have" list in his mind smaller than in your mind?
• Does he view the deadline as a moving target, and if you're only able to replicate 2-3 of the big features by EoY that's enough for him to consider it a success?
• Does he know company management better and is aware that under delivering on new features is still going to be seen as a win instead of a failure?

Figuring out what's causing him to be less stressed about the timeline is step 1. It could be he knows more than he's telling you (about technical matters, expectations, etc). Or it could be he's actually just a pie-in-the-sky optimist promising the world and is setting y'all up to underdeliver (a first in software development lol).

Once you've figured out why your expectations are so misaligned, then I'd say following Hilmar's advice about how to manage scope and delivery would be useful.

Fact: There is a huge team somewhere creating this software that comes with a very expensive license. Fact: Your company thinks it can save money by creating a replacement for this software. Common sense: If you could do that then anyone could and the supplier would be out of business.

Since you are posting on “workplace” and not “software development”: It is clear that you won’t succeed. So it is pointless to try too hard and stress yourself and wear yourself out. To make sure you get paid for the longest possible time, make optimistic noises, tell them “this will take longer”, not “this cannot be done”. Drag it out. Ask for a raise. If you get it, good. If you don’t, it makes you feel better about eventually failing. And at some point look for a job elsewhere.

As the more junior dev on this team, you have very little you can say that will have any real effect, especially since your boss seems to be ready to tackle this project.

If you were still talking to the upper managers that deal with the costs during the planning stage, I might suggest asking them financial questions, instead of technical questions. Upper management typically responds better to that than technical questions/situations they may not understand.

• If we fail to meet the deadline, how much is this going to cost the company?
• Is the cost of the license worth +4 months of our development time, including the time we could be working on something else? And including the time of all the planning meetings?
• Is it worth the cost of having to keep maintaining this project until it's no longer needed and the other team sunsets the project that requires it?

I'm sure you can think of similar questions to ask, but as a junior dev (at least on this team), you may not have the authority to ask these questions in the first place. And it may already be too late to ask them now. However, it might be a decent gut check for them, still, prefacing the question with "With all the time and effort we've already spent on this and all the time we know it's going to take to accomplish this project..."

But if it's too late to do that, then @Hilmar's answer is really good. Because what that does is it gets rid of the "feeling" something is not going to make deadline and instead states the schedule as a certainty, and then you can say "for sure" whether this is going to meet the deadline, or not. Don't guess at large projects, break it down to pieces, and depending on if the pieces fit or not, you have your answer. Maybe the other dev is a better project manager and can estimate better than you can. It sounds like you don't know. I sure don't. So, work with them to actually set a schedule and plan this out.

I know I like to think that I'm good at estimating projects, with my 16+ years experience as a software engineer, but I have to admit that I'm wrong more times than I'm right, at least with the larger projects. Sometimes I estimate too much time and sometimes I estimate too little. And sometimes unexpected things come along that no one could have expected to put you behind schedule. And, just to be complete, maybe there's something that ends up being easier and speeds you up (maybe 1% of the time IME).

I try to under-promise and over-deliver. So if I think a project will take 2.5 months, I say it'll take 3 months. It's sort of like the so-called "Scotty Principle", but not as extreme. So, you plan it out and then give them an expected date that's 10-20% longer than you expect. Or, since the due date is set, tell them you can do 10-20% less than is expected to be done by then. Remember, your expectations of how long a task will take is a guess, not a hard number written in stone where at the end of that timeframe it'll definitely be done. An hourglass might have an exact amount of time for it to finish, but software development sure doesn't.

About the only thing I'm sure about with your situation is that you are likely too far into it to be able to easily convince anyone of backing out now. The whole "sunk cost" fallacy, and all that.

I see 3 major options here:

• Do the work and see where things fall, and hope you can get the work done so you can keep your job.
• Overwork yourself to make sure you hit the deadline, and then deal with burnout and future unrealistic deadlines, while hoping they fire you.
• Start looking for a new job now and see where things end up.

No-one else has pointed out that the senior staff may well know something you don't. This could be company politics, but it could also be development skills and knowledge.

Once you've got sign-off that the list of must-haves and won't-haves (and anything in between) is carved in stone, make time estimates for the sub-projects.

Ask the boss to review the list and see if they would find some stages of it to be a lot easier than you're thinking. He may be able to tell you about a new tool to use, or a new C++ class or library to use, or some such.

They may also be able to clarify whether they're simply expecting a lot of overtime on it, which is taken for granted in many environments. I've worked huge amounts of unpaid overtime and learned a lot while doing so, in some cases, and in others had my approval rating skyrocket. I don't regret a second of it even looking back from my late 50s.

Some seem to be cautioning to keep your concerns to yourself, but that's the last kind of coworker, team member or underlying I'd personally want. My career has always involved people from previous jobs and you want to be seen by them to have done the reasonable and prudent thing, and they'll want to rope you into the next company they work for. Just sitting and smiling while Rome burns isn't a trait that people will recall and try to hire you in a few years. On the other hand, it's always a battle to not be seen as a complainer or overly emotional either. I also would be careful not to give negative opinions of your boss or coworkers, etc., as that's not an attractive trait today's coworkers will be looking for the next time they're at a company that's hiring. To the extent you discuss your projects and work with coworkers (and I do all the time) it's up to you to spin it as: "the project seems to be pretty big, but the boss is pretty sure I'm being pessimistic, maybe I am, they probably know better than I do, let's see, I'll do my best."

How do I push back on an impossible scope?

To be more clear than some other answers, given the various circumstances you've described, I don't think you can. Here's why:

My question is: how can I communicate this effectively to my boss, who is also the more experienced developer on the project?

If your boss is also your lead developer, on a 2-man team, then any "voice" you have to management will be joint with your team, and that team-voice will be highly overweighted by your boss/more-experienced/lead-developer person. They will be speaking for you as a team. The only interaction available to you is within that team.

So the best you can do is to get a shared outlook on the scheduled timeline with your lead developer. Yes, if it hasn't happened yet, nag him for a documented list of features and estimated work schedule for the project.

I've had earlier a meeting with the department that will use the product, they definitely need some features that we thought we could deliver in v2 initially. He was not present in the meeting (holiday).

This sounds like the true scope may be undocumented and unknown to your lead, which is a bad sign. So the two priorities, and really the only two things you can do, as a team, are:

1. Document the list of features required for this phase of the project. This should be relatively easy; if the list is out-of-synch with any stakeholder expectations, it should be made transparent and resolved between those parties.

2. Draft an estimated work schedule. This is the harder part; your lead's estimates will most likely override your own if you have a difference of opinion. But that's not something you can control. Proceed with their estimates and check-in and revise the schedule as needed (likely biweekly or so).

I worked for a company where the CEO was notoriously bad and estimating the time to complete projects. For example he wanted a online version of our product and estimated 3 months. After one month he decided AWS wasn't good enough (or too expensive) so we were doing our own servers. After two or three years we had something.

So what will happen in this case? After the company puts half a year into a project they don't want to give it up. The project will be continue and takes as long as it takes.

There is an opportunity in this in that if you can finish the essential functionality in some manner so the can cancel the license on time, it will look very good for your team. Identifying the minimal subset and putting it in place is your best location for your efforts.

However if you don't succeed they will simply have to extend their license a year while you do get this functionality up and running.

The non-essential stuff will still be wanted so that will end up as your work going forward.

I echo other sentiments on working a normal schedule as much as possible and not burning yourself out. Overtime for short periods to meet an important deadline is fine, but continuously working overtime to meet goals that were not realistic is a bad idea for most people.

I get the motivation for a simpler software tool and the desire to stop paying annual/monthly charges per seat or per site for functionalities that are irrelevant to OP's organization. I have a similar sentiment vis-à-vis the many redundant features of AutoCAD/ProE/SolidWorks for people designing items with the same general shape.

But it seems that you adjudge your company's challenge to be too much for the human resource and time allotted to it.

Previous answers suggest various coping remedies if you decide to stay with the present organization -- or if your circumstances are such that you cannot move away at the present period.

But since IT is a growing field and jobs are generally fairly available, I would consider looking for another job. Of course the new job will not be a cakewalk. But it might well be one that will not be hopelessly unachievable in the time/human resource allocated to it.

There is more to life than work.

What management and/or the technical leads are traditionally supposed to do in "waterfall development planning" is to break the task up into smaller pieces, repeating this until they get to pieces simple enough that one can make a conservative estimate how long each one will take and how many people it will require. Then reassemble this, keeping track of which of these tasks depend on which others, and look for the longest path; that is the minimum time it would take if you had infinite manpower.

Then start assigning people to this, realizing that you do not have unlimited resources and some things are going to have to wait for people to become available to work on them, and move things later as necessary to fit that practical limitation; this will push the completion date out. Remember to allow for people not being available due to getting sick or going on vacation. Remember to allow for the fact that everyone has other duties and will not spend 8 hours a day every day working on this. Remember to allow for unexpected difficulties or changes in requirements. (Even for a simple task I usually find I need to double my initial guess to get a realistic estimate; as the size of the task goes up, so does that multiplier because there are more unexpected interactions.)

There are tools and techniques to help organize this exercise, such as GANTT charts.

That will give you at least a sanity check on whether it is vaguely possible to deliver the complete solution by a given date. It is usually not very accurate, but it provides sone warning when you have clearly bitten off more than you can chew.

The better solution is to start by determining what the "minimum deliverable product" is, trimming away everything that is not absolutely necessary for the product to be worth sharing with anyone else. Go through a similar exercise, and decide when you can deliver that. Do so, and then continue to deliver incremental improvements whenever you have added enough function to be interesting and have the code in stable enough condition to release. That lets people start testing it, using it, and benefiting from it, long before it would have been complete under the waterfall model. Basically, don't let the perfect become the enemy of the good enough.

As a developer, it is not your job to be responsible for time, budget and money. That's the responsibility of a project manager or product owner, which you are not.

For you that means: do not make commitments that you are not sure you can keep. This usually means no more than a few weeks in the future (like 2 or 3 weeks). Try to tie down what you will be delivering in this time span, and try to avoid getting that short schedule (let's call it a Sprint) mixed up or heaped onto all the time. If something is not well specified, you cannot commit to doing it, obviously, so you should make clear what the unclear parts are, and make clear that there is no commitment.

Do not tell them what you cannot do; but do tell them very clearly what you can and will do in the next few weeks. Make 100% sure that you yourself know what that is, and that you know everything you need to know about it before giving that commitment.

If you have no project lead, as it seems you don't, then your disciplinary manager is the person you should send stakeholders to if they keep forcing you to change what you're doing.

Go read the Agile Manifesto and specifically the Scrum guide. The first is a very generic bunch of ideas about how to develop software in the modern days; the latter is a very concrete collection of processes and roles (and there are others of course), it is a concrete framework for software development (or other projects). Even if you do not do actual Scrum in your company (which it seems you don't), you can still take ideas and inspiration from there. Even if you do not do exactly as they say, try to structure your work and your communications with the stakeholders and bosses along those ideas.