Many organizations have common characteristics in this regard. First, they don't expect you to be on time. Sales may think you're going to launch on time, but it's in their financial interest to think so. The rest of the org probably made a schedule they know you can't meet because they think it motivates you to work harder.

Second, unless you're in a startup where everyone's inexperienced, most people probably already know you'll be late, but aren't saying it out loud. They likely have discussed it (up the chain) in meetings you're not in.

Third, people do shoot the bearer of bad news. You can earn a rep as a negative person if you make _true_ predictions out-loud that don't fit the common desire. This is especially true if some of the senior people who know (like your boss) haven't been forthcoming with their bosses.

Have a quiet conversation with your boss over lunch or beers - not a meeting - and tell him/her what you think. Be prepared with details, but if he/she doesn't ask for them, don't provide any. There's a good chance he/she already knows as you suspect.

Even more casually (lunch/beers), express your concerns to the project owner. It's probably not new news to him/her either. Being "positive" is a huge part of the corporate game.: Again, if no details are asked for, don't provide any. Shift the conversation to the weather or the world cup.

You're now down. Go back to work.

Next step, is to spell this out to your project team leadership completely unvarnished. Tell them your conclusion and how you got there. Don't let them bargain over your reasoning unless they actually have better evidence. The key is to never say "this is too hard" or "we don't have enough people" or make any other excuses. Not should you be overly emotional. Just give the facts. It's a fait accompli.

Then just ask how they want to deal with it. There is absolutely nothing to be gained from beating around the bush. I've done this more than once and was always taken seriously. One time we had even already signed a fixed-bid contract before I was able to give them an estimate. What you've committed too doesn't change the course of what's actually going to happen.

You had leaders who were willing to listen to facts rather than prioritize consensus (which brings with it the belief that because you were the dissenting voice in the room demonstrates you're divisive and a problem).

You landed in a really good culture, just one that hadn't faced reality yet. You've yet to plumb the depths of corporate America. :P

Here's the crux of the matter. Your approach needs to be tailored to the culture you're in. The higher up in the leadership chain you go, the more important your understanding of the political machinations of your company is.

All corporations have politics, even the smallest startups. Some are just more cutthroat/feudal/kafkaesque than others.

Lets say you were in charge of the project, are intimately familiar with the technology, and had a clear plan that would lead to success but upper management wasn't happy with the timeline. Their goal seems to be to quickly complete this project to display it as a "win".

Now the new manager was brought in, does not understand or care to understand the complexity of the project, and just keeps asking "when will it be done". Then got tired of that and changed to have it done in 2 weeks which is unreasonable, and then gave you an entirely false, negative performance review based on information they apparently forgot to actually verify or they would have known it was already complete and the people who were on the receiving end of the product are incredibly happy.

HR is asking for a meeting to discuss, what do you do? Tell HR about the depth of the incompetence Tell HR you weren't getting support from upper management Tell HR to look into what on earth was the reason this specific manager was selected.

or

GTFO?

This is a real life circumstance I am dealing with. I believe in the technology but unless changes are made it will be a guaranteed failure. Upper management likes the technology and really wants success here, but I know it wont happen unless then changes are made, and the people between the senior executives and me are making it impossible to be a success.

If they take it out on you, you know its time to go, but maybe this guy has been pissing other people off and you have no idea about it. Maybe its HR doing due diligence to fire.

Don't make accusations or shit on anyone, you don't know the whole story. Play to your strengths, which is knowing the tech and what it takes to get it to where it needs to be. Make sure you point out your attempts to communicate this fact. Provide any evidence of this- emails, etc. where you're communicating the state of the project and your projections for it. Let them know you've been frustrated with the miscommunication, but make sure that the miscommunication has started with you.

Again, don't shit on anyone. Stick the facts, so that if it blows up in your face it says more about them than it did about you. Its also the kind of resolution I'd I want to see on the interviewer side of "How did you resolve a difficult situation".

Be careful with the 'depths of incompetence' stuff. It's assigning judgement and value to the people you're working with. That may be valid (or it may not!), but it doesn't help you professionally. Try not to assume you know why they do what they do, just deal with situation as it is. Telling HR about how bad everyone else is simply won't help you at all.

Your strongest arguments would be:

* The well-documented original plan vs. what has actually happened.

* The factual discrepancy between your performance review and reality. Emphasize positive feedback, and get them to advocate on your behalf if possible.

If someone cares enough to sift through all this, they might figure it out and save you, but chances are good that it won't happen. Having a plan B seems quite prudent.

I should say that I've learned this over many years, but have applied it at the highest levels of corporate America and it does work. If you present an estimate _with evidence_ it makes it so much harder for even the most grizzled IT exec to argue against you. Most are still used to thumbs in the air so if you give them something tangible, they will actually love it.

As a borderline autistic person I have a very direct communication style and lost account of how many times I burned myself for failing to "beat around the bush".

You can't say "the project is doomed" even if it is true. You can't say it will be so over budget and take so long that it would be better to cut the losses now. Don't expect to go unpunished for saying "the king is nude".

According to my experience both parents are absolutely right, but the first is how most organizations work and the second is an ideal seldom found in the real world.

You seem to believe that everyone is mature enough to hear bad news, delivered objectively, and accept it without blaming the messenger, and without dismissing it because it doesn't conform to their wishes. I wish I had your luck in bosses.

In some, you actually have to "earn your place" in the company, and most recommendations I've seen are "keep quiet and listen".

I'm about 3 months in at a new company and starting to see areas for improvement. I just make a note and keep my mouth shut. In another 3-6 months I'll have earned the right to start diplomatically suggesting some of my ideas. For now i just try to understand the thinking that went into decisions that resulted in our current state.

If you want to go into a new organization and "be disruptive" and you're not a management consultant, be prepared for the likely outcome of failure.

This works pretty well in smaller companies or startups, but corporate culture is usually political enough that it would be a disaster for your career.

> Then just ask how they want to deal with it.

Disagree. Anytime you find a problem you should come up with at least two solutions before you bring it to leadership. Managers hate people that only come to them with problems. You're closest to the project and you should be the one to know the situation and possible solutions.

Yes. I think many people who believe they were punished for delivering bad news were actually punished for not offering ways to solve the problem. It's easy to simply say, "the project is doomed" and leave the problem in management's lap; much harder to come up with creative ways to rescue a bad situation.

Only one time?? Are you hiring? :)

