[jerrya]

"Vague problem definition: "Create an automated test suite for the website.""

This is not a vague problem definition. And "Create an automated test suite for the website." is not "I just wanted something that pinged five URLs and checked for 500s."

[Confusion]

The problem definition lacks concrete measurable goals that identify when the problem solved. Without those, there is much room for interpretation and disagreement and the actual problem isn't well-defined. It only seems well defined, because you instantly fill in the gap in your mind.

It's unclear when the manager would consider the website 'tested'. If a manager said something like this and the first thing that came to mind was 'Selenium, full test-suite, 1 month', then the next thing to come to mind would be "that's probably not what he meant, since he doesn't want me gone for a month'.

[jacques_chester]

This is a case of where "commander's intent" would have been useful.

"We need to ensure that the site remains up. It would be helpful to know very quickly when it goes down. I need you to write a test suite to do that."

Without the framing of knowing why something is asked for, the risk is that the work will zoom off in unexpected directions, or, just as bad, get stuck on a triviality.

Staff can do their bit by asking for intent, if the corporate culture allows it.

[gaius]

We call it "definition of done", e.g. the project is complete where everything on this list is true. This is agreed upfront with the stakeholders/sponsor/whoever.