5 ms·
> So show me a methodology that mere mortals can implement successfully. Commit to a deliverable or a deadline, but never both.
by aahortwwy 5y ago
> So show me a methodology that mere mortals can implement successfully.
Commit to a deliverable or a deadline, but never both.
- xvilka 5y agoI would say an approach closer to the Heisenberg uncertainty principle would make more sense. The more information specified that can't be changed about the expected product the less information is available about the deadline, ans vice versa. Thus, the desired balance could be used depending on the situation, goals, budget, etc.
- jcims 5y ago“Ok awesome! Glad to hear you’ve committed to deliver widget, when do you think it will be done? We have four business units that were going to use wedgie but that’s getting decommed next year and they’d much rather avoid a pivot. Oh and change restrictions start in six weeks, don’t forget that. BTW what’s your team’s vacation schedule looking like? We only get to roll over 7 days this year, hopefully they took some this summer haha! Ok so anyway really would like some estimate that i can take back to product, you thinking January? Maybe get something up in test that they can kick around in what, a month?” Etc etc.
- aahortwwy 5y ago"No." It's remarkably powerful.
- bodge5000 5y agoI'm not all to familiar with this kind of thing so I could be missing something, but what is a deadline without a deliverable? Surely "We will do something (literally "something", not a stand-in for X) and it will take a month" is worth nothing?
- selfhoster11 5y agoYou can have a fixed scope with a flexible timeline, or a flexible scope with a fixed timeline. If you try to have both, you'll incur an additional cost, which most companies avoid. It's a well known law of project management and software development.
- darrenf 5y agoI worked for several years on an extremely large and popular sports news/results website, meaning all our deadlines were absolutely set in stone by the outside world – sporting events start on specific dates. The Tour de France sure as hell ain't gonna postpone a few days until we've finished our team profile pages. So we committed to a deadline, but not a single deliverable. Scope would shrink and grow as delivery of each component progressed. Well in advance, for each major sporting event in each country where we operated, we would scope out literally every single thing we'd like to deliver, and then start work on the components in priority order. In each planning session as the event approaches we'd appraise whether we still have time to realistically deliver the next priority thing, and if not we'd skip it and move to the next - those that got missed out could wait until the following year (when the major features already delivered would need to evolve, not be implemented from scratch). I learnt a lot from working on sports. Having third party deadlines that no-one could bitch about made us an extremely effective team at planning, estimating, and ruthless scope reduction.