You will never be thanked for telling them uncomfortable truths, even if they -don't- know. Even the private conversation is dangerous; as you say, keep it as low key and minimal as possible ("i have some concerns about the timeline" is literally all you should say unless they ask, and your answers to any followup question should be equally circumspect).

Instead, as others have mentioned, just make sure you document what does get done. Ideally have a decent backlog of things that need to get done, but that presumes a PO who does their job (and it sounds like he/she probably isn't). That's your CYA, and your innocent response if they ask why you didn't raise the alarm.

Deadlines often slip. It happens ALL THE TIME, regardless of elaborate and sophisticated project management techniques and skilled contributors. Deadline slippage is also RARELY FATAL, but yeah, leads/PM's can absolutely get themselves metaphorically shot by bearing bad news to the wrong people at the wrong time.

Some orgs hire a ridiculous number of PMP's who pretend like they're making a difference but are really just practicing an elaborate dance of goal-post-moving to appease the deadline-gods. People in such orgs often bullshit about a "track record" of being "always on time and under budget".

Best thing OP can do is learn from the mistakes and speak up next time during planning phases, well before deadlines slip.

Always wise to know what the corporate culture is around these kinds of things.

Corporate culture includes everyone involved in a project. You can't be calm if you have someone outside of your office going mental over something being a day or a week late.

I've seen this so many times, it's like why even bother attempting to describe what we'll deliver. Just put the date down.

How do you know deadlines are going to slip when planning the project? Makes no sense.

Surprisingly, it works relatively well to estimate how long the project will actually take.

It falls apart if you're talking about 10's to 100's of people working for weeks/months/years, or wherever you need to compete with other vendors for the contract.

However sometimes, it can be a calculated risk, for most projects, something is provided by the client, and generally they are also late on their parts. If played correctly it can hide delays on your side.

Also, being over-optimistic in a bid doesn't mean you have to be over-optimistic internally, you could set realistic expectations internally and "manage" properly the delays on the customer front.

Just to be clear, this is a cynic view of things. Every time I see something like that, I cringe inside (and even outside).

However the 2x rule can be quite limited in big projects as it doesn't account for the overhead induced by the size. In a team of hundreds, 30, 40 or 50% of the efforts can be lost due to difficulties in communication, management layers, heterogeneous set of competencies and skills, etc. It's harder to identify what this overhead could be. They can be huge differences between relatively well integrated teams and a complete mess.

3 hrs => 6 days

2 days => 4 weeks

Or say 2 decades and get all the praise when you come in under time and budget.

If you actually want to have some integrity when you talk about deadlines before it eats up your insides and you lose sleep you will need to have these beer / lunch conversations to gauge the level of appetite for change and then start talking about how to get something shipped on time as well as the consequences for not shipping on time.

Sounds like you already have this dialog with your manager. Keep talking about how best to manage expectations up the chain.

You’ll want to get buy-in to reduce scope or make whatever other changes you need, otherwise you’ll have to lie to keep up the facade that things will ship on time. It will burn you out.

If the read in the parent comment is bad for your org and it’s NOT normal to BS deadlines and ship late then no paper trail or written warnings, risks, and issues brings with it some badness as well - judge for your organization. I’m guessing you may already know the answer.

This is probably not the best career ladder advice at some firms, but at all costs make sure you never lie for anybody. Keep your integrity. Be honest. Sleep at night.

Of course sometimes “honest” is an excuse to be pessimistic. Look hard to make sure your dire warnings are not “chicken little” pessimism, then talk it out with your management, but don’t lie for them and be honest about your engineering and your team.

> a rep as a negative person if you make _true_ predictions

> out-loud that don't fit the common desire.

I've heard this very often, both as advise, complaint and even in an intimidating manner. And yes, I've seen this, people who stay kind of positive stay in their position even if they screw up a project completely so it has to be "rebooted". In fact I've also observed a super negative person, being a colleague of mine for 2.5 years and staying good with everybody despite one screwed up project.

On the other hand people have put me in various settings under high pressure to keep my mouth shut both internally and externally. (That was only in the startup/co-founding setting though.)

My conclusion: I'd take this advice with a biiiiiiig grain of salt. In my experience people get away with everything as long as they stay confident and keep their shit together.

Disclaimer: I'm not a team lead

You can be a negative/realist as long as your perceived value outweighs your "bad" attitude. The problem with this is that people are really bad at placing value on soft skills and all it takes is one clueless manager to sandbag you.

Everything op said above is spot on

But I mean for anyone with team responsibility: staying silent is bad for you, which is okay if you're in for the career. I totally respect that, people should be ambitious if they want to. But this is the recipe to make workplaces toxic and bad for the whole team.

You do need to figure out for yourself a realistic, pretty safe time when you will be ready: an extra month? three months? never? You say the work is outside your team's comfort zone. This is potentially a much bigger red flag than being late. Will the team learn and deliver, or it just cannot execute at the speed requirements are changing or will soon be? Be brutally honest with yourself.

If you think you can safely deliver the product in, say, three extra months, then keep working but be ready with good estimates when the time comes to redo the schedule. When that discussion comes (usually suddenly), having a clear plan and realistic estimates that you can confidently present will likely give you (most of) what you ask for. IME really bad options are either agreeing to fix everything in a week (if you know it will take three months) or not having an estimate at all "we are burning midnight oil and I cannot tell you when we will be done". Either could lead to quick problems.

IME when "what do we do with this crap" time comes, senior management does not care why you are late (everyone is at least some of the time). They want to know if you have a plan and look ready to execute it. Just my 2c. Good luck!

Like some of the other posts said - be real. If people don't respond well to this then the company has a bigger problem than a slipped schedule.

One sign this isn't healthy environment, frankly, is that no one has (apparently) asked the lead how he/she thinks the project is going. This also suggests that they already know and/or don't want to know.

OP's description is generally how every project at every company has ever worked, forever.

True. But under such circumstances chances are pretty good someone(s) is going to be shot anyway.

I think the answer is solid. But if going this route I would update my resume and reach out to my network.

If this ends badly you want to be prepared.

As someone who has been a bearer of bad news, this is a sound advice. Most of the time you are told - "At least give it a try". And even if you tell them - "I did try but still likely we will miss the deadline". They will ask you to check again.

It is mind-numbing when it happens the first time. And most of the time you get disillusioned and think - "I need to look for another job". Guess what? Every corporate works like this. All about positivity and "You can do this" messages. And most importantly people setting up super-aggressive timelines knowing well that you are going to fail.

> Second, unless you're in a startup where everyone's inexperienced,

Curious about this though. So, as per you startups are run by people who don't know how to run projects?

If however the project is due to slip 200%, or 400%- I guess I don't have specific advice, but that kind of project is the sort of project that can sink a company. Of course, you only really get to that point if vice-bigwigs are lying severely to the bigwigs, in which case there may be nothing a team lead can do about it.

Also be prepared with solutions. Any decent manager or product owner is going to ask things like: "What's a realistic timeline?" or "What could be cut to get closer to the timeline?"

It would worry me more if they didn't ask details. In my experience that means they sent you on a fools errand expecting you to fail and take the heat for it.

First they hear what they want to hear, i.e., what is not threatening to them. 'Project delivery will certainly be late' is heard as 'the next milestone will be late' or 'we're a little behind schedule and will catch up' or 'it's making another project late', etc. It's truly incredible what people will construct in their minds. What's the saying? 'Don't expect people to understand what their salary depends on them not understanding'?

Second, like everyone, they ignore or put off dealing with bad news. (Probably, that's a temptation of the OP.) Then they say, 'I didn't know.'

It depends on the people and the organization, of course, but you do you protect yourself from being thrown under the bus?

It can compel some attention and provide an opportunity for extra thought. An unwanted verbal message over lunch is easily forgotten or misremembered, intentionally or not, weeks or months later. A written one is harder to ignore and provides something the recipient can re-read and ponder later.

Also, there are circumstances where documentation is good to have. For example, it may help in a company with more layers; your email to the guy 2 layers up may help when the guy 4 layers up gets involved.

It's her responsibility to help the rest of your business do the best they can with reality. If sales of your existing product have dried up because prospects are waiting for the modernized one, that's a big problem (been there). But it's a problem belonging to product and sales management, not you. Unless you are a founder.

Renovating software is hard, much harder than greenfield software. All the best to you.

If you're in a smaller company, and you have clout due to being closer to the top of the food chain, and you have a vested interest in the success of the operation, to the point that it's worthwhile cutting your losses and moving elsewhere if the outcome isn't positive, then the higher risk strategy of pushing for change makes more sense.

However, these things happen time to time and when you have a stubborn PO like that from the beginning, you should have started looking elsewhere way before as a lead role. I’ve never heard of situations where a manager takes the blame. It always falls to the engineers.

If you do too much boat-rocking, though, you may find yourself looked on as "external" to the other responsible people, which is not a good place to be.

1. Focus on something going well. 2. By the way, could you fix this little thing? 3. Return to positive stuff.

This formula can be applied to delivering honesty amid positivity. Ideally whoever you're communicating is mature enough to just take honest feedback straight, but if they aren't then this can be a safe(r) way to deliver it.

Bearers of bad news are frowned upon when the bad news is their fault and not presented when its determined to exist. I think this is a distinction that should be made with your phrase.

1. A small course correction can work wonders early on, but if you wait until the ship is seconds from the iceberg there’s nothing anyone can do. Or use the cancer analogy: early detection can be the difference between life and death.

2. Yes, sometimes deadlines are padded and you’re silently expected to miss a little. Sometimes they are not and you’re not. How do you know which one applies to you and your project?

3. Having private conversations is fine but private conversations can be denied and privately made decisions do not become the broadly understood plan of record, leading to confusion and ambiguity, which are risk multipliers.

4. A positive attitude is good and hiding real problems, evading responsibility, and playing corporate games might work in the short term. However if that becomes what you are known for, it will limit your career long term.

That constructive feedback is actionable and adds value. If your manager (or the business) chooses to ignore it, don't be frustrated, but when it's constructive, finite and actionable, you'll be surprised how often they'll make the changes.

If you've been there for 3 years and never had a drink socially with the PO (who presumably OP doesn't report to other than in this status report context) then you suggest it just so you can talk about how you're not hitting the schedule, it's possible they don't take it well.

“What happens if the deadline slips?”

If the project is late, does the company go out of business? Do people get fired? Is the overall deliverable unusable within the org? Is the deal lost?

If the answer to these is a big “no” then totally agreed with OP to not sound an alarm.

However configuring a skilled team and leading it to do excellent work and constantly improve should be something most people strive for.

NB Based on one fairly large project I was involved in for a large company where there was a huge drive to get the system delivered on time then.... nothing. Nobody used it for months.

Eventually we found out about the real reason.

As long as you are sure you will eventually succeed, ignore the problem and keep going. Being late is no big deal; it's actually a confirmation of how amazing and innovative your product is.

If someone senior brings up the issue, don't flinch, and be ready with an alternative timeline.

> The rest of the org probably made a schedule they know you can't meet

> Most people probably already know you'll be late, but aren't saying it out loud

> There's a good chance <your boss> already knows as you suspect.

> It's probably not new news to <the project owner> either.

Doesn't take much for one, if not all of those to be untrue. And by the time it unravels, it's too late.

If you do this, follow it up with an email outlining everything you said so you have a paper trail that you brought it up with your boss.

That’s just bull.

If your organization isn’t willing to get real and is blaming people instead of processes, it’s the wrong org to be.

Just say things as they are. I’d just raise this in my 1:1 with boss and boss’s boss. “It’s highly likely that we’ll miss X deadline, because of Y reasons. Here are some options we have. Either cut scope to meet deadline, pull in more resources for Z work, that can be parallelized, or push back the deadline.”.

First get PO on board. Choose the process that will push PO into the central role: Kanban, Scrum, XP(anything really). Work with the PO to create user stories, estimate and calibrate. PO should work with stakeholders to ensure that the timeline is realistic.

Get your team a proper training. Hire someone to do training on the tech you use. Get some courses from Pluralsight/Udemy that will be mandatory for everyone on the team. Extra day in month spend on training is not much but it will up-skill people quickly.

Drag in your manager. Get him into a meeting and ask for a guidance of the senior manager. Make him co-responsible, he might help with funding on the project. Cut features to absolute MVP. If nothing works, escape sinking ship.

But yeah: 1. Be honest with everyone 2. Invest in online courses for everyone 3. Lay out a simple roadmap for the minimum MVP 4. Hustle

And next time use my recipe for estimating. Spend ~ a day on this.

1. Split up everything into the smallest subtasks 2. Estimate the time all subtasks take. Uncertain? Write down a low and a high. Still uncertain? Split the task into subtasks or confer with someone. 3. Add the times together and multiply by pi. If applicable, do it once for the high and once for the low. 4. Present the high estimate. It is probably closer to the truth. Estimating the low as well is more of a psychological trick.

Don't use the subtasks for the development though. They will be too fine grained.

Each integration point with a 3rd party automatically adds an extra 1 week+ to my estimates, depending upon the complexity.

I would work for you.

Get some post-its and write down each feature. Organized on the 2x2 with these axes X: "risk/complexity" Y:"desirability" (that's business & customer desirability.)

Setup a meeting with your products owner and others to try and get a good deal of feedback and communication, reorganize the 2x2 matrix during the meeting to build understanding of risks and priorities.

With everything on the table the big risks should be clear and addressable. The product owner will be able to make some changes to the product plan.

Visibility and transparency is key, don't do an ass covering exercise, and act sooner.

Make sure you understand what has been difficult and outside the teams comfort zone, where improvement could be made etc.

Also be aware of the motivations for the product owner and empathize. Build & strengthen that relationship.

Better feedback loops, better clearer/slicing of feature requirements... I could only generalize, but aim to improve communication and even if all goals aren't met it will be a healthier place and contingency will be easier to work on.

Not to sound like an idiot here or anything, but does that mean something like this: Risk | Complexity ---------------------------------- BiZ desirability | | ---------------------------------- Cus desirability | |

Can't an item be in many of these squares?

         Necessary
             ^
             |
  Simple <---+---> Complex
             |
             V
        Nice to have

If I were in the OP's position, I would start discussion with the direct manager as early as possible - and begin by breaking down the remaining scope in terms of where the features are in this diagram.

If the product must be "ready to ship", clearly some corners will need to be cut - especially the bottom right.

You are correct that the way you described wouldn't work.

a) a new timeline that you believe you can meet or b) a list of tradeoffs that can be made to get the project out the door in time

