3 ms·

Fwiw in a real world scenario it'd be more helpful to hear "the timeline has risks" alongside a statement of a concrete process you might not be doing given tha

Fwiw in a real world scenario it'd be more helpful to hear "the timeline has risks" alongside a statement of a concrete process you might not be doing given that timeline. Everyone already knows about diminishing returns, we don't need a lesson on that.

Swizec 2y ago
My favorite tool when defining project timelines: What are we not doing? There's an infinite number of nice-to-haves. A nice good deadline makes it super easy to clarify what you actually need vs what you only want.
- TylerE 2y ago
  and you'd be amazed when you start really having these discussions with the client how often stuff ends up not only not being needed, but often going right past 'nice to have' and right to 'lets not'. The problem is often the initial problem being WAY overspecified in ways that don't ACTUALLY matter but generate tons of extra work.
  - whstl 2y ago
    Yeah, to me this kind of thing is much better than the carefulness knob. Delaying or just not doing certain features that have low ROI can drastically shorten the development time without really affecting quality. This is something that as an industry we seem to have unlearned. Sure, it still exists in the startup space, with MVPs, but elsewhere it's very difficult. In the last 20 years I feel like engineers have been pushed more and more away from the client, and very often you just get "overspecified everything" from non-technical Product Managers and have to sacrifice in quality instead.
    - TylerE 2y ago
      I had one today that with one email went from "I want this whole new report over our main entity type with 3 user specified parameters" to "actually, just add this one existing (in the db) column to this one existing report and that totally solves my actual problem". My time going from something like 2 days to 15 minutes + 10 minutes to write the email.
      - whstl 2y ago
        For me the biggest one lately was due to miscommunication and bad assumptions. The designer was working in a redesign in their own free time, so they were using this "new design" as a template for all recent mockups. The Product Manager just created tickets with the new design and was adamant that changing the design was part of the requirements. The feature itself was simple, but the redesign was significantly hard. Talking with the business person revealed that they were not even aware of the redesign and it was blocked until next year.
TylerE 2y ago
If everyone actually knew this stuff, this entire class of problem would cease to exist. Given that it has not...
ChrisMarshallNY 2y ago
I use a fairly simple “checkerboard” table to display risk, and encourage planning for mitigation/prevention/remedy[0]. In my experience, risk has two dimensions (probability and severity), and three ways to be handled (prevention, mitigation, and remediation). [0] https://littlegreenviper.com/risky-business/ https://littlegreenviper.com/risky-business/

Swizec 2y ago

My favorite tool when defining project timelines: What are we not doing? There's an infinite number of nice-to-haves. A nice good deadline makes it super easy to clarify what you actually need vs what you only want.

TylerE 2y ago
and you'd be amazed when you start really having these discussions with the client how often stuff ends up not only not being needed, but often going right past 'nice to have' and right to 'lets not'. The problem is often the initial problem being WAY overspecified in ways that don't ACTUALLY matter but generate tons of extra work.
- whstl 2y ago
  Yeah, to me this kind of thing is much better than the carefulness knob. Delaying or just not doing certain features that have low ROI can drastically shorten the development time without really affecting quality. This is something that as an industry we seem to have unlearned. Sure, it still exists in the startup space, with MVPs, but elsewhere it's very difficult. In the last 20 years I feel like engineers have been pushed more and more away from the client, and very often you just get "overspecified everything" from non-technical Product Managers and have to sacrifice in quality instead.
  - TylerE 2y ago
    I had one today that with one email went from "I want this whole new report over our main entity type with 3 user specified parameters" to "actually, just add this one existing (in the db) column to this one existing report and that totally solves my actual problem". My time going from something like 2 days to 15 minutes + 10 minutes to write the email.
    - whstl 2y ago
      For me the biggest one lately was due to miscommunication and bad assumptions. The designer was working in a redesign in their own free time, so they were using this "new design" as a template for all recent mockups. The Product Manager just created tickets with the new design and was adamant that changing the design was part of the requirements. The feature itself was simple, but the redesign was significantly hard. Talking with the business person revealed that they were not even aware of the redesign and it was blocked until next year.

TylerE 2y ago

If everyone actually knew this stuff, this entire class of problem would cease to exist. Given that it has not...

ChrisMarshallNY 2y ago

I use a fairly simple “checkerboard” table to display risk, and encourage planning for mitigation/prevention/remedy[0]. In my experience, risk has two dimensions (probability and severity), and three ways to be handled (prevention, mitigation, and remediation). [0] https://littlegreenviper.com/risky-business/ https://littlegreenviper.com/risky-business/