Disaplinery for bad estimate
Posted by BR14Sparkz@reddit | ExperiencedDevs | View on Reddit | 87 comments
My currently place asked me to estimate a job, the estimate was at the time of my understanding a good length of time to complete the task.
During the process the outline of the task changed and we where asked to do addtional work with wasnt re-estimated. The task in the end went well over the estimation and becuase my employeer treats estimates as quotes we lost some of that money as the client wasnt changed over the quote.
I am now facing a disaplinery becuase of this and I think it unfair and just want to get others opinion on if anyone has experianced something like this?
For a little context is was one of them projects where your involved to do and estimate, dragged in later on and the workload goes out of control becuase the deadline has passed and everyone just wanted to get it finished. Also the final work invovled so much more than we would normally even agree too.
rayfrankenstein@reddit
Software can’t be estimated effectively. Anyone who tells you otherwise is trying to sell you something.
z960849@reddit
You can do estimates effectively but it is a skill like everything else. Spent 10 yrs doing it. You need to know the exact scope of your work.
Spiritual_Stomach693@reddit
IF you know the EXACT SCOPE - yeah this little thing.
this happens probably when you're doing some 1 page joomla templates.
z960849@reddit
And all the best thing to do is to storyboard it and create some sequence diagrams
sehrgut@reddit
No, and if you think you can, that's your ego talking, not expertise.
valkon_gr@reddit
Sure, if you are working on the same project for years it could be easy to estimate stuff yes.
z960849@reddit
I was scooping out new projects at least once a quarter. It depends on the client you just need to do a lot more up front work and a lot more story boarding.
ratttertintattertins@reddit
Estimation is easier in some domains than others. I work in computer security and do a lot of systems programming/driver work. Lack of story boarding is rarely why estimates are wrong. They’re usually wrong because of hidden complexity associated with a highly complex environment.
You can do something and find it’s incompatible with something another security vendors does. You may have never even heard of them before but your customers have and it comes from left field. You can discover behaviour within the OS which causes a significant rethink.
I recently had to port a driver to ARM and discovered half way through that the task was literally impossible until I spoke with Microsoft and they made a change to enable what I was doing on that platform.
It’s always the hidden complexity that screws the estimate.
eggeggplantplant@reddit
Others have commented on the absurd disciplinary action.
I will tell you how i handled this during my consultancy days:
Make the estimate, take the pessimistic bound, double it and if you dont know a lot of the context at least triple it.
This worked for me since oftentimes it can happen that some sales or PM person will reduce the estimate for some offer.
Your mileage may vary but if found that in consulting, honest estimates bite you since you dont get much reward if you are faster but a lot of stress if you need more time after all.
Spiritual_Stomach693@reddit
But it is just some static website? Why it takes so long? Some HTML and CSS.
What do you mean CMS? What backend? What is CI/CD? Buttons have what? Variants and states? You're selling me snake oil I think.
Quanramiro@reddit
A good rule of thumb for situations where esitmation is treated like a deadline is to estimate the worst case scenario and add 100-200% of buffer to that.
Also, not sure hpw does it look there but you can propose to announce topics to be discussed one week before so you got time to analyze those topics.
sehrgut@reddit
This is a huge red flag. Like, "start contacting recruiters and looking for a new job immediately" red flag. It shows your management has less than zero understanding of software development.
TheWhiteKnight@reddit
You need a new employer.
salamazmlekom@reddit
Next time they ask me for an estimate I would just tell them to fuck off cause they treat estimates as obligations.
salamazmlekom@reddit
For the next time just learn this phrase: "It's not part of the scope" and ignore all work that was not part of the eatimate.
aroras@reddit
I think disciplinary action for something like this is absurd; but, if there is a lesson to learned, it is that product managers tend to treat estimates as deadlines. If I'm forced into position where I must estimate a task, I always provide pessimistic and optimistic range of dates in which it could be completed. I explain _why_ there is a range and the types of unknowns we are facing. And I explicitly state that this should not be taken as a deadline. All of this is preferably done in writing.
I've lost faith product's ability to understand the uncertainty that comes with doing novel work
Regular-Active-9877@reddit
Depending on who I'm taking to, I won't even give the optimistic quote because that's all they'll hear.
Thormidable@reddit
I'd always give a range. It highlights uncertainty, gives you a safe fall back and basically forces managing the project back into the managers court.
showraniy@reddit
Hahahahaha, forcing managers to manage.
Hahaha, sorry, I've been let down in this exact way entirely too much, so yeah I'm with the other guy: I've identified who I can be honest with re: estimates, and who gets the longest one by default.
Sales guys get the longest estimate every time because they always make it my problem that they didn't know how to effectively communicate to customers. They won't come out and say they gave a short estimate, but I can tell because they blow up my messages and emails the moment that imaginary deadline expires.
In theory, I agree with you. In reality? I'm my own manager.
SnowdensOfYesteryear@reddit
Treating estimates as deadlines isn’t the worst thing in the world. In most cases you need to commit to a date to launch/deliver by so others can plan around you.
That said, providing that date depends on what kind of company you work for and the importance of your product. I work for a company that’s ok throwing engineers on to a high priority project to hit a date. In cases like this, you provide a realistic date with your resourcing requirements to hit the date. If it’s a low priority product, just keep adding FUD to the date to be extremely conservative.
lab-gone-wrong@reddit
It's so easy to have both though! That's the part that gets me. "The deadline is X and I expect our work to be done by Y" avoids confusion and facilitates any necessary conversations around the issue when Y comes after X.
So sure, estimate = deadline isn't cancer, but it's unprofessional
Agree, this is also unprofessional
Thormidable@reddit
Also, in this case, the goalposts move. Document (email to relevant parties) "requirements have changed in these ways. This increases the estimate by X" - I absolutely agree a range is important.
gemengelage@reddit
I've got the opposite situation right now. Product is pretty lax about missing deadlines and they recognize that sometimes there are things you just don't know beforehand. But my team regularly remarks that my estimates are too pessimistic and than takes a lot longer than even my estimate.
itsawesomedude@reddit
not just product, but also engineering manager too, i detest this kind of thinking so much, thanks for the tips
BonnetSlurps@reddit
I've lost faith in Product a long time ago. Good PMs are extremely rare.
Apprehensive-Ant5976@reddit
… and if Product wants to materially change the scope the estimate needs to be revised. That should be part of how they’re deciding priority & scheduling.
I’d push for stopping work until the new estimate is done and agreed upon. That would fail so “Ok, but that original estimate is void, we don’t yet have an estimate on when this will be done.”
Brought2UByAdderall@reddit
So who failed to address the scope change? That's what you need to find out. The devs should have thrown a hissy fit the second scope changed without a new estimation process being set in motion. A responsible PM would have called it out immediately. Somebody might be trying to throw you under the bus for their failure here. Don't let them.
Rikey_Doodle@reddit
Ya this is pretty BS. Estimating software timelines is a notoriously difficult and somewhat arbitrary process. Anyone who has ever worked in software knows this. To treat estimates from devs as firm deadlines, to not provide a mechanism for re-estimate, and then to ALSO take punitive action against the dev is absurd. Straight up clown car.
All this does is incentivize devs to just throw out arbitrarily long estimates to cover their own asses.
valkon_gr@reddit
So all those MBAs are useless and a poor dev is punished for overestimating.
netderper@reddit
If the task changed, the estimate is invalid and it should've been re-estimated. If this was a "known unknown" going into the project, then there was tons of uncertainty and the estimate should've been padded appropriately.
NastroAzzurro@reddit
The estimate is invalid the moment the work starts. There’s always unknowns, things to learn, misunderstandings, etc. There should be margin for error built into the estimate, and depending on the risk of unknowns, 50-100% isn’t unreasonable.
netderper@reddit
I would say even 2 to 3x is reasonable for something super vague.
SpudroSpaerde@reddit
Bruh
MrMichaelJames@reddit
Always pad your estimates. Come up with a good one, detail out all the assumptions and unknowns. Detail what will happen to the timeline if assumptions are wrong. Then multiple by 2 or 3.
angrathias@reddit
This is rubbish, estimate properly, and account for changes properly. Estimates can genuinely sometimes be off because you just didn’t account for something you should have, but changes to scope are not part of that.
Swamplord42@reddit
Can you explain what is wrong with padding estimates?
It's much much easier to start discussions by inflating your estimate and then revising it if there's pushback than estimating too low and having to explain why you're late and why the estimate was wrong.
angrathias@reddit
From a business perspective, an estimate is worthless if it isn’t representative of what you know. Projects already mechanisms such as variances and contingeny budgets to deal with scope creep.
To me, padding is making up for something that is missing from the estimation process. It might be because you don’t track your developers skills enough and so an estimate cannot be standardised to the avg rate of your team, it could be because your business team is too scared to tell the customer they need to pony up more money (in my experience this usually the most frequent one).
The problem with padding, is it doesn’t solve the root problem. Eventually you will run into scope creep that will overshoot even your padded estimates, and because your company lacks the processes to deal with it properly, now you’re screwed.
If you’re padding it internally and the rest of the business knows, then that’s fine as it’s a business decision on margin, but if you’re just keeping it too yourself, then you’re just compensating.
MrMichaelJames@reddit
Estimates are an art not a science. Estimates are based upon what is known now with certain assumptions. If you detail it all out it actually provides a better guess. Scope changes are not part of estimates but in the actual real world you sometimes have to give an estimate without the entire picture.
angrathias@reddit
That’s my point, you estimate what is in front of you, no more no less. You let the client know that estimates change with scopes. There’s no point padding it out, because that’s just excusing poor organization behaviour of how to handle scope creep.
And eventually, if you haven’t learnt to deal with scope creep at a business level correctly, the creep will exceed the padded estimates, or your company will lose customers because you’re constantly over charging by 200-300%
I have had to deal with this daily for the last 20Y of my career, customers don’t like it of course because they are being held to account for their own lazyness in scoping, but your business shouldn’t be the one taking on the financial risk. It’s literally incentivizing the customer to be lazy, the less they scope the more they can murder you with for final sign off.
MrMichaelJames@reddit
Scope changes are not the same as unknowns becoming clear or an assumption being wrong. Scope change means something changed from the given requirements that product or the client didn’t request from the beginning. Completely different from an assumption being wrong or an unknown becoming clear that impacts the estimate.
angrathias@reddit
All our specs include assumptions, business and technical risks. We call out those possibilities before a contract is signed so that the customer knows we aren’t on the hook for unknowns.
We’ll provide a rough order of magnitude on what we expect the upper bound might look like but we won’t guarantee it. If customers don’t like the uncertainty, we let them engage us for consultation to get more in depth and are charged appropriately for it. We’re happy to provide fixed quotes for fixed scopes and where we think uncertainty exists we’ll always assume the upper bound of an estimate, but we aren’t padding an entire quote just because of a couple of unknown points, and if there is that many assumptions being made then there is insufficient scoping going on, hardly a surprise these days with the cargo culting of agile.
plpn@reddit
Leave consulting now. It’s a toxic place and their whole business is human trafficking 😂
soundman32@reddit
Whenever I (as a SWE) estimate a job, the project manager doubles it, and the sales guy doubles it again, so the customer is told an estimate that is MUCH bigger than everyone estimated. This has been happening to me in dozens of roles since the 90s, so I know it's not unique.
I guess it could be on you that you didn't tell them EVERY-DAY that the estimates were based on the original work, and the changes will make things take longer.
When the client wanted changes, your boss should have asked them for more money, even before involving you. Your boss is the problem, not you.
Quigley61@reddit
From now on start building in massive amounts of time to cover bad cases. If asked why you're doing it, tell them that you were punished because the PO expanded the scope but nothing was rescored. It isn't your fault that someone made an agreement with a customer that a product will be delivered by a certain date. Whoever made that agreement is the one at fault.
This just seems extremely unprofessional and whoever made that agreement seems extremely fresh to the industry. They agreed a contract, the scope of the work in that contract changed, and no one thought to update the contract?
Polite_Jello_377@reddit
You should estimate yourself out the door and into a better job
UntestedMethod@reddit
how long has this company been in business?
using estimates as quotes? not billing clients for extra work?
these sound very much like rookie mistakes to me.
UntestedMethod@reddit
first of all there should always be a paper trail (contracts, emails, etc) of the scope of work your estimate is based on.
additionally, there should be another paper trail for any extra work that wasn't in the original scope.
if your company isn't defining clear scopes for their client projects, they're doomed to failure. If they're not bothering to keep track any extra work and bill the client for it, then they're completely fucked.
mistyskies123@reddit
Create a document of ALL the scope changes, who approved them (e.g. PO), and the timeline. If you can, look up/estimate how long each of that incremental scope ended up taking.
If you have any documented audit trail of you drawing people's attention to the fact this new work was going to alter the timeline, that would be helpful.
Also, do you have a screenshot or message showing the original estimate request as it was explained to you?
Your estimates were based on a set of assumptions, one of which being that the work you were estimating would be... that work.
If you're going to be thrown under a bus for this, don't seek to protect other peers if some hard truths need to be said about who was really responsible for what.
OverEggplant3405@reddit
No amount of documentation will prevent people from owning up to their responsibilities. Management added features and failed to negotiate the cost increase to the customer.
Xaxathylox@reddit
The OP was probably hired to be a developer, not a CYA specialist. The cost of doing business to maintain a project management capability is assumed by the employer... if they are not fulfilling that responsability, id recommend that OP polishes their resume and start doing interviews... unless they actually like taliking to coworkers that neither trust nor respect them
mistyskies123@reddit
Agree the OP should get out of there, it sounds a poorly-run and very political environment.
So many things about this are out of the OP's control.
To answer their original question: if they're faithfully representing the story (and it's a familiar enough tale in tech about rough estimates being treated as commited deadlines) then no it's not fair.
But politics eats fairness for breakfast.
Hopefully their next role will be with a more understanding company.
joelypolly@reddit
Who was responsible for doing the re estimation? Because many contracts stipulate that a change in scope will result in different billing. Did you let people know that the scope changed and hence the SOW needs to be updated?
nevermorefu@reddit
It is stupid especially for the reasons you mentioned. If I'm forced to give an estimate, it is 3x what I actually think it will be. It's usually around 2x and you beat the deadline.
Usernamecheckout101@reddit
Estimate is rolling a pair of dice
Revision2000@reddit
No
I’m responsible for building stuff and signaling we will/won’t make it on time.
Employer / management is responsible to act on those signals. Naturally scope change or scope creep leads to your original estimate no longer being valid. While you could’ve signaled that, they came up with the changes so it’s their responsibility.
Also, they’re really shooting themselves in the foot here: * In the future you’ll want to avoid this disciplinary action * So all your estimates will now be 50% higher * And a good reason to find another employer
z960849@reddit
You're stating facts and except for the fact that I would double my estimate.
edgmnt_net@reddit
Sounds to me like OP perhaps should have fought early against scope creep and refused to take unreasonable measures for damage control on their own time, considering they mentioned an increased workload. Someone else may have overpromised something and perhaps it is they who should be going back on it and doing damage control.
Revision2000@reddit
Yep…
But if this is how your colleagues treat you - no thanks.
alien3d@reddit
Estimate junior senior developer . Per ticket style and dont accept other advice . As per chunk you cannot estimate a real time issue unless very detail changes about it . Real fact life , 1 x3 . Estimate 1 hour actual 3 hour . You dont estimate 2 week jira chunk (whatever you call point , tshirt, fruit) too complete full fledge upgrading old code .
Equivalent-Score-900@reddit
Is this a start up?
renq_@reddit
But estimating is just guessing. Sometimes you guess, but in most cases, you don't.
NullVoidXNilMission@reddit
Big design up front, stamp it. If something else is needed then it's out of scope and needs to be re assessed. What does disciplinary action mean? Lol
saposapot@reddit
This doesn’t belong in this sub because it shows you aren’t an experienced dev.
No way an experienced dev doesn’t have CYA skills or you are very lucky to only have worked in good companies where you don’t have to hone those skills.
Anyway, don’t walk, run.
Where was your project manager in all of this?!? Ah, you don’t have one? Well, guess that’s not your fault.
This is also a great way to ensure your boss from now on will only get estimates with tripled values.
All in all, your boss has no business in having a software development company. He clearly has no idea what’s he doing and hopefully this is a small company that won’t cause much damage when it inevitably fails
Penultimate-crab@reddit
Lmao someone pulled that shit on my at a job with scope creep and AS SOON AS THEY SAID IT, I said FUCK THIS I QUIT. shut my laptop, done lmao. These fucking people have no idea how software development works. IM NOT CLEANING WINDOWS DAMNIT. Most things are unknowable test suite issues, environment issues, refactoring. Unless I’m changing the color of a button I’m essentially just guessing at how long maybe it might possibly take?
Brought2UByAdderall@reddit
The only way this is your fault, is if it was your job to raise the alarm about the old estimate needing to be updated when scope changed. That would more typically be on a Project Manager. So the question is, who failed to communicate to management that there was a problem?
GoTeamLightningbolt@reddit
Estimating software is soothsaying. Always double or triple your reasonable estimate.
auburnradish@reddit
As a lesson for the future, clearly communicate in writing how scope changes will affect the effort and delivery timeline.
For the immediate time, start looking for another job immediately. This is a dysfunctional environment and you have been blackballed.
edgmnt_net@reddit
Assuming this is the case, it goes to say that OP might also need to learn to say no. Early, bluntly and loudly if needed. How did they even get to the point of excessive workloads? This isn't putting in a bit of extra work to put out some fires when needed or being flexible, this is saying yes to unreasonable demands and unsurprisingly failing to meet them. OP probably should have fought back at the first sign of scope changes and extra hours, if they found themselves in that situation.
titan_bullet@reddit
It's your job to produce correct estimates and notify whoever handles billing when that estimate needs to be changed - you should've called that you would likely run out of time when you were asked to do additional work that wasn't planned.
Additionally, I'm not sure what your level is (and thus how high the confidence was in your estimate), but going through disciplinary for something like that seems excessive, unless you went like 3 times over the estimation. Again, it's your job to provide estimates, but the understanding is that there will always be overhead etc, so the estimate is always "padded" before it's presented (and quoted) to the client.
LloydAtkinson@reddit
Never have I read anything more absurd of tone deaf. What are you, OPs boss? Get off your fucking high horse.
edgmnt_net@reddit
Correct needn't mean precise. The comment has a point, some people have more or less responsibility to come up with decent estimates. It would be equally absurd to remove all such responsibilities.
aroras@reddit
I don't disagree with your overall sentiment but that sentence is inherently contradictory. If they produced a correct estimate, there's no one to notify because the estimate was correct.
I think this is better phrased as "It is your job to provide a _reasonable_ estimate, explain the uncertainty that makes estimation difficult, and keep stakeholders abreast as you continue to learn more about the nature of the problem and how long it will take"
It's also the stakeholders' job to _understand_ all of the above. I've seen engineers be very clear in their communications about estimates, only for their words to be treated as hard deadlines.
Xaxathylox@reddit
Estimates are expected to be slightly innacurate even when the scope is known. Your employer staffs its leaders with idiots.
davearneson@reddit
There are always changes that require additional work. The question is how do you handle it. You can't just accept it and do it without resetting priorities, scope, time and budget. Typically someone on the dev team would spot that there is a change and they would discuss it with the project manager, product owner and account manager for them to sort out with the client.
kcadstech@reddit
What’s a “disaplinery”
Haunting_Welder@reddit
What’s a disciplinary?
chrismo80@reddit
Classic ...
Why deadlines are pointless
Estimates are hard in general for SW-projects. And scope changes are often not considered during a project regarding already given estimates and deadlines. That's the mistake.
Ok-Mission-406@reddit
You may not know the answer to this yet.
But are you being disciplined for coming out with a bad estimate? Or are you being punished for being overly optimistic with an estimate and then not communicating until it became a problem?
If it’s the first one, your company is unreasonable. If it’s the second one, this could be a good learning experience.
There is a huge difference between coming up with a bad estimate and communicating versus coming with a bad estimate and not. The first one just happens. The second one kills companies.
morbiiq@reddit
Over estimate like a champ for everything.
FunkyForceFive@reddit
I would fight very hard against such disciplinary action it's incredibly counter productive and it show poor company culture. Your employer is entitled to hold you accountable for estimates that you make there's nothing wrong with that. But that's not what they're doing here because your being blamed for something. There's a huge difference between accountability and blame.
Accountability is good because it keeps people sharp, they correct mistakes, and try and get the optimal out come to the best of there ability. Blame is bad because in your scenario simply increase all estimates up to the point where you're 100% confident, but now all fixed price agreements become ridiculously expensive due to the padding so they end up losing a ton revenue, plus their employee is pissed off.
Having said all that if you are not ultimately responsible for delivering this project then this is simply not your fault. These things happen when you do fixed price agreements and instead of blaming you your employer should focus on why their business process produced an undesirable outcome and fix that instead of scapegoating someone.
serial_crusher@reddit
Scope creep always happens and it's the team's job to put processes in place that manage it. If you're a contractor especially, there should be some kind of framework specifying how you go back to the client and tell them "we can do that, but it's not in scope for the contract so we'll have to amend the contract and get a new estimate, or do the additional work after the original contract".
Is there already such a process in place that you failed to follow? If there's not, this is all a red flag that your company has unreasonable expectations.
If there is, work with your boss to not only improve your own adherence to the process, but to figure out what went wrong and how the process can be improved to prevent mistakes in the future. Even in the red flag scenario, work with the boss to improve process while you look for your next job.
Take note of this scenario as a "tell me about a time you failed" example for behavioral interviews. This situation and the process improvements you put in place are exactly what interviewers are looking for.
Material_Policy6327@reddit
That sounds like a bad company: never seen anyone disciplined for bad edtimate
No-Individual2872@reddit
Had to do a double take. You got "disciplined" for a "bad estimate". Estimates are a joke to begin with and people should already know that. Find a different company if you can.
ICanCountTo0b1010@reddit
It's one thing to estimate a ticket incorrectly, it's another thing to over-commit to work for a client by setting an incorrect capacity.
It feels to me like you're conflating the two together, potentially a learning experience here is that you should not consider this the same task, especially when your estimates are client facing.
Estimates within your team help keep your project on track and give you rough (rough) timelines. Estimates for clients are contractual obligations that set hard expectations and hard consequences.
Maxion@reddit
Who in your org is responsible for handling the customer? If the scope changes, it should be someones job to tell the customer that they need a new estimate + contract.
If you never told that person that the scope changed, that it does not fit the original estimate then you messed up. Otherwise it's the other persons mess up.
squeasy_2202@reddit
So many problem with this
It sounds like you did your best, but manglement didn't do their job well, validate your estimates, or respect scope. Now you're getting blamed for it.
Might be time to ride the Shoelace Express to somewhere that isn't shit.
Desperate_Rub4499@reddit
ooo the muddy waters of software estimation.
this is just bad procedures/systems. if there was a system to avoid this, that you were trained on by your employer, then i don’t feel sorry for you.
if you’re employer has no system for this and they are reprimanding you, they are in the wrong and should look in the mirror.
either way, there should be no confusion of deliverables in regards to the client. really depends on how the billing agreement is structured. sounds hourly… and if so you should get paid for all the work you do before signing off on deliverables. if its a fixed amount, that differs and your employer should have more control over whats being billed and why