The article doesn't say who should be asking these questions.
I hate to say it, but sometimes "ordinary" software programmers (the most dangerous are the kind with just a little experience but not enough to know that they don't know) will start to feel that they should be asking these questions of the people asking them to build something. It's a good sentiment, but often (especially when there are sales/competitive/pre-emptive/other factors) at play, they're straying a little into "too big for your britches" territory and should just build what they're asked to. Leave the questioning to the engineers who both know how to build it in their sleep, and understand why it's needed...
For any business, the people responsible for a managing a project will also be the people that are both experienced and informed about various important factors that come from being at the level both related to the business and in terms of management skills.
If a new dev asking a questions is enough to derail a project there were bigger issues at play.
As a counter-point, I think it is good to also consider that even the wrong people asking the right questions is better than no one asking them. I think discouraging fledgling developers from asking these questions is a short-sighted choice. I believe a better choice is to have an environment where they can be guided to the right answers, even if they are "too big for their britches".
At my employer, engineers at every level are accountable for their work's business impact more than anything else. It is always your responsibility to understand and be convinced of the value of what you're doing, and to escalate your concerns or transfer out of the team if you're not. "The product requirements were ill-conceived but I executed them well" will not save you at performance review time, even if you're a new grad.
A competent PM has considered these questions carefully, and most of their thinking should be written down and circulated before the project starts. They will happily discuss lingering questions with anyone interested.
Everyone should be able to ask, that's how they learn, and sometimes that guy down in the trenches knows something that is in the plumbing that other folks don't automatically know.
I'd like to better understand your angle / experience here... it seems to me like death march projects start when questions don't get asked up front and/or developers put their heads down and do what they are told instead of being proactive in heading off challenges.
why not? developers are a key part of a business and shape it. they should certainly be paying attention to managements initiatives and what risks or blockers these may present to the project at hand. this would encourage alignment and clarification.