I have been an engineering lead and a product manager and it is much better for everyone to just be upfront about all of this.

You know what your team can produce and (roughly) how fast they can produce within an order of magnitude time-wise. The product owner should know what stakeholders actually want product-wise and what an acceptable timeline looks like. You should be able to work together to narrow the scope of what is being worked on to a point where your team can accomplish it within the timeframe.

Communication and setting expectations are key. This needs to be done both up front and on an on-going basis. As an engineering manager, you should be able to evaluate, week-to-week, where things stand and which tasks may need to be cut to make a deadline or how far a deadline should be pushed back if things can't be cut. Your product owner should be able to weigh in on this and should already be prepared to pare down requirements if necessary.

It may be painful and embarrassing to start having these conversations now, but it is significantly less painful and embarrassing than having these conversations in 3 months when the product is expected to be delivered.

Great way to lose your people because at some point the only way to make the artificial deadline is to increase the pressure on the team building it to satisfy the manager. Those that can move out will do so, you will be left with the people that do not have much in terms of options to finish the job.

This movie has played 1000's of times in badly managed tech companies.

You need to get this under control as soon as possible, definitely don't "give it a couple of weeks and see if the team picks up pace". Start making lists, what has been done, what needs to be done, prioritize and start tracking that.

Don't create big tasks that are measured in percentages (frombulating the gizmobob is 42% done). Make small tasks that are either done or not done (0 or 1). Small tasks meaning measurable in hours, not days, let the people who will do the work make the estimates. Don't worry, this is not micromanaging, this is properly managing a project, and yes, it will take some of your time keeping track of all of this.

