All late projects are the same (2011) [pdf](systemsguild.com)
systemsguild.com
All late projects are the same (2011) [pdf]
http://www.systemsguild.com/pdfs/DeMarcoNov2011.pdf
58 comments
Salesperson to raging customer (aftermath): "We were only able to complete the bathroom in the estimated time. You are welcome to live in it for a reduced monthly fee while we build the rest of the house around you"
In my experience new build houses and apartments are never on time either.
there was just a recently completed apartment building here which was months ahead of schedule. They tried more agile methods when doing it: daily meetings instead of weekly ones and working more in parallel. It was done by a less dinosaury company called Fira.
Generalizing, this equates to “projects fail as result of poor/dishonest communication”, which is definitely accurate.
We sure don't want it to go over time and budget like the last 10 projects.
Just need to manage the lazy developers better (read: more) this time!
More meetings will do the trick. A daily 30 minute standup, and a few alignment meetings scattered throughout the day to identify the technical causes as to why progress is slow. Let's however not go into too much technical detail, but ensure that the developers are aware of what's at stake here.
While much of this is true, I think it also leaves out a very common cause of software being late, perhaps the most common. The time it will take is unknown, in some cases unknowable, and no one is willing to say so. "How long will it take?" (equivalently, "Can you do this feature set by this date?") The only honest answer is: "I don't know." Nonetheless, a date gets put on it.
and no one is willing to say so.
On the reverse of course it makes sense to have estimates otherwise how should managers or product people decide what should be done next?
A big part of the issue is we don't have good knowledge how to estimate work. It's not a skill that is heavily invested in and is wrongly assumed as an inherent ability.
As a manager over a new project with a ridiculous release date, I'm subject to the same political bullshit as everyone else. At this point, I'm of the opinion that anything with a realistic ship date simply won't get funded. So all I do these days is commit to things that I am certain aren't achievable in the time frame on the table, just so that we can get the project off the ground in the first place. From that point, I immediately start to play the game of politics and showmanship to put together a narrative with the usual culprits for why a project is late. Shifting requirements, other teams that didn't deliver what we depended on, etc.
Then I make more promises and estimates, playing the emotional card of "sunk cost" to convince upper management to continue funding the team rather than torpedo the project. Then we ship, and I quickly get everyone on my team promoted "because we shipped" before it becomes clear to upper management that we shipped something essentially worthless to the company. Because we're in a huge profitable company, everyone can jump ship to the next shiny thing, and whoever is left holding the potato on its way to deprecation just gets re-org'd when it gets canned.
I know it's a bullshit game. But I play it well, and all the software developers on my team get paid and promoted because I am so good at it.
Then I make more promises and estimates, playing the emotional card of "sunk cost" to convince upper management to continue funding the team rather than torpedo the project. Then we ship, and I quickly get everyone on my team promoted "because we shipped" before it becomes clear to upper management that we shipped something essentially worthless to the company. Because we're in a huge profitable company, everyone can jump ship to the next shiny thing, and whoever is left holding the potato on its way to deprecation just gets re-org'd when it gets canned.
I know it's a bullshit game. But I play it well, and all the software developers on my team get paid and promoted because I am so good at it.
You're subject to the "same political bullshit" because you choose to be. You don't have to partake in it, but you do. You can choose not to, you can choose to try to bring the company around you to greener pastures - but you don't.
You sound wise and such in general, but perhaps your time would be better spent making a difference in how people believe work should be done at a place that actually allows brewing better practices instead of lauding bad ones.
You sound wise and such in general, but perhaps your time would be better spent making a difference in how people believe work should be done at a place that actually allows brewing better practices instead of lauding bad ones.
This would just result in them not managing any projects anymore, and "Yes we can do it in 2 weeks" Joe will get them instead
One day you might play it so well, you find yourself on the Board.
Will you then argue that all new projects should avoid deadline dates, that no project should have anything other than an MVP and a iteration plan after that?
How do we change the expectations?
Will you then argue that all new projects should avoid deadline dates, that no project should have anything other than an MVP and a iteration plan after that?
How do we change the expectations?
> So all I do these days is commit to things that I am certain aren't achievable in the time frame on the table, just so that we can get the project off the ground in the first place.
This is exactly the point of the article: Organizations routinely fail to prevent untenable projects from moving forward.
This is exactly the point of the article: Organizations routinely fail to prevent untenable projects from moving forward.
What I don't get about your strategy:
Why not work on something so valuable that even if it takes twice as long as the best estimate, with twice the headcount working on it, it would still be worth it?
As a a manager, I feel that helping to find projects that have that amount of value is an important part of my job, so that if I am fighting for a project my team's working on, I'm actually in the right from a business case point of view, not simply playing some BS political game.
If there are no projects that fit that value filter, then that's a completely different organizational problem.
Why not work on something so valuable that even if it takes twice as long as the best estimate, with twice the headcount working on it, it would still be worth it?
As a a manager, I feel that helping to find projects that have that amount of value is an important part of my job, so that if I am fighting for a project my team's working on, I'm actually in the right from a business case point of view, not simply playing some BS political game.
If there are no projects that fit that value filter, then that's a completely different organizational problem.
Lol holy shit, this explains so much of my experience that I never even knew.
> I know it's a bullshit game. But I play it well, and all the software developers on my team get paid and promoted because I am so good at it.
On one level I have to take my hat off to you because you sound like exactly the kind of manager - one who has your team's back - that a lot of people would want to work for.
On another level you're part of the problem: you're wasting organisational resources that could be better and more profitably used elsewhere.
Still, needs must I suppose, because the real fault here - as the article itself hints - is in the determination of what the most valuable use of everyone's time is. I.e., if projects are going to be late (and they are) then you ought only to deploy teams to work on the ones with a putative 10x ROI.
On one level I have to take my hat off to you because you sound like exactly the kind of manager - one who has your team's back - that a lot of people would want to work for.
On another level you're part of the problem: you're wasting organisational resources that could be better and more profitably used elsewhere.
Still, needs must I suppose, because the real fault here - as the article itself hints - is in the determination of what the most valuable use of everyone's time is. I.e., if projects are going to be late (and they are) then you ought only to deploy teams to work on the ones with a putative 10x ROI.
Though this be madness, yet there is method in ‘t
I had this experience recently. We don't use a lot of detailed estimates in my team, because the work needs to be done regardless, and the estimates are then largely a waste of time.
But there was one occasion, where a product launch had been announced by a C*O before the product was finished, and the engineers were very clear that this launch date was impossible. So there was a lot of drama and bad feelings, and the engineering team eventually said, "okay, let's make a detailed estimate so we can be certain". The estimate came in at three weeks development time, one week after the announced launch date.
One week of the estimate was meant for testing and fixing problems that are found in testing. The business experts immediately jumped on this: "Testing and fixing unplanned errors won't be a big deal and certainly not a whole week. We'll skip that so we can get it done in two weeks".
Thankfully, this is retail banking, so releasing an obviously broken product flies even less than missing the deadline. The product was eventually launched uneventfully, one week after the detailed estimate and two weeks after the announced launch date. All in all a success.
But there was one occasion, where a product launch had been announced by a C*O before the product was finished, and the engineers were very clear that this launch date was impossible. So there was a lot of drama and bad feelings, and the engineering team eventually said, "okay, let's make a detailed estimate so we can be certain". The estimate came in at three weeks development time, one week after the announced launch date.
One week of the estimate was meant for testing and fixing problems that are found in testing. The business experts immediately jumped on this: "Testing and fixing unplanned errors won't be a big deal and certainly not a whole week. We'll skip that so we can get it done in two weeks".
Thankfully, this is retail banking, so releasing an obviously broken product flies even less than missing the deadline. The product was eventually launched uneventfully, one week after the detailed estimate and two weeks after the announced launch date. All in all a success.
I have, on more than one occasion, said so, and the response was always bafflement or annoyance, and in either case and unwillingness to accept that answer. When I was younger, I would eventually give a guess, along with a "...but that's just a guess". Nowadays, I don't even give that, because the caveats get forgotten/ignored.
I have this sort of discussion, at minimum, three times a week (we're in-house developers). Very often the project scope isn't even defined and upstream dependencies are known to be critically lacking and will need to be augmented to even perform the work. Yet we're always pressured for dates and the caveats given are immediately forgotten and almost never communicated.
The biggest pet peeve is when I give an estimate such as "I don't currently see a reason why we can't deliver X by the end of next week, assuming no other priorities come up." Of course something more important comes up in the mean time and I get scolded in a large meeting with a statement such as "You promised me I'd have X by Friday!" — this is especially infuriating when it is the PM's other project that is the higher priority interruption.
The biggest pet peeve is when I give an estimate such as "I don't currently see a reason why we can't deliver X by the end of next week, assuming no other priorities come up." Of course something more important comes up in the mean time and I get scolded in a large meeting with a statement such as "You promised me I'd have X by Friday!" — this is especially infuriating when it is the PM's other project that is the higher priority interruption.
It might not be viable, but I used to "publish" internally my own project one pagers, and update the timelines - any discrepancies simply became a shield for this future arguments.
In short it sounds like you don't have the power to say no - but actually you do.
In short it sounds like you don't have the power to say no - but actually you do.
It doesn't get a lot of love on HN, but these problems are addressed by Scrum. Sprints have a pre-allocated amount of work in them, which makes estimating easier. You can't predict exactly how much time you'll lose through meetings and emergencies, but estimating in story points will add a rough statistical estimate.
Of course, if you already have a toxic development culture like the one you describe, then they'd probably abuse more agile processes too.
Of course, if you already have a toxic development culture like the one you describe, then they'd probably abuse more agile processes too.
Instead of caveats, add to the estimate. Every caveat is some additional time.
Another thing that helped us is to answer with ranges instead of dates e.g., "this will take 1-3 weeks".
Another thing that helped us is to answer with ranges instead of dates e.g., "this will take 1-3 weeks".
You could argue that these are some of the many forms of "starting late":
* If you just don't know how long something is going to take, and you need a date, then you're late to doing the work to know how long it will take.
* If you do know how long something is going to take, and it's longer than a externally imposed date, then you know exactly how late you are.
This is partly just playing with semantics, but it's also a way of talking around different views of the problem, in this case emphasizing that if dates are a feature, reasonable estimates are themselves a project. If the estimate work hasn't been properly completed and understood before dates are given, obviously, the larger project is by definition already late because there's work that needed to be done before beginning and wasn't.
And I think if you take this view, it's easier to see that it's a project or team management problem rather than an engineering productivity problem.
* If you just don't know how long something is going to take, and you need a date, then you're late to doing the work to know how long it will take.
* If you do know how long something is going to take, and it's longer than a externally imposed date, then you know exactly how late you are.
This is partly just playing with semantics, but it's also a way of talking around different views of the problem, in this case emphasizing that if dates are a feature, reasonable estimates are themselves a project. If the estimate work hasn't been properly completed and understood before dates are given, obviously, the larger project is by definition already late because there's work that needed to be done before beginning and wasn't.
And I think if you take this view, it's easier to see that it's a project or team management problem rather than an engineering productivity problem.
I completely agree; you discover timelines in the process of doing the work.
The problems start when you need to give an estimate before even being allowed to start working on something.
The problems start when you need to give an estimate before even being allowed to start working on something.
In at least some cases, you have to be halfway into doing the work (or more) before it becomes apparent that there is a big, previously-unknown subtask or requirement that invalidates the plan for doing it. In other words, if you really know enough to give a good estimate, you are probably mostly done.
If you can't be flexible on the delivery date, you have to be flexible in feature scope.
That means building a simple verison first that still fulfills the purpose while not being perfect or polished. Then iteratively improve it to what you and the customer ideally want.
That way, if the deadline comes before you're done, you at least have a working version that fulfills the basic need and allows the kind of workflow that's necessary, even if it still has some rough edges or even gaps in rarely used areas.
Of course this approach requires you to write your contracts in a way that doesn't tie you down too strictly on how exactly things will be solved.
That means building a simple verison first that still fulfills the purpose while not being perfect or polished. Then iteratively improve it to what you and the customer ideally want.
That way, if the deadline comes before you're done, you at least have a working version that fulfills the basic need and allows the kind of workflow that's necessary, even if it still has some rough edges or even gaps in rarely used areas.
Of course this approach requires you to write your contracts in a way that doesn't tie you down too strictly on how exactly things will be solved.
Sadly, when it comes to contracts, that gets boiled down in most customers' minds to: "Vendor only commit to delivering buggy and incomplete software". It's a hard sell for most types of projects, even if it's the actual reality of most projects.
You sell a small portion, for the same smaller price tag. Then when the deadline comes, the customer checks to see if you delivered, and decides to continue the contract or find somebody else.
So the customer can have assurances that they aint gonna be bogged down with sunk costs. The developer can have more frequent deliveries.
So the customer can have assurances that they aint gonna be bogged down with sunk costs. The developer can have more frequent deliveries.
Disagree. Upper and lower bounds can be realistically estimated. Whether the estimates meet the demands of the market is another question. I'm an engineer, not a CEO or sales person, but I'm a firm believer in selling first and building it later. Building it after it's been promised is one of the best ways to limit scope.
> Building it after it's been promised is one of the best ways to limit scope.
only if those doing the promising knows what's within bounds and what's wildly off bounds!
If the sales person makes wild promises because his commission depends on making the sale, but not the delivery, then the whole organization's interests are not aligned properly, thus fail.
If the salesman's commission comes from successful delivery, then he can bring in an engineer who can at least balance the promises. Who knows, may be different departments can cross-contaminate, leading to a better, more well rounded organization.
only if those doing the promising knows what's within bounds and what's wildly off bounds!
If the sales person makes wild promises because his commission depends on making the sale, but not the delivery, then the whole organization's interests are not aligned properly, thus fail.
If the salesman's commission comes from successful delivery, then he can bring in an engineer who can at least balance the promises. Who knows, may be different departments can cross-contaminate, leading to a better, more well rounded organization.
> but I'm a firm believer in selling first and building it later
Please elaborate! :)
Please elaborate! :)
In a word, it's "agile".
Let me first acknowledge that there my thoughts are a mixture of the types of projects that I've been working on, my own personality and my own path dependent experience. In particular, my way is intentionally short sighted and won't work for a project plan that takes five years. Also, for sure, if the sales team/ceo is wrong and the project isn't worth doing, then doing it "lazily" won't fix that. But with that out of the way, here's what I mean.
The engineering team has it's own values and priorities and they just don't have anything to do with what really matters to customers. In the end, everyone brings in emotional baggage from the last project they worked on, and that's what's important until new information comes in from customers and the sales team.
So what I shoot for is taking the requirements that we have and producing a long range design that will meet those and little more, and then producing features as quickly as possible and presenting it to the customer (or the customer's advocate).
Why does it limit scope? Because the deadline doesn't move! To meet the most important requirements in a way that actually sells the product, lower priorities are are cut or reframed.
Let me first acknowledge that there my thoughts are a mixture of the types of projects that I've been working on, my own personality and my own path dependent experience. In particular, my way is intentionally short sighted and won't work for a project plan that takes five years. Also, for sure, if the sales team/ceo is wrong and the project isn't worth doing, then doing it "lazily" won't fix that. But with that out of the way, here's what I mean.
The engineering team has it's own values and priorities and they just don't have anything to do with what really matters to customers. In the end, everyone brings in emotional baggage from the last project they worked on, and that's what's important until new information comes in from customers and the sales team.
So what I shoot for is taking the requirements that we have and producing a long range design that will meet those and little more, and then producing features as quickly as possible and presenting it to the customer (or the customer's advocate).
Why does it limit scope? Because the deadline doesn't move! To meet the most important requirements in a way that actually sells the product, lower priorities are are cut or reframed.
I have seen "realistic estimates" be off by multiples. Also, "build it after it's been promised" is not making any sense to me, perhaps you can restate that somehow?
I think you’re missing the point of the article. His original theses was that we aren’t good enough at estimation. And in fact much hand wringing over estimation has been done in this industry over the last 6+ decades.
Now he’s amending his opinion to state that estimation is not really the core issue. The core issue is that projects are doomed from the start by mismanagement. Issues such as: racing to catch up with a competitor (giving the s/w group an impossible deadline), or starting a project whose business value is so low that minor time and cost overruns reduce the actual value to below zero (at which point people start blame shifting to try and hold on to their jobs).
Now he’s amending his opinion to state that estimation is not really the core issue. The core issue is that projects are doomed from the start by mismanagement. Issues such as: racing to catch up with a competitor (giving the s/w group an impossible deadline), or starting a project whose business value is so low that minor time and cost overruns reduce the actual value to below zero (at which point people start blame shifting to try and hold on to their jobs).
It is not about it being unknowable. If it would, the estimates would be all around the place. Sometimes short sometimes long.
Instead, we systematically underestimate.
Instead, we systematically underestimate.
Isn't there some pseudo quantitative form of estimation based on a first draft system network diagram ?
This is why "agile" methodologies caught on. Ignoring how they're used as internal political cudgels now, the most general goal of agile is to constantly adjust scope and estimates.
This way, we can accept that we're all terrible at estimates but we do our best not to paint ourselves into corners because of our terrible terrible estimates.
This way, we can accept that we're all terrible at estimates but we do our best not to paint ourselves into corners because of our terrible terrible estimates.
He doesn’t think estimation is the problem. He says that the projects are started late and that developers are handed a deadline by the business and then accused of being late when they can’t meet that deadline.
That's still an estimation problem by management. In agile, all sides are supposed to understand that scope and timeline are constantly adjusted.
The most successful software manager I've worked with, in terms of timeliness, was the one who deconstructed the work the most before starting. What exactly was going to be done, how confident were they in their estimate? Not confident? Break it down more. More detailed requirements, more detailed GUI mock up, More pre-design. Then, when confidence was high enough, by his judgement: who was going to do the work, and how did that work fit into the organization's schedule, including the testing, bug fix cycle needs, test equipment availability, and release.
He was nearly always on time, and never acceded to the customer's desired delivery date unless he could meet it.
I'm not saying this works in all environments, but for his case, it did.
He was nearly always on time, and never acceded to the customer's desired delivery date unless he could meet it.
I'm not saying this works in all environments, but for his case, it did.
Or in other words: a good estimate is itself a project.
Which is indeed successful. But this also takes time and sometimes sadly not allowed or deemed necessary. It also does not allow to respond to changes quickly unless a proper re-calculation is also done. Good technique for a lot of scenarios anyway.
This can surely work depending on organization. The problem is when the sales people need an estimate in two days or they don't get the contract. Then it is just a wild ass guess and the normal problems ensue.
The reason that software is so hard to do in most cases is that you are making something that (by definition) has never been done before. Of course stuff is going to go bad. This is largely a corporate culture problem. In these cases, I want to have the sales people come to a weekly meeting and have them estimate when they will have 100K sales for the month from new business. I don't think they would like that very much and you'd get a lot of dithering.
The reason that software is so hard to do in most cases is that you are making something that (by definition) has never been done before. Of course stuff is going to go bad. This is largely a corporate culture problem. In these cases, I want to have the sales people come to a weekly meeting and have them estimate when they will have 100K sales for the month from new business. I don't think they would like that very much and you'd get a lot of dithering.
The question is whether you're working for a sales company or a tech company.
Sales companies will prioritise the requirements of sales people, and tech would prefer to ignore the sales guys.
Frankly, as an engineer - I would never prefer the company where the sales people can decide how much overtime I would be doing in the end. Also - they would be getting all of the bonuses, since it's them making the decisions in the first place.
The good thing I find is that working for the engineering companies usually implies having clients with a head on their shoulders (hence them knowing what they want and what they're getting; and how much time it usually takes).
Sales companies will prioritise the requirements of sales people, and tech would prefer to ignore the sales guys.
Frankly, as an engineer - I would never prefer the company where the sales people can decide how much overtime I would be doing in the end. Also - they would be getting all of the bonuses, since it's them making the decisions in the first place.
The good thing I find is that working for the engineering companies usually implies having clients with a head on their shoulders (hence them knowing what they want and what they're getting; and how much time it usually takes).
> [I]nstead of obsessing over “What’s the matter with those software folks who didn’t deliver on the schedule we gave them?” we need to ask instead “Why did we ever kick off a project with such marginal expected value?
We work, live and operate in a complex environment and I think if we start viewing the organisation its projects and the environment in which it operates more from a systems perspective we may realise that in fact, it is truly difficult to make accurate predictions given the non-linear behaviour the system exhibits that results from all the information flows (or lack thereof), interaction of parts and other dynamics such as markets, human energy levels/mood, etc.
I really learned a lot from the book called Thinking in Systems and nowadays I can't help to look at projects, from within the context in which it operates. Definitely recommend the book for somebody wanting a bit of an introduction to that mental model.
I really learned a lot from the book called Thinking in Systems and nowadays I can't help to look at projects, from within the context in which it operates. Definitely recommend the book for somebody wanting a bit of an introduction to that mental model.
I think it also has todo with scope creeps. When a product / Service is developed, new possibilities are appear and customers are always trying to put these in the scope without adjusting the time / money necessary
Well the projects small marginal value isn't really related to the late delivery of the software people. I always say that delivering software successfully has a lot to do with courage. That includes courage to say (communicate) that a spec is too sketchy or outright unrealistic to deliver on time . That someone is dysfunctional within the project. That the timeline is too aggressive and needs to be split up into phases according to worse case scenarios.
If you can't do that, then you are the one to blame for tge project. If you did, though, then youre free to crash and burn happily ever after.
If you can't do that, then you are the one to blame for tge project. If you did, though, then youre free to crash and burn happily ever after.
While I 99% agree with the thesis of this post, I feel like another part to why I was late with a ton of projects earlier in my career was due to me getting prolonged depressive episodes, where I didn't want to leave my bed, let alone work on some software I really don't care about. For me, I was later diagnosed with Bipolar II, but it makes me wonder how many people just try and "walk it off" with these things, and as a result their work suffers.
The projects are late because no single project have finished before start.
One perspective is that negotiation of schedule and resources is often nothing resembling estimation but is a political game. Ed Yourdon's book "Death March" has a chapter about Negotiation .
http://ptgmedia.pearsoncmg.com/images/013143635X/samplechapt...
There's a list of "negotiation games" that, sadly, you'll probably recognise. And a bit of more practical advice:
http://ptgmedia.pearsoncmg.com/images/013143635X/samplechapt...
There's a list of "negotiation games" that, sadly, you'll probably recognise. And a bit of more practical advice:
>> The problem I have with “estimate” is that I understand
>> the word to mean, “best assessment knowing what is known
>> at this moment and what can reasonably be predicted about
>> the future.” From experience, what I have seen happen is
>> that once an estimate is published,it becomes a rock
>> solid commitment representing the maximum amount of
>> resources needed to accomplish the project phase or the
>> entire project.
> Unfortunately, there’s an uglier aspect of the political
> negotiation when you introduce the plus-or-minus
> qualifier into your estimate: You’ll be accused of
> uncertainty, wishy-washiness, weakness, or even
> incompetence. [...] What senior management really wants
> is a firm commitment — a promise that the project will
> be finished on a certain deadline, with a budget of a
> certain number of dollars, and a staff of a certain size.
> This gives them the enormous luxury of (a) no longer
> having to worry about the problem for the duration of the
> project and (b) having a convenient scapegoat to blame if
> the promise is broken.
> Jim McCarthy, in his excellent book, Dynamics of Software
> Development, suggests that the project manager needs to
> confront this head-on and persuade the customers and/or
> senior management that they need to share some of the
> burden of uncertainty [around schedule, cost, resourcing]
> that the entire project team will be living with on a
> day-to-day basis. Thus, the project manager effectively
> says to the customer or the senior management group,
> “Look, I don’t know precisely when this project will
> finish — but since I’m the project manager, I’m far more
> likely than anyone else in the organization to figure it
> out as soon as it can be figured out. I promise you that
> once I know, I’ll tell you right away.”
> Only a manager with a lot of self-confidence, and the
> ability to walk away from the assignment, has the
> chutzpah to say something like this in the politically
> charged atmosphere of a death march project. The time to
> say it is at the beginning of the project; after all, if
> the customer and senior management do not respect your
> ability as a project manager, and if they don’t realize
> that you do have a better chance of knowing when the
> project will finish than anyone else, then why are they
> putting you in charge of the project in the first place?
> Are you being set up as a scapegoat? Are you going to
> be a “puppet manager,” with all the decisions being
> made by other political manipulators in the
> organization? If so, now is the time to get out!
> Similarly, if you’re a lowly programmer on the project
> team and you see political games like this, it may be a
> strong indication that your project manager (a) doesn’t
> have the confidence to believe in any estimate that he
> puts forth, (b) doesn’t have the backbone to stand up
> for himself and for the project team, and/or (c) has
> gotten himself into a political situation where all the
> key decisions will be made by people who are not
> directly involved in the project. Again, this is a
> strong indication that the project is doomed; and
> before you get too deeply involved, it might be a
> better idea to seek greener pastures.
Bah, your estimate is meaningless anyway, since someone five levels above you in the org chart has already promised the customer that feature X would be available in 3 weeks. And that promise was made last Tuesday, so by the time it gets to you, there are only two weeks remaining until the deadline.
You'll know this is the case when you say "at least a month", and the PM looks at you like you just shot his dog.
"The answer I need is two weeks."
You'll know this is the case when you say "at least a month", and the PM looks at you like you just shot his dog.
"The answer I need is two weeks."
I found Steve McConnell's (of Code Complete) breakdown of estimates, targets, and commitments super helpful: https://www.youtube.com/watch?v=FY9X21HA02w
(2011)
Customer: “how long will it take (and therefore cost)?”
Three vendors: “less than [the other 2 vendors].”
...iterate until “cheapest” solution is reached ... meanwhile the technical staff at the vendors are losing their minds at the sales team, telling them that what they’re specifying is impossible...
Customer, to vendor [cheapest]: “Here’s a contract. We look forward to this project being delivered on time and on budget!”