Ask HN: How do you deal with managers/customers questioning your estimates?
106 comments
- Call it a forecast, not an estimate.
- Supply confidence intervals. (“50% likely it’ll be done by date X, 90% likely by date Y.”) Estigator.com is great for helping construct and illustrate these.
- Demonstrate understanding of client/customer/manager priorities, frustrations, and necessary tradeoffs: show compassion and supply suggestions for where scope can be narrowed if needed.
- Supply confidence intervals. (“50% likely it’ll be done by date X, 90% likely by date Y.”) Estigator.com is great for helping construct and illustrate these.
- Demonstrate understanding of client/customer/manager priorities, frustrations, and necessary tradeoffs: show compassion and supply suggestions for where scope can be narrowed if needed.
> Demonstrate understanding of client/customer/manager priorities, frustrations, and necessary tradeoffs: show compassion and supply suggestions for where scope can be narrowed if needed.
I think this is huge. I've found that if you ask if they need to cut things from the scope to hit a deadline, and tell them you'll work with them to get a scope that is reasonable by the time they selected, it works wonders. Sometimes it turns out they really need a small thing to get their next project out, but they are asking for far too much.
I think this is huge. I've found that if you ask if they need to cut things from the scope to hit a deadline, and tell them you'll work with them to get a scope that is reasonable by the time they selected, it works wonders. Sometimes it turns out they really need a small thing to get their next project out, but they are asking for far too much.
Wow, Estigator.com seems really cool! I wish it was a bit more flexible when editing though, even just playing around with it was a tad cumbersome.
>Demonstrate understanding of client/customer/manager priorities, frustrations, and necessary tradeoffs: show compassion and supply suggestions for where scope can be narrowed if needed
IOW ... it's all ROI - you have to be able to speak to everyone in the room at "their level" about the costs/benefits of the whole operation (see https://antipaucity.com/2015/05/05/what-level-of-abstraction...)
IOW ... it's all ROI - you have to be able to speak to everyone in the room at "their level" about the costs/benefits of the whole operation (see https://antipaucity.com/2015/05/05/what-level-of-abstraction...)
I've wanted something like Estigator for a long time! Unfortunately, it seems to be broken — it's not possible to add a specific type of estimate.
Also worth trying getguesstimate.com. Unfortunately development on it is abandoned, as far as I know.
I made my own text-based tool for this at one point, but I lost it when I switched jobs.
I would like to recreate it except more generally useful. I would also like to make it compatible with the SIPMath standard (which are an open standard for conveying empirical distributions, e.g. as business-relevant inputs to estimations, or the outcomes of them.)
I made my own text-based tool for this at one point, but I lost it when I switched jobs.
I would like to recreate it except more generally useful. I would also like to make it compatible with the SIPMath standard (which are an open standard for conveying empirical distributions, e.g. as business-relevant inputs to estimations, or the outcomes of them.)
Hm; how so? The interface is a little clunky; the + button at the bottom of the estimate component list adds three items, one of each type, and then I remove the ones I didn't mean.
There may be better tools out there, and I'd be happy to hear about them; this is the one I recommend only because I don't know of simple alternatives.
There may be better tools out there, and I'd be happy to hear about them; this is the one I recommend only because I don't know of simple alternatives.
This is great. We used to do this and offer to adjust later phases if needed. Rewards the customer for meeting their deliverables and being clear as well.
> Call it a forecast, not an estimate
Can you explain why? At least for predicting expected task finish times, I feel like people use them interchangeably.
Can you explain why? At least for predicting expected task finish times, I feel like people use them interchangeably.
In business terms...
"Forecast" is an expected date that may change due to circumstances.
"Estimate" is how long something will take, regardless of circumstances.
"Forecast" is an expected date that may change due to circumstances.
"Estimate" is how long something will take, regardless of circumstances.
I endorse this answer; it's more concise than I would have given.
I guess "forecast" is more explicit about the fact you're trying to guess what will happen in the future, so it's clearer that you can't be totally confident about when you'll finish.
If you say "I estimate 2 weeks", then the word "estimate" is often taken to mean "2 weeks, plus or minus 10%" (or some other fixed bound), when what you probably actually mean is "between 1 week and 6 months, but probably around 2 weeks".
If you say "I estimate 2 weeks", then the word "estimate" is often taken to mean "2 weeks, plus or minus 10%" (or some other fixed bound), when what you probably actually mean is "between 1 week and 6 months, but probably around 2 weeks".
[deleted]
> we continuously get pushback of: "Why would it possibly take so long? All you have to do is A, B and C!" (often providing incorrect solutions, increasing the burden of having to explain all possible implementation strategies to them and the risks involved with each step)
"Your estimate assumes the absolute best case scenario, and also assumes that we'll be working on nothing but your request. Our original estimate stands."
"Your estimate assumes the absolute best case scenario, and also assumes that we'll be working on nothing but your request. Our original estimate stands."
By my experience engineers tend to way underestimate schedules and those are the two reasons. Best case scenario means no suprises come up during implementation, which is almost always false. Roughly double the best case estimate is usually about right. The second though can be a miscommunication, whether the estimate is an actual date when done or an estimate of the man-hours.
Another problem is that engineers also tend to estimate only the time for original implementation, not for design, testing, documentation, bug fixes, meetings, etc.
A long time ago I read about some research that showed that the original implementation makes up about 1/6 of the total time spent on the task. This has been roughly the case in my experience too -- so now I budget for at least 6× estimated implementation cost, more if it's a tricky problem.
A long time ago I read about some research that showed that the original implementation makes up about 1/6 of the total time spent on the task. This has been roughly the case in my experience too -- so now I budget for at least 6× estimated implementation cost, more if it's a tricky problem.
> I budget for at least 6× estimated implementation cost
How else can I keep my reputation as a miracle worker?
How else can I keep my reputation as a miracle worker?
A reductive approximation: engineers estimate at 50% confidence (on average it will be done on this date), management and leadership hear that at 90% confidence (it will be done by this date to near certainty). Making these assumptions explicit up front solves tons of problems.
This has been one great thing about moving from "just engineer" to "consultative engineering/architecture/etc" in my career - learning how to speak to the business needs over the technical needs
At the end of the day, Ford doesn't care about its IT environment - they care about building and selling cars, trucks, etc
The NASDAQ doesn't care about the OSes on their servers, they care that transactions complete properly
Learn to speak to the business case, and the tech takes care of itself (more-or-less)
At the end of the day, Ford doesn't care about its IT environment - they care about building and selling cars, trucks, etc
The NASDAQ doesn't care about the OSes on their servers, they care that transactions complete properly
Learn to speak to the business case, and the tech takes care of itself (more-or-less)
> To me this is insanely disrespectful of the team, and it seems as though it's a boundary violation on some level.
To be fair, people asking you to justify your estimates aren't disrespectful. Realistically, you should be able to provide justification otherwise, your estimation is most likely flawed. And people wanting to have a better understanding of what is going on isn't necessarily a bad thing. Just like you would ask your joiner why it's going to cost X and take Y days, you want to have a good understanding of what is happening and to be informed.
To be fair, people asking you to justify your estimates aren't disrespectful. Realistically, you should be able to provide justification otherwise, your estimation is most likely flawed. And people wanting to have a better understanding of what is going on isn't necessarily a bad thing. Just like you would ask your joiner why it's going to cost X and take Y days, you want to have a good understanding of what is happening and to be informed.
> people asking you to justify your estimates aren't disrespectful
In my experience, people are only _pretending_ to ask you to justify estimates. In reality, they are just angling for a discount and/or rush job. It's just a technique for increasing anxiety.
In my experience, people are only _pretending_ to ask you to justify estimates. In reality, they are just angling for a discount and/or rush job. It's just a technique for increasing anxiety.
That's a toxic attitude.
The software is being written for the customer and/or management, and they're paying for it. They have a legitimate right to know why the estimate is what it is, and to understand what work is going to be done. If they want to exclude parts of it because they don't see the value, then that's up to them because they get what they pay for.
If you can't explain why it's a bad idea to cut certain parts out, or why certain things take the time that they do, then it's a failure on your part as the engineer, and not theirs.
The software is being written for the customer and/or management, and they're paying for it. They have a legitimate right to know why the estimate is what it is, and to understand what work is going to be done. If they want to exclude parts of it because they don't see the value, then that's up to them because they get what they pay for.
If you can't explain why it's a bad idea to cut certain parts out, or why certain things take the time that they do, then it's a failure on your part as the engineer, and not theirs.
But sometimes I don't know why it's a bad idea ahead of time! That doesn't mean I'm wrong -- often time reveals what it was I was subconsciously worried about.
That's what expertise is sometimes like: an accurate gut feeling, impossible to articulate clearly.
That's what expertise is sometimes like: an accurate gut feeling, impossible to articulate clearly.
In that case one must be assertive. Speaking this way does not come naturally especially to engineers.
You don't have to articulate it clearly, you don't have to know why you are making the estimate you are making. It's ok for management to push, in fact it is their job.
I suggest this book. https://www.amazon.com/dp/B004IK8Q22
You don't have to articulate it clearly, you don't have to know why you are making the estimate you are making. It's ok for management to push, in fact it is their job.
I suggest this book. https://www.amazon.com/dp/B004IK8Q22
I agree, sometimes it is just a gut feeling, but a lot of times expertise means knowing where the gut feeling comes from and being able to explain it.
If nothing else, management will be more trusting in those situations if you give good and accurate estimates the rest of the time and are able to justify them.
If nothing else, management will be more trusting in those situations if you give good and accurate estimates the rest of the time and are able to justify them.
Management, yes. Customers, no. Customers should have no expectation that they can reach into another company and manage teams and individuals like they're employees. Management should step in and make the line clear. Not just because it's counter-productive, but because it's exactly the sort of thing that upsets talented senior staff who rightly believe they deserve more respect than to be told how to do their job by someone that knows nothing about them.
There's a difference between asking an expert for their opinion and commensurate respect for the effort it takes to provide it, and demeaning an expert because you dont like their answer. I sense that OP was indicating that they felt undermined and attacked for their honest take. Being attacked for your best effort is also toxic
[deleted]
Sometimes they legitimately don't know. It's a good opportunity to help them understand how much work goes into what you do.
I recommend not default-reacting to "why does it take so long? Isn't it just A, B, and C?" as an expression of pushback, but rather just as an expression of honest confusion.
I recommend not default-reacting to "why does it take so long? Isn't it just A, B, and C?" as an expression of pushback, but rather just as an expression of honest confusion.
But OP is saying they consistently do this. At that point, it's a pattern, and it's intentional.
And I do agree with OP: every company does this. They want to squeeze every bit of work out of you, and this comes in other forms, not just through 'agile estimates'. Communications across teams that emphasize 'work-hard play-hard' also fall under this, and the 'play-hard' never actually comes. It's just new time-crunched work that gets dumped onto you. Or 'move-fast teams', or 'OKRs', etc.
The entire corporate infrastructure and communications is designed around pressuring workers to work more and more. Sure, there might be some great managers that can push back, but how many of them have you encountered across all the jobs you've been at? Most of my experiences have been what OP has said, most teams are terrible.
It's not a coincidence that the Tech Burnout Index is almost 43% across all of tech. Which means any job you jump to will have a good chance to burn you out some way or another. Which means all the crap that developers experience that burns them out is nearly ubiquitous, including being constantly grilled on estimates.
Burnout Index: https://f.hubspotusercontent30.net/hubfs/7677235/The%20State...
And I do agree with OP: every company does this. They want to squeeze every bit of work out of you, and this comes in other forms, not just through 'agile estimates'. Communications across teams that emphasize 'work-hard play-hard' also fall under this, and the 'play-hard' never actually comes. It's just new time-crunched work that gets dumped onto you. Or 'move-fast teams', or 'OKRs', etc.
The entire corporate infrastructure and communications is designed around pressuring workers to work more and more. Sure, there might be some great managers that can push back, but how many of them have you encountered across all the jobs you've been at? Most of my experiences have been what OP has said, most teams are terrible.
It's not a coincidence that the Tech Burnout Index is almost 43% across all of tech. Which means any job you jump to will have a good chance to burn you out some way or another. Which means all the crap that developers experience that burns them out is nearly ubiquitous, including being constantly grilled on estimates.
Burnout Index: https://f.hubspotusercontent30.net/hubfs/7677235/The%20State...
Even if it's consistent behaviour, I'd consistently answer the same way, treating it as honest ignorance. Tasks always look simpler from the outside.
If that conversation is happening with senior management, it can also identify some consistent mismatch between their perception and reality. (Didn't your team get 5 new hires last year? Yes but two are on leave and we also took over responsibility for customer-facing documentation from marketing). Or reveal new priorities when consistent themes come up -- maybe the testing process is being slowed down by a growing matrix of product configurations, and management had no idea how much work that creates.
When the language shifts to something like "regardless of your estimate, we need it done by the end of Q3, so make it happen", then I treat it as pushback.
If that conversation is happening with senior management, it can also identify some consistent mismatch between their perception and reality. (Didn't your team get 5 new hires last year? Yes but two are on leave and we also took over responsibility for customer-facing documentation from marketing). Or reveal new priorities when consistent themes come up -- maybe the testing process is being slowed down by a growing matrix of product configurations, and management had no idea how much work that creates.
When the language shifts to something like "regardless of your estimate, we need it done by the end of Q3, so make it happen", then I treat it as pushback.
> Even if it's consistent behaviour, I'd consistently answer the same way, treating it as honest ignorance.
This has been how I handled issues, yet I'm getting more convinced that it is not productive.
People don't learn through only repeated exposure. In the second time something happens, they should be reminded of the first time. And in the third time, they should be outright denied any explanation with a reminder of the first two incidents. Otherwise, they'll keep doing the same thing, probably because it's very low-cost to them, and I'll keep spending my precious resources.
This has been how I handled issues, yet I'm getting more convinced that it is not productive.
People don't learn through only repeated exposure. In the second time something happens, they should be reminded of the first time. And in the third time, they should be outright denied any explanation with a reminder of the first two incidents. Otherwise, they'll keep doing the same thing, probably because it's very low-cost to them, and I'll keep spending my precious resources.
> Sometimes they legitimately don't know. It's a good opportunity to help them understand how much work goes into what you do.
In my experience, they definitely don't know. But no amount of explanation is going to do it for them; any explanation is going to be met with stuff like "well, there must be a simpler way", which is a hell of a statement when it comes from someone who has no idea what they're talking about.
And oftentimes, at the point where you're making the estimate, you don't know how long "A, B, and C" are going to take. You might know how long they will take if the system underpinning "A, B, and C" do their jobs, but they inevitably won't do their jobs, and the extra time is usually working around the failings in systems that you have no choice but to use.
In my experience, they definitely don't know. But no amount of explanation is going to do it for them; any explanation is going to be met with stuff like "well, there must be a simpler way", which is a hell of a statement when it comes from someone who has no idea what they're talking about.
And oftentimes, at the point where you're making the estimate, you don't know how long "A, B, and C" are going to take. You might know how long they will take if the system underpinning "A, B, and C" do their jobs, but they inevitably won't do their jobs, and the extra time is usually working around the failings in systems that you have no choice but to use.
It’s the telling the team how to do their job I find disrespectful. If all they were asking for was more information on the estimates, it’d be a different story.
The presumption in their attitude and approach is that our team doesn’t know what they’re doing and they could do it better, even though they haven’t put in the effort to do the scoping.
The presumption in their attitude and approach is that our team doesn’t know what they’re doing and they could do it better, even though they haven’t put in the effort to do the scoping.
To be honest, I think that is in your head. Why? Because I've been on both sides of these conversations, you need something done the other companies engineer says it's going to be X and you want to know why since to you it seems rather simple but you don't know all the things that happen in the other system so what on the face of it can be simple. I've also got to explain to other people why task X is delayed by the third party and why what seems like a simple task is now taking a lot longer.
I think it's more than you're being questioned and you don't like that and feel like your word should be enough.
I think it's more than you're being questioned and you don't like that and feel like your word should be enough.
It’s fairly normal for customers to try to negotiate schedule and price. Don’t feel disrespected. A good buyer will take whatever you are ready to give them. No boundaries are being crossed.
It’s therefore the role of the salesperson/whoever is in charge of the client at this point to set clear boundaries. It doesn’t have to be extremely adversarial. You have to understand why your customers is trying to push there in case there is something to address - for example if they think you are underdelivering that needs to be worked on - then explain what can move to find a solution - typically reducing scope or raising the budget to go faster - and stand firm on what can’t.
If you can’t emotionally deal with this process which is a job in and of itself you need to put someone who can in between you and your customer.
It’s therefore the role of the salesperson/whoever is in charge of the client at this point to set clear boundaries. It doesn’t have to be extremely adversarial. You have to understand why your customers is trying to push there in case there is something to address - for example if they think you are underdelivering that needs to be worked on - then explain what can move to find a solution - typically reducing scope or raising the budget to go faster - and stand firm on what can’t.
If you can’t emotionally deal with this process which is a job in and of itself you need to put someone who can in between you and your customer.
In previous jobs where we were negotiating with non-technical people, they'd actually negotiate at the business requirement level: "if we take out features B and C, how much would that reduce the cost?"
That to me seems like a far more reasonable negotiation strategy.
To tell someone how they should be doing their job, I find, is disrespectful.
But I agree, putting someone more emotionally capable between the team and the customer is probably the best way forward there.
That to me seems like a far more reasonable negotiation strategy.
To tell someone how they should be doing their job, I find, is disrespectful.
But I agree, putting someone more emotionally capable between the team and the customer is probably the best way forward there.
> To tell someone how they should be doing their job, I find, is disrespectful.
You are taking things too personally here. As a consultant I have been working fairly regularly in the past few years on large software projects for some of my customers. That has involved being in charge of formally setting business requirements and negotiating price and schedule for scope modifications with their providers.
I will systematically challenge any provider planning for a few reasons:
- If they fold straight away, it’s a free win for me and I have children to feed.
- I will myself pad a planning when I am in the reverse position to give me leeway in negotiation and I don’t want to leave all of that on the table.
- Keeping a moderate amount of pressure on my providers will help me in futur negotiations. I want them to leave the table feeling I made some concessions.
- Having my providers be late is extremely advantageous for me. On large projects it’s a quasi-certainty that at some point they are going to complain about scope creeps or delays in writing the specs and ask for money. If they delivered late, I have something to push back with especially if penalties are involved.
- I am also systematically negotiating hard with companies which did themselves do it. If finding a price with your company was a pain, I am likely to retaliate on scope and schedule.
If you are strictly working on the technical side, you are probably not privy to most that. A significant part of what’s happening might not even be related to you or the quality of your estimation at all.
You are taking things too personally here. As a consultant I have been working fairly regularly in the past few years on large software projects for some of my customers. That has involved being in charge of formally setting business requirements and negotiating price and schedule for scope modifications with their providers.
I will systematically challenge any provider planning for a few reasons:
- If they fold straight away, it’s a free win for me and I have children to feed.
- I will myself pad a planning when I am in the reverse position to give me leeway in negotiation and I don’t want to leave all of that on the table.
- Keeping a moderate amount of pressure on my providers will help me in futur negotiations. I want them to leave the table feeling I made some concessions.
- Having my providers be late is extremely advantageous for me. On large projects it’s a quasi-certainty that at some point they are going to complain about scope creeps or delays in writing the specs and ask for money. If they delivered late, I have something to push back with especially if penalties are involved.
- I am also systematically negotiating hard with companies which did themselves do it. If finding a price with your company was a pain, I am likely to retaliate on scope and schedule.
If you are strictly working on the technical side, you are probably not privy to most that. A significant part of what’s happening might not even be related to you or the quality of your estimation at all.
Seems relevant:
https://ih1.redbubble.net/image.875440864.2771/raf,750x1000,...
Signs like this are so common at mechanics' shops that they're practically a cliché.
Text:
$100 / hr minimum
$150 / hr if you watch
$175 / hr if you help
$200 / hr if you worked on it first
$250 / hr if you tell me how to do my job
https://ih1.redbubble.net/image.875440864.2771/raf,750x1000,...
Signs like this are so common at mechanics' shops that they're practically a cliché.
Text:
$100 / hr minimum
$150 / hr if you watch
$175 / hr if you help
$200 / hr if you worked on it first
$250 / hr if you tell me how to do my job
> if you worked on it first
I'd walk right out the door if I saw that. What kind of entitled baby Steve Jobs wannabe thinks they're the only one allowed to work on MY car? I'd sooner scrap it than support this behavior.
I'd walk right out the door if I saw that. What kind of entitled baby Steve Jobs wannabe thinks they're the only one allowed to work on MY car? I'd sooner scrap it than support this behavior.
> I'd walk right out the door if I saw that.
That's your right, of course. But as a likely computer-savvy person, you've probably seen examples of why this joke exists.
You may have had to help family members with computer problems who first spent an hour clicking away and downloading shady tools trying 20 different things trying to solve something and have seen firsthand how their own attempts to fix a problem sometimes messed up the situation even more.
I've had a family member delete some important software configuration file because they thought that the filename had some profanity in it and thought it was therefore a computer virus.
I wouldn't dissuade anybody from trying to solve their own problems, but people with a little knowledge can be very dangerous when trying to fix stuff.
That's your right, of course. But as a likely computer-savvy person, you've probably seen examples of why this joke exists.
You may have had to help family members with computer problems who first spent an hour clicking away and downloading shady tools trying 20 different things trying to solve something and have seen firsthand how their own attempts to fix a problem sometimes messed up the situation even more.
I've had a family member delete some important software configuration file because they thought that the filename had some profanity in it and thought it was therefore a computer virus.
I wouldn't dissuade anybody from trying to solve their own problems, but people with a little knowledge can be very dangerous when trying to fix stuff.
If it's actually just a joke then it's not a big deal. I have dealt with a very annoying parent screwing up every single setting on a phone.
Eh, it's a joke about shitty DIY jobs. And you'll be walking out of every mechanic save some (some!) big chains, I expect, if that's a deal-breaker. Signs along these lines are pretty common.
One guy near me whined about the fact that a different mechanic touched my brakes, not even me. Never going back to that weirdo. Everyone else understands they're not Steve Jobs. I've worked on most systems in my car myself and it doesn't even come up.
Well, sure, in practice someone who actually knows what they're doing also won't cause problems, even if they do happen to be the vehicle's owner. I assume these signs are so popular because just about every mechanic thinks they're funny, and they think they're funny because they have all seen bad versions of these kinds of customers, probably a lot, and likely far more than they see any kind of good version of these.
> To me this is insanely disrespectful of the team, and it seems as though it's a boundary violation on some level.
> Has anyone found a healthy, emotionally mature response to this line of questioning? Ideally one that results in the customer understanding that they're crossing a boundary of sorts here.
TBH, I don't see what the big deal is. Give them the data and explain the thought process that went into making the estimate. And if you don't have any of that to give them, then I think they're justified in questioning the estimate.
If you don't like it, switch to regular releases, and tell them the feature will be in the next quarterly release.
> Has anyone found a healthy, emotionally mature response to this line of questioning? Ideally one that results in the customer understanding that they're crossing a boundary of sorts here.
TBH, I don't see what the big deal is. Give them the data and explain the thought process that went into making the estimate. And if you don't have any of that to give them, then I think they're justified in questioning the estimate.
If you don't like it, switch to regular releases, and tell them the feature will be in the next quarterly release.
Here is an exercise that might be helpful. As a developer, estimate was my number one fear, right before public speaking, and behind death. So I record myself in a self-zoom call explaining why I made the decision I made.
On the first recording, I rambled for 15 minutes why I think it will take n weeks and cost x dollars. Rewatching it was painful. But it gives you a good idea what to take out.
After the 10th recording, 2 minutes was enough to give the estimate and give a rough description of the work that needs to get done.
Also, you'll have to make 10 wrong estimates before you build up the skin you need to say you stand by your decision. Just because your clients are engineers, it doesn't mean they know what it takes for another team to do the work.
On the first recording, I rambled for 15 minutes why I think it will take n weeks and cost x dollars. Rewatching it was painful. But it gives you a good idea what to take out.
After the 10th recording, 2 minutes was enough to give the estimate and give a rough description of the work that needs to get done.
Also, you'll have to make 10 wrong estimates before you build up the skin you need to say you stand by your decision. Just because your clients are engineers, it doesn't mean they know what it takes for another team to do the work.
Death: the zeroeth fear.
Very self-aware. I like this
Sounds like you know what it will take, but that many of the tasks involve iteration or admin stuff that you feel embarrassed to put a price on. So you would rather not talk about those things. I think the answer is to practice feeling for yourself that all of the time is well spent.
A big problem can be that the customer wants you to treat some tasks as worthless or free (or your problem as overhead), because they might be treated that way internally. You will not have a good time with that, so might as well stick to your guns.
The other problem is that often the customer is doing this because it has worked in the past. You can say that while others have salespeople that treat estimates as haggling - leaving others to do the work, you prefer to offer estimates based on project success not bonus money.
In both cases you are going to want to get comfortable defending your practices. You can ask satisfied customers what they liked about working with you and might get your talking points!
A big problem can be that the customer wants you to treat some tasks as worthless or free (or your problem as overhead), because they might be treated that way internally. You will not have a good time with that, so might as well stick to your guns.
The other problem is that often the customer is doing this because it has worked in the past. You can say that while others have salespeople that treat estimates as haggling - leaving others to do the work, you prefer to offer estimates based on project success not bonus money.
In both cases you are going to want to get comfortable defending your practices. You can ask satisfied customers what they liked about working with you and might get your talking points!
If you get this pushback from a few of your customers, you should probably just politely explain the reasoning behind your time estimates.
If you get this pushback from most of your customers, that means your team is widely perceived as underperforming. If you're the manager or a leader on the team, you should do something about this.
First, you have to be honest with yourself. Maybe your team is underperforming because of the people on the team. Maybe some of the engineers on the team are underperforming, because they aren't able to meet the standards of your organization, and they should be managed out.
There are a couple other possibilities. Your team could be underperforming because it lacks some underlying infrastructure. For example, minor changes might take too long because the test infrastructure is too slow. You might be dependent on some other team which is too slow. You might really need to invest some effort in improving underlying automation. The right course of action depends on the underlying facts, but basically, maybe there is some medium-term plan that can improve this, and you should figure out how to do it.
The final possibility is that there's nothing you can do except communicate better that people should lower their expectations of your team. Just mentally prepare yourself to have a lot of this sort of conversation forever.
If you get this pushback from most of your customers, that means your team is widely perceived as underperforming. If you're the manager or a leader on the team, you should do something about this.
First, you have to be honest with yourself. Maybe your team is underperforming because of the people on the team. Maybe some of the engineers on the team are underperforming, because they aren't able to meet the standards of your organization, and they should be managed out.
There are a couple other possibilities. Your team could be underperforming because it lacks some underlying infrastructure. For example, minor changes might take too long because the test infrastructure is too slow. You might be dependent on some other team which is too slow. You might really need to invest some effort in improving underlying automation. The right course of action depends on the underlying facts, but basically, maybe there is some medium-term plan that can improve this, and you should figure out how to do it.
The final possibility is that there's nothing you can do except communicate better that people should lower their expectations of your team. Just mentally prepare yourself to have a lot of this sort of conversation forever.
We moved to a somewhat set release cadence and then instead of discussing timeline estimates with clients, we discussed release scoping and what was in the next release(s).
It had a helpful effect of abstracting the development team and helped shift the conversation away from button clicking towards a ‘product increment’ and all the extras it entails, but also from the customers perspective it helped engage them on a more meaningful level - prioritization of features vs the technical steps the dev team would be performing.
Then we avoided justifying timeline in favour of ‘if you wanted it for next release, we’d need to drop a/b/c or add resources x/y/z’ beyond a cursory ‘it adds some complexity with the other module’ etc.
It had a helpful effect of abstracting the development team and helped shift the conversation away from button clicking towards a ‘product increment’ and all the extras it entails, but also from the customers perspective it helped engage them on a more meaningful level - prioritization of features vs the technical steps the dev team would be performing.
Then we avoided justifying timeline in favour of ‘if you wanted it for next release, we’d need to drop a/b/c or add resources x/y/z’ beyond a cursory ‘it adds some complexity with the other module’ etc.
Whenever this is possible, I really like this approach. It emphasises what the most immediate constraint is (capacity to perform development) and forces prioritization within that constraint, rather than trying to ignore the constraint and see what happens.
This sounds closer to Shape Up/appetite over estimates. It's probably too late for OP to respond and adopt right this moment, but is a great approach going forward. I wrote up a tl;dr on this at https://dylanfitzgerald.net/blog/appetite_not_estimate/ if you're so inclined.
You can calibrate your estimations skills. This means that if you say, "there's a 50 % chance it is done before this day", 20 times, then in 10 of them it is done by that day, and in 10 of them it gets done later than that day.
Perhaps more usefully, it also means that if you say "there's a 90 % chance it is done before this day" then 18 times out of 20 will it be done by that day, and only around two times will it be late.
I have calibrated my estimation skill, so whenever someone challenges my estimation, I urge them to keep score and find out that I'm right just as often as I claim to be.
(If I'm particularly bold, I suggest a bet. I'm confident enough to make money on it in the long run.)
However, usually it doesn't get that far. Once I start explaining that it's a probabilistic measure of high certainty customers and managers back off.
----
Some people want to be reassured that I don't plan on taking as long as my 90 % estimation suggests, so then I give them something like a 10 %--90 % span and say, "it's unlikely to be done before this day, but also unlikely to be later than this. This interval is wide today because there are many uncertainties for me. As I learn more about the problem, this interval will narrow."
Perhaps more usefully, it also means that if you say "there's a 90 % chance it is done before this day" then 18 times out of 20 will it be done by that day, and only around two times will it be late.
I have calibrated my estimation skill, so whenever someone challenges my estimation, I urge them to keep score and find out that I'm right just as often as I claim to be.
(If I'm particularly bold, I suggest a bet. I'm confident enough to make money on it in the long run.)
However, usually it doesn't get that far. Once I start explaining that it's a probabilistic measure of high certainty customers and managers back off.
----
Some people want to be reassured that I don't plan on taking as long as my 90 % estimation suggests, so then I give them something like a 10 %--90 % span and say, "it's unlikely to be done before this day, but also unlikely to be later than this. This interval is wide today because there are many uncertainties for me. As I learn more about the problem, this interval will narrow."
In some implementations of Agile this is supposed to be the point of the team velocity. Not that you make the engineers change the way they feel about tasks, but instead discover the hidden rate of delivery.
That's also a way to do it! I prefer making it explicit at the lowest level -- it's nice to be able to ask someone for a probability and know that it's accurate. It also helps them grow as people and professionals.
"Estimates are non-negotiable." - https://www.amazon.com/Software-Estimation-Demystifying-Deve...
You should start way earlier in the process. If you get at that point you have almost no leverage and if you have to deal with people that don't listen to you.
In my own experience it's a two-fold process:
- one is the ability of the engineering manager and the product manager to work towards a phased approach (smaller iterations means better chances at hitting the deadlines/estimations -if any)
- the other one, by working closely with your stakeholders, so they have a good understanding of what's going on and the status of the team, effectively building a trust relationship.
In my own experience it's a two-fold process:
- one is the ability of the engineering manager and the product manager to work towards a phased approach (smaller iterations means better chances at hitting the deadlines/estimations -if any)
- the other one, by working closely with your stakeholders, so they have a good understanding of what's going on and the status of the team, effectively building a trust relationship.
I run into this with clients all the time. It's basically a two part conversation for me:
1. A quick (few paragraph) run through of where I see the complexity that led to the estimate. This often reassures people, sometimes helps us discover a disconnect on the requirements (where I imagined something more complex than they needed), and is sometimes a waste of breath.
2. When (1) doesn't change anything "I don't litigate estimates. Based on our discussion this is my best guess at when I will be able to finish this for you, not a fixed bid. If I'm done early you'll get it early."
1. A quick (few paragraph) run through of where I see the complexity that led to the estimate. This often reassures people, sometimes helps us discover a disconnect on the requirements (where I imagined something more complex than they needed), and is sometimes a waste of breath.
2. When (1) doesn't change anything "I don't litigate estimates. Based on our discussion this is my best guess at when I will be able to finish this for you, not a fixed bid. If I'm done early you'll get it early."
I'm not quite sure how to phrase it, but I'd try to change the way you're talking about it. You're not negotiating the amount of time it'll take. You're discussing what it would mean for it to take shorter or longer.
For example: "if you want it done in 2 weeks instead of 2 months, we can get to X functionality while sacrificing Y." Or: "what would it mean for you if we were to get this done in 2 months instead of two weeks? How would it affect you?" Basically: try to get to more of the root of why they're questioning your estimates without putting on the table the notion that you can magically change the truth about how much time things will take.
As others have said, also express your degree of uncertainty. Try to leave your ego out of it and make sure you're not giving them some sort of subconscious ammo that you're hiding something or being manipulative.
> To me this is insanely disrespectful of the team, and it seems as though it's a boundary violation on some level.
You're right, but if their deep belief is that your team just isn't adequate, you need to force them to bring it up. Yes, it will be insulting to find this out, but people tend to dance around these things with euphemisms and coded language, and one of the best things you can do is get it out in the open.
For example: "if you want it done in 2 weeks instead of 2 months, we can get to X functionality while sacrificing Y." Or: "what would it mean for you if we were to get this done in 2 months instead of two weeks? How would it affect you?" Basically: try to get to more of the root of why they're questioning your estimates without putting on the table the notion that you can magically change the truth about how much time things will take.
As others have said, also express your degree of uncertainty. Try to leave your ego out of it and make sure you're not giving them some sort of subconscious ammo that you're hiding something or being manipulative.
> To me this is insanely disrespectful of the team, and it seems as though it's a boundary violation on some level.
You're right, but if their deep belief is that your team just isn't adequate, you need to force them to bring it up. Yes, it will be insulting to find this out, but people tend to dance around these things with euphemisms and coded language, and one of the best things you can do is get it out in the open.
Your job is to insulate your team from the normal course of business (customer negotiating) so that they don't feel like it's "insanely disrespectful." Your job is to process it unemotionally and handle it unemotionally. Let the customer say whatever the customer is going to say and then respond with a boilerplate like "We've considered these possibilities and appreciate the input but we are not flexible on our original estimate."
Rule 1 - Keep your code quality up enough to manage the level of realiability that the business demands and needs.
Rule 2 - When questioned on estimates, say "The business needs XXX level of reliability and we have built our software and release practice up to the level we can deliver on that. The estimate takes into account this process, qa, defect cycles, and release constraints." and do not deviate from it.
Unless Rule 3 - Deviate the heck out of it if your estimates plainly suck. :)
Rule 2 - When questioned on estimates, say "The business needs XXX level of reliability and we have built our software and release practice up to the level we can deliver on that. The estimate takes into account this process, qa, defect cycles, and release constraints." and do not deviate from it.
Unless Rule 3 - Deviate the heck out of it if your estimates plainly suck. :)
To share my anecdote, the place where I work often pits engineers' solutions/estimates against eachother and then picks & promotes the "fastest" one. Never mind that typically these faster estimates typically overrun to make them equal in retrospect, oh and come with bugs and needed improvements that will only be "discovered" by customers over the next 24 months...
le sigh
/rant
le sigh
/rant
This is basically how government contracting to the lowest bidder works too. The penalty for overshooting your budget by a lot is far less severe than missing out on the contract.
so what's the solution?
Maybe we can make engineers work for free until they deliver what they promised? (that's sarcasm btw).
Maybe we can make engineers work for free until they deliver what they promised? (that's sarcasm btw).
"Our estimates are based on many interdependent factors. If you'd like to book an hour slot (paid) with one of our consultants they would be happy to go over the details with you."
I used to give them data, conversation was much easier, repeating my comment[1]
I take data from previous feature requests that were completed and number of bugs reported/refactoring etc. to create a rough cost estimate for maintenance in terms of man hours with the understanding that this is not perfect and there could be +-10% variation and this is only an estimate for planning. It worked well for me, other org's were not able to argue with me as i just showed them the data. Estimates were surprisingly accurate(its anecdotal) but i did not saw estimates overshooting/undershooting the +-10% variation. Later on this was adopted by the whole organization. I left but my guess is they are still using the same methodology
[1]https://news.ycombinator.com/item?id=31106593
I take data from previous feature requests that were completed and number of bugs reported/refactoring etc. to create a rough cost estimate for maintenance in terms of man hours with the understanding that this is not perfect and there could be +-10% variation and this is only an estimate for planning. It worked well for me, other org's were not able to argue with me as i just showed them the data. Estimates were surprisingly accurate(its anecdotal) but i did not saw estimates overshooting/undershooting the +-10% variation. Later on this was adopted by the whole organization. I left but my guess is they are still using the same methodology
[1]https://news.ycombinator.com/item?id=31106593
Something like: "I understand that this presents a challenge, but we have to test and support this code while continuing to meet our other commitments, and this represents our best estimate for the time required to accomplish this work."
This is a thought-terminating cliche (https://en.wikipedia.org/wiki/Thought-terminating_clich%C3%A...), i.e. saying nothing politely. It contains no information; its purpose is to close that topic and pivot to a new one - discussing a different team doing the work, changing the ask, hiring contractors, etc.
> Ideally one that results in the customer understanding that they're crossing a boundary of sorts here.
A great low-conflict way to convey this is by being more formal/icy in your phrasing than usual.
This is a thought-terminating cliche (https://en.wikipedia.org/wiki/Thought-terminating_clich%C3%A...), i.e. saying nothing politely. It contains no information; its purpose is to close that topic and pivot to a new one - discussing a different team doing the work, changing the ask, hiring contractors, etc.
> Ideally one that results in the customer understanding that they're crossing a boundary of sorts here.
A great low-conflict way to convey this is by being more formal/icy in your phrasing than usual.
This is the problem estimation in disconnected units like story points is supposed to solve. Team: “We estimate that solving this problem will take two elephants and a gazelle, we came to this estimate by using our best guesses informed by our expertise on the matter”. Manager: “well I can’t disagree that that is your estimate.” Scrum master: “based on past performance, two elephants and a gazelle will take 5 weeks to complete.” Manager: “well I can’t disagree that this is what past performance tells us.”
In reality what happens is that you end up having a manager in your estimation meetings telling you that one of the elephants have to be a gazelle, because he needs to make a deadline and believes that forcing your estimate will somehow bend reality to conform to it.
In reality what happens is that you end up having a manager in your estimation meetings telling you that one of the elephants have to be a gazelle, because he needs to make a deadline and believes that forcing your estimate will somehow bend reality to conform to it.
As a PM who has often had to take developer estimates to management meetings only to have them questioned, I've found a couple of things that work:
1. If there's something unintuitive to a non-technical person, call that up out front as a reason for the estimate. For example, if you're estimating how long it'll take to implement a popup, but there's some piece of information displayed in the popup that you need to get from some archaic system that is held together with tape and glue, you might come up with an estimate that seems very large to someone who thinks all you're doing is implementing a popup. When this happens, it's best to call it out up front when giving the estimate, as opposed to giving a big estimate and then giving the explanation only when questioned.
2. On a related note, give options. This works very well with toddlers (don't tell them they have to put on pajamas, ask them if they want to put on the red ones or the blue ones) but also often with PMs and management. In the prior example, instead of saying that it's going to take three weeks, say that it's going to take three weeks, but two weeks of that is because you have to pull this one piece of information from that archaic system. If we could go without displaying that piece of information, then the estimate is a week. If we could instead display this similar piece of information that's easier to get, then the estimate is a week and a half. When you do this, you come off as thoughtful and prepared, and you put the people you're talking to in a position where they feel like they've done something by making a choice.
People generally question estimates because of a lack of context, so when they do so, I really encourage you to think of it not as them not trusting you, but rather as them attempting to get the context they need to understand.
Some people do also question estimates because they feel like it's their job to haggle developers down (these people are annoying and do not represent most PMs). Number 2 above is a good way of dealing with this - it turns it from haggling into a negotiation over scope.
1. If there's something unintuitive to a non-technical person, call that up out front as a reason for the estimate. For example, if you're estimating how long it'll take to implement a popup, but there's some piece of information displayed in the popup that you need to get from some archaic system that is held together with tape and glue, you might come up with an estimate that seems very large to someone who thinks all you're doing is implementing a popup. When this happens, it's best to call it out up front when giving the estimate, as opposed to giving a big estimate and then giving the explanation only when questioned.
2. On a related note, give options. This works very well with toddlers (don't tell them they have to put on pajamas, ask them if they want to put on the red ones or the blue ones) but also often with PMs and management. In the prior example, instead of saying that it's going to take three weeks, say that it's going to take three weeks, but two weeks of that is because you have to pull this one piece of information from that archaic system. If we could go without displaying that piece of information, then the estimate is a week. If we could instead display this similar piece of information that's easier to get, then the estimate is a week and a half. When you do this, you come off as thoughtful and prepared, and you put the people you're talking to in a position where they feel like they've done something by making a choice.
People generally question estimates because of a lack of context, so when they do so, I really encourage you to think of it not as them not trusting you, but rather as them attempting to get the context they need to understand.
Some people do also question estimates because they feel like it's their job to haggle developers down (these people are annoying and do not represent most PMs). Number 2 above is a good way of dealing with this - it turns it from haggling into a negotiation over scope.
I just give them my third-best murderous glare and ask them, "You want me to test this, right?"
You probably won't like this but it's your attitude that's the problem. Change it. You assume you are infallible and smacks of sanctimoniousness. Now, you are entitled to such feelings if the clients were some finance suits with no idea of tech, but by your own admission they are not only engineers but also former devs. Just engage in the discussion, who knows there might be solutions lurking there if you take off your shades and earplugs.
Link them to this:
http://johnsalvatier.org/blog/2017/reality-has-a-surprising-...
We've all been bitten by the "it'll just be x, y, and z, no big deal" engineering bias when we plan a system in our head.
Reality has a lot more detail than mental planning does.
http://johnsalvatier.org/blog/2017/reality-has-a-surprising-...
We've all been bitten by the "it'll just be x, y, and z, no big deal" engineering bias when we plan a system in our head.
Reality has a lot more detail than mental planning does.
There are a few things you can do to improve the conversation and relationship:
- Get support from top management on the client-side. Provide quality metrics quarterly (number of bugs reported, releases, etc.) and show positive trends.
- Iterate faster - like every week, and show what has been delivered. Prioritize what has actual value for your clients., and let them provide feedback.
- Make your clients have skin in the game. The problem with folks challenging estimates is that they are not involved in the process, e.g., they are not contributing to the product. Without being involved, they can only provide feedback such as "I don't understand...". It would help if you found a way of having them contribute to the product, and the conversation will change from estimates to the product's actual value. Ask them to review features, prioritize, read release notes, suggest improvements, share their experience with other clients, etc. If you have ways to open your product and processes, it should help.
- Get support from top management on the client-side. Provide quality metrics quarterly (number of bugs reported, releases, etc.) and show positive trends.
- Iterate faster - like every week, and show what has been delivered. Prioritize what has actual value for your clients., and let them provide feedback.
- Make your clients have skin in the game. The problem with folks challenging estimates is that they are not involved in the process, e.g., they are not contributing to the product. Without being involved, they can only provide feedback such as "I don't understand...". It would help if you found a way of having them contribute to the product, and the conversation will change from estimates to the product's actual value. Ask them to review features, prioritize, read release notes, suggest improvements, share their experience with other clients, etc. If you have ways to open your product and processes, it should help.
> All you have to do is A, B and C
I'd inquire why they are saying that. Are there requirements in your proposal that aren't required? Enterprise development best practices for instance, if the customer wants to prioritize time to production or time to market, it's normal for him to push aside writing 12 factories and 7 dlls to later/never.
I'd inquire why they are saying that. Are there requirements in your proposal that aren't required? Enterprise development best practices for instance, if the customer wants to prioritize time to production or time to market, it's normal for him to push aside writing 12 factories and 7 dlls to later/never.
1. Track actuals for work items
2. Compare new work items to actuals
3. Give range based on risk (known unknowns, unknown unknowns)
Fundamentally establish trust through transparency.
Remember most humans are trying to justify or find reasons to do something. Finding out it will take too long or be too expensive (in their eyes) is a reason not to do it. If those people have already made "positive noises" to other people, then your reality is going to run head on to theirs.
Help people, perhaps by asking up front "how much effort do you want to spend solving this".
It's not disrespectful at all. The engineering team does not exist in a vacuum independent from everyone else. What does happen is that engineers with a lack of maturity hate to have their judgment questioned.
Without knowing specifics of context, perhaps by understanding the constraints, needs of the business or limitation on budget, then any estimate you provide is going to be wrong in the eyes of the reciever.
IMO anyway.
Fundamentally establish trust through transparency.
Remember most humans are trying to justify or find reasons to do something. Finding out it will take too long or be too expensive (in their eyes) is a reason not to do it. If those people have already made "positive noises" to other people, then your reality is going to run head on to theirs.
Help people, perhaps by asking up front "how much effort do you want to spend solving this".
It's not disrespectful at all. The engineering team does not exist in a vacuum independent from everyone else. What does happen is that engineers with a lack of maturity hate to have their judgment questioned.
Without knowing specifics of context, perhaps by understanding the constraints, needs of the business or limitation on budget, then any estimate you provide is going to be wrong in the eyes of the reciever.
IMO anyway.
> To me this is insanely disrespectful of the team
The team is probably underperforming relative to the expectations. This is what it feels like to be questioned and put under pressure. It is technically disrespect.
To what standard should the team perform, and how can it be determined if it is?
Maybe make some sort of benchmarks visible that establish the competence and prestige of the team.
The team is probably underperforming relative to the expectations. This is what it feels like to be questioned and put under pressure. It is technically disrespect.
To what standard should the team perform, and how can it be determined if it is?
Maybe make some sort of benchmarks visible that establish the competence and prestige of the team.
You are right that it’s often a problem of a mismatch between your client expectations and what you are delivering but that’s not disrespectful and will probably not be sorted out with a benchmark.
From my experience, 90% of the time these mismatches come from a lack of or a flawed communication. The solution is to sit down with your customers, ask questions to understand why they feel what they feel and specifically address that. I think that in general people working in software rarely spend enough time talking with their clients.
It’s the same with managers actually. If there is a persistent mismatch between what you think you should be doing and what your manager thinks you should be doing you are not talking with your manager enough.
From my experience, 90% of the time these mismatches come from a lack of or a flawed communication. The solution is to sit down with your customers, ask questions to understand why they feel what they feel and specifically address that. I think that in general people working in software rarely spend enough time talking with their clients.
It’s the same with managers actually. If there is a persistent mismatch between what you think you should be doing and what your manager thinks you should be doing you are not talking with your manager enough.
> ... 90% of the time these mismatches come from a lack of or a flawed communication.
It's important to think about how the communication is failing.
The customer/manager might be comparing your performance with others who are faster or cheaper.
Some might have more technical experience than you; and are in effect asking you to explain and justify your solutions.
Or, they might not understand or care, while still being convinced that you are underperforming ("being incompetent").
It's important to think about how the communication is failing.
The customer/manager might be comparing your performance with others who are faster or cheaper.
Some might have more technical experience than you; and are in effect asking you to explain and justify your solutions.
Or, they might not understand or care, while still being convinced that you are underperforming ("being incompetent").
Part of the problem I pick up here is that, in general, engineers who haven't done the hard work of the actual scoping themselves tend to be wildly optimistic in their estimates.
I'm not sure if this applies to more seasoned engineer-customers though. The more experienced engineer-customers (people who've been working for 10+ years) tend to be far more understanding here.
I'm not sure if this applies to more seasoned engineer-customers though. The more experienced engineer-customers (people who've been working for 10+ years) tend to be far more understanding here.
> results in the customer understanding that they're crossing a boundary of sorts here
I think you're looking at this the wrong way. If the customer / manager want to get into the weeds with you, you should let them. Information sharing leads to good things.
Giving the customer/manager details about the work required for a feature will help them better understand and prioritize future work. If you and your team are excellent, going into the technical details will impress the customer/manager and gain you the respect you are looking for.
On the other hand, if you are defensive and withhold information, that will only erode trust and push them away. Eventually, they'll look for someone else to work with.
As a side note, scrum boards are stupid. What people really need are dependency trees.
I think you're looking at this the wrong way. If the customer / manager want to get into the weeds with you, you should let them. Information sharing leads to good things.
Giving the customer/manager details about the work required for a feature will help them better understand and prioritize future work. If you and your team are excellent, going into the technical details will impress the customer/manager and gain you the respect you are looking for.
On the other hand, if you are defensive and withhold information, that will only erode trust and push them away. Eventually, they'll look for someone else to work with.
As a side note, scrum boards are stupid. What people really need are dependency trees.
Whether you estimate something liberally or conservatively hardly matters. You're still going to have to stand trial for the cost by everyone anyway.
You get better at it with time. You'll get better at arguing your case. You'll get better at justifying certain work.
It is worthwhile to clarify to everyone that it is an estimate and not a promise. If someone tells you they can do it in half the time, then a friendly "feel free to help contribute to the project" can shut up people quickly.
If possible, try to get away from this practice and to more agile practices. That way you would be able to just talk about when you start and cease certain work or give wild ass guesses instead of wasting too much time estimating.
You get better at it with time. You'll get better at arguing your case. You'll get better at justifying certain work.
It is worthwhile to clarify to everyone that it is an estimate and not a promise. If someone tells you they can do it in half the time, then a friendly "feel free to help contribute to the project" can shut up people quickly.
If possible, try to get away from this practice and to more agile practices. That way you would be able to just talk about when you start and cease certain work or give wild ass guesses instead of wasting too much time estimating.
I provide:
* Known tasks and how long each will take (with error bars),
* An overview of known unknowns, how they might impact the project, and what research would bring them into focus,
* Then I bring up the dreaded unknown unknowns.
With reasonable leadership that usually leads to good discussions about reining in the scope.
* Known tasks and how long each will take (with error bars),
* An overview of known unknowns, how they might impact the project, and what research would bring them into focus,
* Then I bring up the dreaded unknown unknowns.
With reasonable leadership that usually leads to good discussions about reining in the scope.
I've talked to people who were pretty shocked by modern time estimates where they sounded shocking to me as well as an outsider of the org but working on the same technologies.
I think a lot of organizations add more and more requirements to "guarantee quality" after each incident and never really streamline again, so my first guess with a group that is opaque about the specifics is that it has gradually built up doing too much and only feels comfortable if it performs a lot of rituals. An idea of where you see the risks and what buffers you are using may make people more comfortable with your estimates being logical instead of the consequences of process gone awry.
I think a lot of organizations add more and more requirements to "guarantee quality" after each incident and never really streamline again, so my first guess with a group that is opaque about the specifics is that it has gradually built up doing too much and only feels comfortable if it performs a lot of rituals. An idea of where you see the risks and what buffers you are using may make people more comfortable with your estimates being logical instead of the consequences of process gone awry.
In a T&M contract they literally pay you by the hour. Not pushing back on your estimate would be negligent.
Even in a fixed price setting (there is no such thing really as your sales will be peppering them with change requests on the vague initial requirements contract anyways), the client wil want the solution ASAP as 'time is money friend'.
Software is a "lemon's market". Neither buyer nor seller has enough information and there is a huge history of failure, malpractice and outright fraud. While I feel your pain, this unfortunate reality is infertile to trust building.
I wish it could be different but I doubt it will.
Even in a fixed price setting (there is no such thing really as your sales will be peppering them with change requests on the vague initial requirements contract anyways), the client wil want the solution ASAP as 'time is money friend'.
Software is a "lemon's market". Neither buyer nor seller has enough information and there is a huge history of failure, malpractice and outright fraud. While I feel your pain, this unfortunate reality is infertile to trust building.
I wish it could be different but I doubt it will.
I would question why you are giving customers technical estimates instead of giving them expected release date.
Expected release dates should be broad, next month, next quarter, etc.
Estimated release dates take into discussion what is also being worked by development team.
Expected release dates should be broad, next month, next quarter, etc.
Estimated release dates take into discussion what is also being worked by development team.
[deleted]
I provide an initial estimate. Very high level but enough to give them the idea.
If they want details I tell them I need to bill for the time and file it under project planning. Amazingly they are happy to pay for it and we are happy to do the paperwork they require.
If they say no they won’t pay then you make a judgment call on how important that client is to you. What I have found is if they nickel and dime you then your not providing value in their eyes. Move on to a higher value client.
If they want details I tell them I need to bill for the time and file it under project planning. Amazingly they are happy to pay for it and we are happy to do the paperwork they require.
If they say no they won’t pay then you make a judgment call on how important that client is to you. What I have found is if they nickel and dime you then your not providing value in their eyes. Move on to a higher value client.
It needs some work but it goes like this:
Estimate X is 10000 (amount, time or whatever). It will come from A (5000) B (3000) and C (2000). A will come from A1 (500) A2 (1700) A3 (1300) A4 (1500). A1 is derived from A1.1 (200) A1.2 (200) A1.3 (100). The deeper you go in the analysis the more difficult it will be for anybody to check all the data and prove you wrong.
Estimate X is 10000 (amount, time or whatever). It will come from A (5000) B (3000) and C (2000). A will come from A1 (500) A2 (1700) A3 (1300) A4 (1500). A1 is derived from A1.1 (200) A1.2 (200) A1.3 (100). The deeper you go in the analysis the more difficult it will be for anybody to check all the data and prove you wrong.
First of all, that sounds like a shit situation.
If you think it'll be valuable, you could ask them why it's important that you hit their date. Most likely they're being pressured by someone else.
But at the end of the day, you own the delivery of the product. Smile, nod, and get back to delivery.
(And yes, it's easier to write that then to do it)
If you think it'll be valuable, you could ask them why it's important that you hit their date. Most likely they're being pressured by someone else.
But at the end of the day, you own the delivery of the product. Smile, nod, and get back to delivery.
(And yes, it's easier to write that then to do it)
Have them give an estimate, and see who is closer at the end of the project. Three strikes, they stop complaining.
If their estimate is always shorter than yours, they can easily accuse you of sandbagging to meet your estimate.
A lot of bosses do that I think. They accept your estimates but internally they expect you to always be under the estimate. Accusations of laziness fly eventually if you are over estimate, or even meet your estimates consistently.
A lot of bosses do that I think. They accept your estimates but internally they expect you to always be under the estimate. Accusations of laziness fly eventually if you are over estimate, or even meet your estimates consistently.
Risky. I've had a bad experience with a manager that on a similar opportunity set his own deadline and used that to put pressure on the team completely ignoring anything the team said. At the end his version was the team didn't deliver, not one bit that he was wrong. That mofo. I'm still bitter about it.
[deleted]
Sarcastic non-serious answer, but:
> Why would it possibly take so long? All you have to do is A, B and C!
We would be happy to deliver A, B and C exactly as described at the proposed time. We anticipate these problems. Happy to accept the risk?
> Why would it possibly take so long? All you have to do is A, B and C!
We would be happy to deliver A, B and C exactly as described at the proposed time. We anticipate these problems. Happy to accept the risk?
There is only one solution to it and it is called "cutting the scope". Learn them and use them in any discussion involving managers and PMs. "We will deliver X by Y if we cut A,B and C".
Offer to provide a detailed work breakdown for a ridiculous fee, but don't back down on your estimate if you believe in it. "Negotiating" like this is a waste of time and goodwill.
Personally, I don't find this disrespectful at all. It's good for stakeholders to understand what you're doing, why you're doing it that way, and what the alternatives are.
"Based on our experience, skills and expertise that we bring, this is our best estimate. Be advised that an estimate is not just writing the code but includes work for various stages including discussions, proposals, meetings, design, development, testing, user acceptance testing, fixes after testing and more other stages. Would you want me to give you a breakdown of those stages as we want to make it easy for you to understand the estimate"
Never let someone tell you your estimate is too much. If it,s too much let them do it themselves.
Never let someone tell you your estimate is too much. If it,s too much let them do it themselves.
what usually helps is to include some of your assumptions with the effort estimate - especially the ones that cause significant effort.
In a product those typically are not so much negotiable with respect to the architecture. In a project they may lead the customer to change their architecture priorities completely.
In a product those typically are not so much negotiable with respect to the architecture. In a project they may lead the customer to change their architecture priorities completely.
Did you tell them the solutions are incorrect? How did they react?
Highlight:
* Effort vs duration
* Best case vs worst case
* Levels of certainty
* Risks and how you account for them in estimate / plan to mitigate them
Etc
* Effort vs duration
* Best case vs worst case
* Levels of certainty
* Risks and how you account for them in estimate / plan to mitigate them
Etc
It depends on the team's other priorities
I feel you.
[deleted]
Whenever we tell them, for example, the team has estimated it'll take X weeks to do something, we continuously get pushback of: "Why would it possibly take so long? All you have to do is A, B and C!" (often providing incorrect solutions, increasing the burden of having to explain all possible implementation strategies to them and the risks involved with each step)
I've also experienced this in previous companies where managers, who used to be technical, do the same thing.
To me this is insanely disrespectful of the team, and it seems as though it's a boundary violation on some level.
Has anyone found a healthy, emotionally mature response to this line of questioning? Ideally one that results in the customer understanding that they're crossing a boundary of sorts here.
In an ideal world I'd much prefer to not have to give estimates in the first place, and rather involve our customers more frequently in our development process to help them see the progress. It's hard, however, to convince them of the value in this approach.