As a PM, I find it best to put together a straw man project plan before I talk with people, then revise it progressively as I talk with people. Not always, but

As a PM, I find it best to put together a straw man project plan before I talk with people, then revise it progressively as I talk with people. Not always, but it's often a good idea, particularly if the project crosses multiple departments or companies. Sometimes I can't get everyone in the room at the same time. Sometimes (often) people will see their own team's area of work as being the main focus, while I have to coordinate with other groups, while trying to minimise the "hurry up and slow down". Sometimes there is a need to get people started on the bits we know about and accept that other bits will need changing. And sometimes you need to get the person responsible to estimate the length of the piece of string, and putting up a wrong estimate is a good way to get an answer. I'm sure everyone is thinking "agile" now. Yes, I was in to that back when XP was the thing. But it only works for some sorts of project, typically where there is only a single company developing a project, and the customer is internal. If you have a big contract with specific deliverables, a contractual time line, multiple organisations, and perhaps large non-sw parts, you often find that you have to start planning even before the developers are engaged, then accept that some of your assumptions will be wrong.