I took a long weekend to visit relatives and happened to have worked from home the week before due to an injury. Now, on my way back to office, I have a sense of perspective. Let's see what the rest of the week brings and how my perspective changes once I'm in the trenches again.
One thing I realized is that as a project usually involves several teams of people, knowing who is involved will be extremely important to the success of the project. I would assume that this can usually be known up front if time is taken for planning and understanding. For example, any need for a DBA on any project I've worked on was known early on. A proper plan will map this (possibly through some sort of activity diagram with swim lanes). It seems appropriate that each team has representation in the project kickoff meeting, especially from the person most likely to do the work.
This kind of plan requires participation in a project from a technical lead - the person who is responsible for designing the solution. Early participation can help determine an overview of the human resources needed for the project, especially if the technical lead is well-versed in the inner workings of the organization. After design, the needs would be more detailed - however, still not necessarily precise since design can change so much during build. The project plan needs to be reviewed and refined after this milestone.
Some questions to ask from each team that should generate tasks to add to the project plan:
How much lead-time do you need in order to plan for resources?
What information do you need in order to estimate effort?
How does one submit a request for work?
What level of involvement will be needed during the project?
This information should be available as part of the project documentation and should be tied to the tasks in the plan. A project plan should always map dependencies between tasks and between milestones.