There is also the question whether should you be doing this or should the product owner be doing this? Obviously the PO is not doing this, and you have a leadership position, so I would not hesitate too much.

I think aside from looking up the org chart, you have make sure your teams knows you're there for them. It's likely the have ideas for improving the process in the immediate, as well as the long term. Asking them is probably a wise thing to do.

The key to surviving this is:

1) Informally let everyone who may look bad know the truth.

2) Gather data. (No metric is perfect but this takes it away from being about people)

3) When it comes time to present formally, list what you are doing about it and what everyone else needs to do. It should be worded as, “To hit this date, we need Jane QA to do X, Joe PM to pick the two most important features, bla bla...”

4) Document #3 in a plain-English follow-up email. List names not orgs.

5) Send weekly updates to number 4 in writing.

If people don’t give you the help you need, you’ve done your part. They also won’t be surprised.

In all of this, be specific, factual and unemotional.

- A simple summary: we need to deliver by x but current estimate point at y being the delivery date.

- An estimate of delivery for each features you have visibility and their dependencies (not task, features. This email will escalate at some point and you need it be management friendly)

- A backing analysis to defend your task time estimate. Maybe as an external link or attachment.

- A suggestion on a set of feature you feel could be cut or postponed after release to keep the project within deadline.

The fire alarm need to be sounded immediately as you see smoke. Start with your direct manager, but first build consensus between the team: you’ll be squeezing the manager toward the owner, and for him tje path of least resistance will be to put pressure on you and the team.

