[NikolaNovak]

I'm not reading those 3 nearly as Cynically.

Number 1 should not be controversial for vast majority of IT. If you cannot articulate what problem you're trying to solve, you won't know when you're done or how to approach it or what it's value is. Anything from scope creep to underfunding to business mis alignment are classical dangers of not having #1. (note it does not read "I know exactly the specific solution and implementation details". Just says "understand what the heck you're trying to accomplish", which I would expand as "understand and agree")

#2 I view tactically and or operationally. It's good, when choosing a tool or approach or algorithm or vendor etc, to know what some alternatives may be. Presumably, you consciously or subconsciously did that work anyway during solutioning or POC or just brainstorming phase.

#3 is basic project management. Articulating risks is crucial. Ideally the developer can do it but if not, for love of all that is unholy, somebody should :). And you should be able to articulate some key unknowns - e. G. I don't know the performance of this yet to be developed application until we get to performance testing.