91–100 of 111 posts
If a project is a month past its deadline, that means it should have begun a month sooner (in order to meet the deadline).
It's surprising how little attention is paid to this fact in the professional world. So many teams and managers focus on the end date, and ignore the start date. In truth, the start and end dates are precisely equal in importance.
Because when you are in a business that follows a process you are in a business that can hide behind that process and no one has to accept responsibility.
Are you saying businesses shouldn't have processes?
Earlier quoted context omitted.
Another reason is a kind of selection bias: an organisation wants something built, gets offers from various software companies, and picks the cheapest. That is, if you are doing the project, your company's initial estimate was the one that had the highest chance of being too low.
That's not only that, the field is full of bullshit. Advertising feature as available when they have not even been discussed seriously is the usual in the companies I have worked for the last 10 years. Our website and sales all go advertising "We support X. We are ready for regulation Y", while we are actually waiting for a paying customer to buy it to even look into it. And that's all companies. You can't really be…
You completely lost me there, what happened exactly?
When I was doing more project work I outright refused to give estimates, explaining that I could come up with a random figure that's so low they won't believe it or so high they won't like it, and in any case the figure would have nothing to do with when the project would be complete. Instead I offered broad time ranges that would narrow down to more accurate ones as work progressed. The managers who had to report th…
Broad time ranges can also be risky, because people will hear what they want to hear, which is usually the lower end of the range.
Which is why I only discuss effort (in hours) rather than timeframes. All of our projects are fixed bid, so the conversation usually goes, "this project will take 150 hours of effort. We don't know how long those 150 hours will take to expend." And in rare cases where we absolutely have to mention a timeframe, we make sure it is not in writing anywhere.
Because humans suck in predicting the future.
All this talk of medians and means assumes that you've done the same thing many times before (otherwise you wouldn't have those statistics). In software, if you've done it before, then it's already done so the estimate is zero.
Projects always involve doing new things, new requirements, using new technology, techniques, or tools; targeting a new system, and/or using new processes and people. New requirements, constraints, market situations, priorities, and discoveries rise up during the project. Sometimes all of the above. Past performance is not a predictor of future results.
It's more realistic to flip it around. Prioritize the most-important requirements and set an initial deadline. Then you'll get something (the most important stuff, or at least some progress towards it) by the deadline and can decide whether to add the less important stuff afterward.
When doing that, quality and other intangibles need no longer be overlooked but become part of the prioritization. Do you want high quality, or more stuff by the deadline? Do you want the team functioning well for the long haul or is it worth burning them out to rush this, then having downtime afterward?
To get more control, shorten the deadlines to the minimal point where you're still getting deployable chunks of acceptable quality. That acknowledges the inherent uncertainty and gives better control and visibility than just making up a random number (or 3).
Earlier quoted context omitted.
That's not only that, the field is full of bullshit. Advertising feature as available when they have not even been discussed seriously is the usual in the companies I have worked for the last 10 years. Our website and sales all go advertising "We support X. We are ready for regulation Y", while we are actually waiting for a paying customer to buy it to even look into it. And that's all companies. You can't really be…
> An extreme case, is a client that took a package I developed 5 years after delivering the working version of it. You completely lost me there, what happened exactly?
We delivered a project a few weeks ago and heard nothing; I heard only yesterday that the manager went on holiday and will be back 3rd week of january. And when he comes back his inbox will be full so I do not expect any testing till the 2nd week of feb...