Another way to look at it is that programmers hate death marches. Projects like this could lose people, and sometimes it's good to have some backup.

But of course, they still try it anyway.

Lead: "We're in serious danger of missing our delivery date in 6 months."

Suit: "Egads! Here, have 5 new grads with no experience for your team, get it done!"

It's like telling you that you have 3 months to achieve world peace, otherwise all the wars are your fault.

If the response is, "You'd better hit the dates or heads will roll", then respond with, "Of course we'll do our absolute best!" and start looking for a new job.

If the response is, "That's disappointing, but we can't change anything because all of our marketing/whatever is dependent on you finishing everything on that date." Respond with "Of course we'll do our absolute best! Let's see how it goes for the next 2 weeks and hopefully it will get better". Start poking around under the hood to see if there is any wiggle room for pushing things out (i.e. are you being fed BS, or is it really the case that the company is doomed if you don't deliver). 2 weeks later have the appropriate conversation. One time I had to say, "I completely understand the position we're in, but I'm sorry to tell you that the odds of us completing our part of the work on time is extremely low and I can't think of a way to fix the problem. I think we're going to need to work on a new business plan." Basically its realistically discussing the "we're totally screwed" reality. Try to find the best compromise that you can, while looking for a new job in the background :-)

Otherwise just play it by ear. Unreasonable product owners will be unreasonable no matter what you tell them. You might as well tell them the truth. If they are going to flip out, then let them. If your product owners flipping out bothers you a lot (it bothers me a lot ;-) ), then look for a new job.

However, my experience is that when you are not flipping out yourself and are open to listening to the other person's problems, usually good things happen. I don't often look for new jobs when my projects aren't working out as hoped.

  > If the response is, "You'd better hit the dates or heads will roll", then respond with, "Of course we'll do our absolute best!" and start looking for a new job.

If you're in one of these companies where people are not allowed to screw up, then I would recommend you start looking for a healthier work place.

Good luck

If your manager decides to blame you, rather than defend you and your team, it's resume time.

If they don't know the actual status of the project then they haven't been doing their job either.

Be ready to lose some weekends and burn additional hours - but people will appreciate your being on top of things.

People shoot the messenger - when the messenger is too late in delivering the warning when the rest of the business can't do anything to fix it. Even if management is anticipating delays - it will still look good on you that you are able to foresee problems, and your foresight will be rewarded later on.

People don't like hearing bad news - but if the bad news is delivered early and documented in such a way that it makes them responsible for not acting on warnings, they tend to work on it positively.

If you do the above and still get shot as the carrier of bad news - the work culture is toxic you are better off working elsewhere.

Bottom line, stay true to your own sense of integrity and be honest with whomever asks for your assessment of the situation.

I agree with the other comments that suggest you have conversations about your management and that you journal your progress and concerns.

The cultural question is around what happens when it is obvious the schedule is going to slip. In some organizations the group looks for someone take the heat and they heap a world of pain on that person. Generally that is the person who doesn't have any record to back up their assertion that they told everyone else it was not going to work. In other groups there will be a great ceremony of replanning and another unrealistic deadline will be pronounced and the cycle will simply repeat. Sometimes organizations will want to figure out how they got the schedule wrong and apply fixes (your journal will be invaluable there).

> At what point should I start sounding the alarm?

Immediately.

IMMEDIATELY

Then get everybody onboard (your direct manager first). Talk about the problems you have and how you can solve them. Make a plan that everybody believes in and set a new release date together.

In general, modernization projects are not about timing, but about high quality. So cost are the only variable here, making it important to know how much that project is worth for your organization. Is it just nice to have or critical for the development of the next years as it cleans up a lot of technical debt? Keep that in mind as the consideration of stopping a project is always on the table when it leaves its frame.

Start setting up meetings with the project owner ASAP. People are usually more angry if not informed. If they've been informed in advance, there are a lot of options that can be taken, and it lifts a little blame off the dev team.

It's very tempting to think that on a practical level, people 'need to know' what's going wrong. Unfortunately it is often very difficult to accurately or objectively assess what the underlying problems are and in many cases, what you perceive as a problem can actually turn out to be a symptom of some other issue.

Project slippage happens all the time - and in and of itself it may not indicate any serious issues. It could just be a case of poor estimation, or scope creep, or some other 'process' related issue which is unlikely to be something any single individual can do anything about.

