3 ms·
The fact that the deadline is not “arbitrary”, because it is a contractual obligation, doesn't automatically make the contractual obligation feasible. The reaso
by laserlight 4y ago
The fact that the deadline is not “arbitrary”, because it is a contractual obligation, doesn't automatically make the contractual obligation feasible. The reasoning behind signing the contract could still be based on “arbitrary” reasons, wishful thinking, political agenda, etc. Putting project constraints on paper doesn't mean that the project will meet those constraints.
- Frost1x 4y agoA lot of business leadership handwave this away and I've seen some claim the only way to remain competitive was to go this insanely aggressive towards the target in some way: low budget, short timeline, "optimistic" feature sets, etc. It's especially common in larger businesses with layers of middle management that aren't held accountable and pass their poor decision making down, often making it difficult to identify the real problem they are to the organization. Even in small orgs, if you need to make unrealistic promises to compete, you shouldn't be competing and should refocus your business, your current business plan is flawed and its not inherently your employees fault that they can't deliver as efficiently against businesses that focus on some niche and have done so over decades or benefit from economies of scale and fat margins to pad such projects they can afford to operate at a loss.
- nobody9999 4y ago>A lot of business leadership handwave this away and I've seen some claim the only way to remain competitive was to go this insanely aggressive towards the target in some way: low budget, short timeline, "optimistic" feature sets, etc. There's an old saw that goes something like, "fast, cheap, good. Pick two." I've found that to be true over and over again. All three options can be useful depending on whatever it is that's being worked on. Many of the complaints in this discussion about setting deadlines seems to be that not enough resources are being allocated to meet the "fast and good" selection. Which, of course leads to an end result of "fast and cheap," which isn't the goal. The main argument seems to be that "cheap and good" is better than "fast and cheap" because there aren't enough resources allocated to achieve "fast and good." The solution, of course, isn't to eschew deadlines, but rather to determine the work required and make a decision about how the work should be done (with the above being a simple-minded way of describing that 'how'). It seems like deadlines become an issue when those setting such deadlines are focused on the "fast and cheap" pair, while the folks actually doing the work want "good" to be part of that pairing. As someone who has worked both in environments which focus on minimizing time and cost when bidding for work, and in those where estimates realistically reflect the time and cost of completing the work, I find the latter to be much more effective. The former is generally a shit show where no one is happy. The client either doesn't get what they need, or it's going to cost a whole bunch more than they were told, and those actually doing the work are pressed to work harder and faster because the client is pissed off. And the business generally loses in the medium to long term as well, as they're unlikely to get repeat business and certainly won't get referrals from that client. When good estimates are provided and the appropriate resources applied, projects often go much more smoothly and everyone wins -- over the short, medium and long term. Obviously this requires good planning and a strong understanding of the goals and requirements and translating those into reasonably accurate estimates. Those (as others on this thread pointed out) are skills that can be learned. Sadly, those skills seem to be in short supply. And more's the pity. Edit: Clarified my prose.
- nikau 4y agoAll the recent projects I've been on have been shit shows, and I put it down to Agile, MVP, and inappropriate tools like Jira and Miro being used to manage projects with pretty diagrams and no depth or proper interdependency mapping. I'd go for an old school MS project wielding project manager any day of the week.