Live data from Hacker News

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

systemsguild.com

31–40 of 59 posts

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

#31
post #6

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.

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.

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

#32

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

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.

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

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

Just need to manage the lazy developers better (read: more) this time!

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

#34

Earlier quoted context omitted.

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

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

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

#35

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.

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.

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

#36
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:

  >> 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.
Refusing to be pressured into emitting on-the-spot "estimates" that will be regarded as commitments is a useful life skill. Teach your new hires: http://www.dadhacker.com/blog/?p=2267

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

#38
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…

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.

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

#40
post #23
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"

In my experience new build houses and apartments are never on time either.
Post reply on HN