In my experience, the best way to deal with these kinds of situations is to make sure you're keeping your relevant colleagues up to date. If you feel like some deadline isn't going to be hit - it's probably best to voice your concern about that risk (and only that risk) to your immediate superior. In many cases it's likely that people are well aware of how behind things are - but everyone has a different assessment as to why.

In such situations it's often the case that the most you can do is to tend your own garden. It's important to keep the chain of command - even in small organisations (and especially when dealing with multiple teams / stakeholders), and avoid trying to assign blame (or even identify 'the cause') unless specifically tasked with figuring it out.

Basically: if it's not your job to raise hell about things, then don't. Keep your superiors up to date with progress and let them figure out the implications.

Although it can be intensely boring, project management tools can help to de-politicise these kinds of situations: graphs aren't personal, and the more regularly the relevant people can get a snapshot of progress, the less likely it is that it'll fall to you to point out when things aren't going as expected.

if they are your people then there are all sorts of opportunities to reorganize what gets done first, and who is working on what, and how it all fits together.

you can take a unfocussed seemingly infinite amount of work and turn it into 'if we can just get this seed part done, then the rest can hang off that. jane and timmy, since you are both working adjacent to that piece, and I trust you both to sit down and make it happen - please do that'

thats the best part of the job

  Start tracking this risks DB on a weekly basis
  Involve your Manager and the product owner in the risk analysis and mitigation task.
  It is shared responsibility of management.

  Each week update the ETC and show how it has changed as a result of the risk mitigation.
  Sit down with the product owner and juggle the features to get to an optimum mix of ETC, features and risk.
  He/She has to take responsibility along with you.

  Up and Down and sideways...

Reset everything. Massively reduce the scope of the project and make sure everyone knows that's what you're doing and to expect to see something being delivered soon, but that it will be a small and simple component intended to get something out there.

Deliver the smallest useful thing you possibly can as quickly as you can, and show everyone,

Once you've delivered a few parts get a bit of momentum, get everyone together and hash out a slightly bigger next step.

Things cannot be* late. You are only on a week timeline. There is no other timeline. Forecasts outside the week are unpredictable and should be ignored.

This will give you a velocity (items done per week) and start quickly building team confidence. Things get done.

Don’t let anyone change or modify the week goals. If some one wants something they pitch for it Monday.

A Project or Product are never really finished. There is always a long tail of things to do or remake. In case of the goal being so far ahead, pick three ( or may be just one depending on teams size, but no more then three ) things / function / product features, that it MUST work, start sprinting towards those goals. Make them sound as easy as possible. Make a deadline that they know they could sprint to. My experience has taught me, may be only 1 out of every 10 or 100 person can see the bigger picture. Human are not very good at broad perspective, that is why you must set small enough goals, that is mentally easy to comprehend, and therefore mentally easy to achieve with hard work, but not impossible, damaging morale.

Most of the time, ( if not all the time ), once you prioritise those goals and reach within 80%, of what looks nearly finished project. This is a good time to talk to direct manager, because your last 20% of project will likely take the same amount of time as your first 80%. The higher management will hopefully, having seen the good enough 80% work, decide on which direction to go next. ( Which is another broader set of view on how to jiggle product / project / business/ operation / expenses priorities. )

Sadly, everyone thinks removing yourself from bad environments, especially as a lead, is selfish as though the company isn't. Also, many assume leaving is impossible/difficult, but in our industry at this time, that's rarely true.

You need to find the real needs of the real users and customers. You need these in priority order. Perfect answers are not required, just good enough answers. Now get your team focusing on getting things done in priority order. When your 3 months are up you can then say "we didn't get everything, but we think it is good enough".

If you cannot get someone else to tell you priority, then start asking questions until you can come up with an answer. Sometimes you have to make a decision and hope you are close enough. Sometimes you will find other people (marketing, sales, your boss) who will help. An incomplete team that recognizes that things might not be perfect but they can influence one where the imperfections are is better then going alone, but go alone if you must.

Note that customers and users are not always the same! If it is a customer need you can fake it as it won't be used, so make this look good, but make it obviously useless to users. If it is a user need it needs to work right, but it doesn't need to look as good since the customer has already bought it. Of course for release two you have feedback on what needs to be fixed.

As much as everyone hates deadlines they are important and try your best to meet them if they're realistic.

2) Create a clear list of planned features with him (if you haven't already)

3) Priorize the features. I.e. find out the ones that where really promised to the customers (the manager knows). Usually it's just 1-2 key features that sell the product.

4) Focus just on those and code properly. Especially if you are doing a rewrite / modernization. What's the point of having a new product, that is hacked spaghetti code from the beginning?

1. http://brucefwebster.com/2008/04/15/the-wetware-crisis-the-t...

That being said, faith won't magically fix everything. If you are unable to make it, then figure out what you can deliver and then tell your manager/product owner. Deliver the "bad news" with a constructive alternative. Cut away some features and then going forward be ruthless about scope creep. Urgent thing CAN come, but then others needs to be removed.

Q1. Why late? Work is 'outside of comfort zone', thus accurate estimates are impossible.

Q2. When will it be ready? Scope, timescale and quality are interdependent. Ask 'the business' which two are most important to them. The remaining item will need to be revised. My recommendation would be to curtail scope and deliver the rest in phase 2. If they say timescale can be extended the revise estimates based on current velocity, i.e. if you are 30% behind where you expected, add 30% to all outstanding work items. If quality is cut, make sure they are aware of the additional support and maintenance costs that will be incurred.

Either way, do as rinka_singh says and get the PO/PM to establish a risk log accessible to all. I would add that each risk should be assigned to someone who is responsible for tracking it. Review the log each week.

