3 ms·
Interesting, though not sure I follow. My reasoning is that the ultimate deadline is the “we run out of money and go out of business” point, from which all othe
by danielvaughn 3y ago
Interesting, though not sure I follow. My reasoning is that the ultimate deadline is the “we run out of money and go out of business” point, from which all other points follow. So a project may be organized differently, but under the hood it’s all the same - get more money before you lose all the money.
- pyrale 3y agoSay you have a half-sized team in order for the remaining people to get twice as much time. People working on the project will, on average, be more familiar with the problem. That's not a frequent answer, since most companies are more time-sensitive than budget-sensitive. But that's a good illustration of how budget and timeline are separate things. That being said, my initial message wasn't about that, but about the idea that plenty of organizational methods abandon tight deadlines in favor of early feedback. That usually works better when power is decentralized, since the higher you report to, the less people have time to actually look at what you produce (and therefore, the more they rely on low-involvement management methods such as setting deadlines). On the other hand, the more decision power is decentralized to the people actually using the software, the more early feedback will make setting deadlines redundant.
- regularfry 3y agoThis is only a hard deadline if you have to wait until the end of the project before any money happens. This is the problem with the word "project" and, more generally, with formal project management: it attempts to divide the timeline into "Before Delivery" and "After Delivery" and often it doesn't care what the world looks like other than as a bag of deliverables. That's not the only way to do it, of course, but it's the mental trap you set for yourself by thinking about things as Projects with a capital P.