
All late projects are the same (2011) [pdf] - fanf2
http://www.systemsguild.com/pdfs/DeMarcoNov2011.pdf
======
jen729w
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 contract. We look forward to this
project being delivered on time and on budget!”

~~~
avip
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"

~~~
collyw
In my experience new build houses and apartments are never on time either.

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

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

~~~
mden

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

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

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

~~~
thecatspaw
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

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

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

~~~
jayd16
That's still an estimation problem by management. In agile, all sides are
supposed to understand that scope and timeline are constantly adjusted.

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

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

~~~
heavenlyblue
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).

------
jt2190
> [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?

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

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

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

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

------
juskrey
The projects are late because no single project have finished before start.

------
dang
From 2016:
[https://news.ycombinator.com/item?id=11098466](https://news.ycombinator.com/item?id=11098466)

------
shoo
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...](http://ptgmedia.pearsoncmg.com/images/013143635X/samplechapter/013143635X_ch03.pdf)

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](http://www.dadhacker.com/blog/?p=2267)

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

------
jt2190
(2011)