Raise the alarm now because there will be dependencies, and you are probably not aware of all of them.

I would not be worried about how the alarm is percieved, if your intentions are to steer 'the business' away from a cliff it will be recognized.

Then during this meeting, run a deeper and more detailed estimate for each user story. How long would it take, what work has to be done and is it depending on any other team or future work? etc.

When you get a better understanding and know how off the original estimation/deadline is (compared to this new one), setup another meeting with your PO and your manager to share this information. Obviously you will need material for this meeting. As a lead, that's your job to create that material (slides, etc..)

That's it. As a lead, your job stops here. Any other decisions will have to be made by your PO or manager. Your role is to share that knowledge because these 2 don't have a clue about the actual work that has to be done down to the lines of code.

Good luck (you're not doing anything wrong at the moment, just bubble up the information and let them do their job).

The Good:

- I came in with a blank slate. They had no source control, no CI/CD, and two "database developers" using an ancient platform with only passing knowledge of any modern language - C#. I was able to implement best practices and teach them how to code in C#.

- The developers were eager to learn and were smart.

The Bad

- The company moved the entire project to AWS but to get anything provisioned I had to go through both my manager, the net ops people, a bunch of hired consultants, and an outsourced cloud management company. I never did get access to anything outside of some EC2 instances.

- None of the people involved knew anything about AWS besides how to translate an on prem network to AWS and then wondered why it costed more.

- I had a budget to hire, but only contractors. All of the best developers wanted a full time job with benefits. I never got the cream of the crop.

- When the company was acquired, they decided that they didn't "want to be a software company" and wanted to outsource everything. They did however want me to lead two more projects to completion. I stayed long enough to finish phase 1, but it wasn't the best implemented thing in the world. It was architecturally sound, but didn't leverage anything AWS provided.

- Everyone above me was jockeying for position at the newly merged company and didn't make development a priority.

My solution:

- I left for a job that pays slightly more where from day one I was given AWS admin access (yes I had the qualifications and experience). I'm now "just" a Senior Software Engineer but I am nowhere near as hamstrung when it comes to getting things done.

FWIW a better approach would have been to break the entire thing down into smaller, more immediately achievable milestones. Ideally do so alongside enough exciting new stuff to keep your developers' morale high - be weary that some might already have low morale if they're noticing that the project they're working on is going nowhere.

At any rate, the time to bring up the problem is likely now. Have a candid discussion with your team. Explain what's going on; collect data points you might be less aware of and new ideas as you do. Sketch out a brief but equally candid status of your current situation (in writing) to let your manager and the product owner in the loop, along with an outline of next steps get things back on track.

http://gettingreal.37signals.com/

Yes sound the alarm. Your heading towards a a million dollar failure.

Instead define a bare minimum feature set for 1 user role, build a mvp with that minimal feature set and get it into the hands of users

then start adding more

In an ideal situation I would say call be honest and tell the stakeholders your view.

On the other hand, from my corporate experience, it's not always the best course of action. See - as lwj1001 already said - some companies play sort of meta-game, where certain things are known but never said out loud. If you are in a position to change the environment - great! (But this is not likely the best opportunity to do so). Otherwise... I would still say your opinion to those who need to be informed, or even better - write them an email. The reason is - you might have to cover your ass in the near future. The worst that can happen is that everyone assume everyone know yet there is someone who doesn't.

https://hbr.org/2015/01/what-everyone-should-know-about-mana...

Without a concrete plan it was really hard for the rest of us to help or say what's really important. And so began the feature creep for something that was suppose to be a quick prototype ended up being whole implementation which took half a year to get first somewhat working version.

The problems for us was we didn't know status of anything as it was always promised to be ready in 1-2 weeks but feature creep made it bigger and bigger. We tried to help with planning sessions etc but that wasn't enough to get the prototype back to track.

As everybody got a bit too rosy picture of its status, our salesguy started selling the idea forward. The timing seemed to be right etc but we didn't have even proper deml version as the one guy chugged on with his waterfall ad hoc dev style...

After our sales guy confirmed there's lot of demand for this proto and we got the first somewhat working version out and when the next steps were not really sane, we made an intervention which we felt we should've done four months earlier.

First we had a team discussion and decision what should we do together for the situation and then we created concrete plan for the next steps we felt we needed to get first sane version out. Then we made this public to everybody.

The funny thing with this intervention was that the guy who made the feature creep proto felt relieved after this. The biggrst reason why we were so reluctant to intervene was that this guy would get badly demotivated but he had chugged on so long he did get really stressed and frustrated with the situation but didn't know how to get help in the hole he had dug in.

So my advice is to talk out loud and make things visible. Timelines, features bot yet implemented etc. Maybe a gant timeline etc. These helped us to get the project to a sane point shere to continue.

This is interesting. Every example of scope creep I've run into has been a case of too many cooks in the kitchen, or an over-zealous "thinker" (as opposed to a "doer"). If I want to avoid scope creep I limit the scope of the project to as few people as possible and get them as close to the users/market as possible.

It sounds more to me like everyone did get their two cents in, but not in the correct way, and this lone developer was formulating the requirements based on way too many informal channels rather than one structured one.

At least, at my org, these are all considered appropriate.

Scope creep is often a major factor in situations like this. In my experience product people usually believe that relatively small feature changes imply relatively small engineering effort, and of course that doesn't hold generally.

Sometimes product people will try to sneak scope creep by as a "clarification" of requirements, which almost always leads to the situation you're in.

So, depending on your environment, it may be constructive to draw attention to this, if it's applicable.

What has been done is what will be done.

The conversation they want is, "As the leader, the risk X has now hit, and to avoid underlying Y happening again and achieving predictability goals Z, I'm leaning to A or B on this timeline with those key delivery+derisking milestones. To get there, can you help with resource/negotiation/decision C, and what are your thoughts on alternatives?"

Even if you don't hit your full deadlines you'll have a more complete 'product' this way

If they suggest more dev resources, be wary; that almost never speeds up project completion

Maybe they make you the hero, maybe they make you the fall-guy. Very little you can do to influence that. Focus on the work.

> The team is great, it's just that the work is way outside their comfort zone.

This reads to me like the team doing the implementation literally couldn't have estimated this work at the start. Who in the company committed your team to deliver a fixed set of features in a fixed timeframe with new technology?

- what would be best for your company?

- what would be best for your team?

- what would be best for you?

Try to come up with answers for these questions separately. In particular, find out what is important for you personally (making a career, gain trust with your team, being open and honest, etc.). Identify the communication strategy which optimizes the outcome for you, your team, and your company.

Question : how will suffer if you're late ? (no, it's not the end users, it's someone, somwhere who said it was possible, whose career path is tied to the project, etc). Make sure he won't suffer too much, that may give some room on the planning.

A modernization project is only a modernization project if it is incremental by design and you have frequent releases (minimally monthly).

Throw out the flag onto the field and get the train stopped before you end up causing the entire group to be fired.

Just meet with your boss and manager and explain the issues, sooner than later. If the product owner is still in denial, well, you told them... They have to face reality.

Nothing worse than feeling to be on a failing project with lots of pressure to make unrealistic deadlines.

But it's not built yet? IANAL, but make sure they're doing this correctly. There's a fine line between selling and outright lying aka fraud especially if the "new version" doesn't exist.

Serious question, are there any adults around that can help your team?

My PO would rather cut a few features and hit the deadline than deliver nothing because we wern't conservative in our estimates.

It's a lot easier to plan for the worst early & hope for the best

Last week ideally. But now is fine.

> give it a couple of weeks and see if the team picks up pace

They won't if nothing changes.

What do you mean by "outside of their comfort zone"?

Is it a technology that people don't master yet? Do you have experts on that technology already on the team?

- You need to write down all the things that need to be done, the granularity of task should be between half a day and two days. (Anything larger than 2 days will be a task like "refactor this system" that hasn't been though through enough, and thus likely to be completely wrong.) Do this in a meeting with all your team members, they will be telling you what they foresee they need to do.

- If you can't estimate things, because e.g. the system design hasn't even been started yet for those things, you need to design them, at least on a very high level. So that you know, at least to some extent, how long you think they're going to take.

- Write down estimates for the aforementioned tasks, in person-days, by getting your team members to estimate these tasks.

- Ideally use some kind of task planning system such as MS Project, LiquidPlanner, manuscript.com or some JIRA plug-ins that can handle this sort of stuff. But even a Google Spreadsheet shared between your colleagues will be better than nothing.

- Now you'll know an end date. How far out is it? 4 months rather than 3? 12 months rather than 3? That makes a difference. If you're going to be late, you management may wish to give you an extension. If the project's going to take another year, management may wish to cancel or change the requirements significantly. You have to provide them with the information to enable them to make that choice.

- If it's decided to continue, then update that spreadsheet all the time. Get your team members to update it, and if they don't do that, then talk to them every few days and get them to tell you what they still need to do. Focus only on the future: remove tasks when they're done, add new tasks as they arise, change estimates on tasks as they're partially completed. So even if you decide to continue, maybe in one month it becomes apparent you haven't made as much progress as you'd like, or there have been unforeseen difficulties resulting in more tasks. Know if it's going off track again as soon as possible.

Estimate will be wrong. Things always take longer. This is a minimum bound. But if your spreadsheet says you need another 12 months on a project that only has 3 months to go, you can be sure that it won't be done in e.g. 2 months, that's useful information to have.

STOP. RESET. CONTINUE.

That said, I would update my resume and reach out to my network.

If this ends badly you want to be prepared.

As other have also said, you're also going to have to tailor the way you present the message about the facts (i.e. the "alarm") to your current organization's culture and your specific situation in it. You'll need to keep in mind your own talents/resources and current limitations in developing a message or plan (see also "Dunning–Kruger effect" for risks on that). Talents/resources and limitations include your own ability to present a message and what help you can rely on from the rest of the organization to develop a message and present it based on what your coworkers, manager, and management chain value.

If you eventually want to reflect on the larger issues that may have gotten you to this unfortunate situation and what your company can do better in the mid-term and long-term, here is a reading list I put together that includes multiple books on software engineering management as well as broader surrounding issues -- including a great book by Matthew Walker on the importance of adequate good sleep for everyone in an organization: https://github.com/pdfernhout/High-Performance-Organizations...

One item from there:

"Why Deadlines Need to Drop Dead" by Eric Elliott https://medium.com/javascript-scene/why-deadlines-need-to-dr...

"Deadlines are incredibly destructive to team productivity and morale. The #1 challenge software developers face is unrealistic expectations. Can we motivate & push without arbitrary deadlines? You can lead teams without deadlines. You can still deliver code quickly. You can still ship in time for Christmas. But you’ll be dealing with a different management framework. One that puts the deadline pressure on product managers rather than developers. ... The point here is that instead of trying to build out the CEO’s ideal vision of the product you’re bringing to market, you build out a beautiful stepping stone on the way towards that vision. In place of arbitrary deadlines, you deliver consistent, steady progress."

Eric Elliott advocates for the Marketing department creating each hype cycle for what is already finished and tested.

On a serious side though, perhaps release a beta version in the following days with the current state of the service/product? Maybe even give the customers a preview? That would be a cold shower and wakeup call for all stakeholders.

OutOfTimeException

Well done.