But isn't this just stating the obvious, e.g. don't measure success by lines of code written, number of commits, number of bugs fixed...? And there is nothing wrong in stating the obvious, especially as when it is not obvious to some people.
There's enough nuance required here to fill a small series of books. If you state the obvious and then go on to actually examine the nuance, then I'm fine giving you credit. If you don't then I don't really see the benefit.
Worse, you've given people a thought terminating cliche that can be disastrous in the hands of a novice. "Hey, we're focusing on the outcomes!" Yeah, but you've missed three milestone dates so your funding is going to be pulled and everyone is now unemployed.
But you are really arguing in general against such lists like this, that don't "examine the nuance". But perhaps they are useful discussion point or memory joggers. And shouldn't the senior members of a team or managers explain to novices the importance of meeting such milestones that you mentioned?
I basically read the whole list as: "How do be successful? Step 1: Be successful. Step 2: Be successful at purple. etc"
Some of it sort of makes sense. Some of it might as well be gibberish. None of it is useful without a bunch of senior members of a team who have been successful before. And if that's the case, then we can just delete the list and stick with the senior members of the team.
I can see the use of such a list for example on a team wiki as a reminder of what the team considers good practice.