Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

All late projects are the same (2011) [pdf]

systemsguild.com

Post reply on HN
Print view View original

21–30 of 59 posts

Re: All late projects are the same (2011) [pdf]

#21

Post by Techonomicon »

jadedmgr wrote: post #14
mden wrote: post #7

Earlier quoted context omitted.

and no one is willing to say so. Except most engineers are perfectly willing to say so in my experience but management decides to ignore them or force them to say a made up number promising falsely not to hold them to it. Even worse what happens very often is an engineer would give an estimate and then a manager would "bully" it down to a lower number. On the reverse of course it makes sense to have estimates otherwi…

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 poi…

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.

Re: All late projects are the same (2011) [pdf]

#22

Post by trainingaccount »

jen729w wrote: post #3

They’re all late because customers are fools and salespeople are liars. 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 co…

We sure don't want it to go over time and budget like the last 10 projects.

Re: All late projects are the same (2011) [pdf]

#23

Post by avip »

jen729w wrote: post #3

They’re all late because customers are fools and salespeople are liars. 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 co…

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"

Re: All late projects are the same (2011) [pdf]

#25

Post by zdragnar »

tcmb wrote: post #4
rossdavidh wrote: post #2

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.

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…

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.

Re: All late projects are the same (2011) [pdf]

#26

Post by thecatspaw »

Techonomicon wrote: post #21
jadedmgr wrote: post #14

Earlier quoted context omitted.

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 poi…

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 bette…

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

Re: All late projects are the same (2011) [pdf]

#27

Post by wwweston »

rossdavidh wrote: post #2

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.

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.

Re: All late projects are the same (2011) [pdf]

#28

Post by a_imho »

jadedmgr wrote: post #14
mden wrote: post #7

Earlier quoted context omitted.

and no one is willing to say so. Except most engineers are perfectly willing to say so in my experience but management decides to ignore them or force them to say a made up number promising falsely not to hold them to it. Even worse what happens very often is an engineer would give an estimate and then a manager would "bully" it down to a lower number. On the reverse of course it makes sense to have estimates otherwi…

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 poi…

Though this be madness, yet there is method in ‘t

Re: All late projects are the same (2011) [pdf]

#29

Post by chii »

zdragnar wrote: post #25
tcmb wrote: post #4

Earlier quoted context omitted.

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…

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.

Re: All late projects are the same (2011) [pdf]

#30

Post by jt2190 »

jadedmgr wrote: post #14
mden wrote: post #7

Earlier quoted context omitted.

and no one is willing to say so. Except most engineers are perfectly willing to say so in my experience but management decides to ignore them or force them to say a made up number promising falsely not to hold them to it. Even worse what happens very often is an engineer would give an estimate and then a manager would "bully" it down to a lower number. On the reverse of course it makes sense to have estimates otherwi…

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 poi…

> 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.

Post reply on HN