[osigurdson]

>> Failure to deliver on time means they don't get another dime

"On time" can be achieved by over estimating. As a hypothetical, dev A estimates that a project will take a year and completes it in 6 months. Dev B estimates 1 month for the same project and completes it in 3.

Companies that focus too much on things being "on time" ultimately get the "nothing is worth doing" corporate culture.

[Joel_Mckay]

Actually, sometimes it means hiring rank amateurs, and training them to reliably complete tasks like a real business. Understanding the time constraint would be lower for Jr, and thus the equivalent pay scale will be less lucrative... but it is up to individuals to decide their own work ethics.

Using PERT deliverable/vertices redundancies is often necessary for projects no one has seen before:

https://en.wikipedia.org/wiki/Program_evaluation_and_review_...

Note, the simple system uses probabilistic time estimates of key deliverables, considers redundancy, and explicitly mitigates teams that introduce liabilities.

If it put people on the moon, than I figured it was good enough for most of my ridiculous projects. Have a great day =3

Rule #17: "Always listen to the person that signs your paycheck. Everyone has an opinion, but some opinions are more profitable than others"

[osigurdson]

I think the PERT chart is pretty accurate. The issue is typically predicting what all of the nodes on graph will be ends up being a waste of time. Instead, there are really just two points: current state and desired state. It is better to spend time clearly articulating the desired state so that everyone really understands it. Then incentivize people to get there as quickly as possible.

[Joel_Mckay]

I think our perspectives differ slightly, as I really don't care to micromanage adults that know better. Notably, the fixed cost of development is far less of a concern than long-term deployment, support, and maintenance costs.

Probably a ROWE would be a similar modern equivalent...

Have a nice day, =3