A project team at a mid-sized municipality spends its first meeting about a new case-management system on the question of whether the project will follow Prince2 or a lightweight Scrum variant. A vote is taken; by the end of the meeting the method is already on the first slide of the presentation. At that point, the requirements list for the system itself consists of three bullet points on half a sheet of paper: no acceptance criteria, no owner per requirement, no distinction between must-haves and nice-to-haves. Three weeks later, when the first sprint starts, it turns out nobody agrees on what 'a working case overview' actually means.
That order, method first, requirements later, happens more often than you'd think. Research shows it is the wrong order.
What the research shows
Dvir, Raz and Shenhar studied in 2003 what project success actually correlates with. Their finding: success correlates with the quality of requirements definition, how sharply it is documented what the project must deliver, and not with the extent to which a formal PM process has been implemented. The choice of method itself, however thoroughly worked out in a handbook or template, correlates little with that. The requirements do.
That is an uncomfortable conclusion for anyone who spends a lot of time choosing and documenting a way of working. A project plan with a tight Prince2 structure, roles, phase transitions, a PID, everything by the book, looks professional. But if the requirements underneath stay vague, the client is buying false certainty: the form is in order, the content is not.
The nuance that comes with it
This is not an argument for abandoning governance and process agreements. Other research, by Serrador and Turner in 2015, does find positive links between process maturity and project success. 'Content over process' is therefore not a universal law, the two lines of research contradict each other on this point. What holds: requirements definition must not disappear behind a methodology discussion, even when that discussion is itself useful.
What this means for the start of a project
Concretely: if a plan of approach spends its first weeks mainly on which method will be followed, which framework, which templates, which meeting structure, while the requirements list stays a placeholder, the order is upside down. Choosing a method can well happen early, but not instead of recording requirements. A requirement that counts has an owner, is verifiable (you can check afterwards whether it was met), and is independent of how the project is managed.
For anyone reviewing a plan of approach before kickoff, this is a concrete question alongside the one about governance and phasing: are the requirements there, independent of the chosen way of working? A plan that scores excellently on process design but whose requirements amount to little more than a statement of intent deserves a critical look on that point. Not because process doesn't matter, but because a tight process can mask the absence of sharp requirements, and that is exactly where it went wrong with the case-management system.
One concrete step
At the next session on the plan of approach, put the requirements list at the top of the agenda, before the conversation about which method to follow. Have every requirement get an owner and an acceptance criterion before the team moves on to the question of which framework to build around it. That costs an hour at a point when the discussion is still about form anyway, and it prevents a well-documented method from ending up on top of an empty foundation.