In today's "agile" and "extreme" development cultures, it's easy for team members' roles to become a little blurred as a project advances. But even in a flexible environment, there still needs to be a division of labor to meet goals and avoid redundancy-particularly in the scope and planning phases. You can wait to get all scrummy when the coding starts.
The Detailed Project Planning Flow Chart, from project manager Michael Taylor, clearly lays out project planning responsibilities in a traditional, visual project flow. The PDF, which you can easily print and distribute within your organization, is available for free download to IT Business Edge members here in the IT Downloads library.
The flow chart breaks out planning responsibilities across four staff levels: team leaders, team members, subcontractors and, of course, project managers. It depicts the planning process within a traditional dev structure-the hair-pulling of crafting business cases and functional requirements with business managers is not encompassed in the plan.
In the model, PMs work directly with team leaders during the planning phase, and are responsible for creating and distributing three key resource definitions:
Work Breakdown Structure: This basically is a decomposition of a project into smaller chunks, based on deliverables. The WBS usually takes the form of a flow chart itself, and ultimately is a key element in defining the overall scope of the project.
Organization Breakdown Structure: This is another chart (project management is a highly visual discipline, after all) that maps the components of the WBS to teams and units within the organization. It's basically a map of who reports to whom and serves to support further refinement of the work plan.
Responsibility Assignment Matrix: The RAM typically takes the form of a spreadsheet that lists a project responsibility and the category of team member that will be assigned the task. It also tracks the intersections of project responsibilities, when appropriate.
After PMs develop these fairly high-level assets (the flow chart describes them as being at "level 2"), they pass them along to team leaders for a round of refinement, which you can see depicted in the excerpt of the flow chart below.
Team leaders are charged with "decomposing" the Work Breakdown Structure to level 3 and then passing it on to actual team members, who then break it down to the finite levels needed to support technical specifications (or coding, if you are an extreme shop). The team leaders also are charged with identifying and recruiting the team members and developing team RAM, which is then turned over to team members for draft scheduling.
In this model, team members (not leaders or PMs) are tasked with issuing RFPs to subcontractors. This gives you a pretty good idea of the organizational scale the flow chart addresses. Of course, you can always modify the flow chart's assumptions to fit your structure-the general wisdom and sequences of steps in the process will remain valid and useful.
PMs don't get re-involved in the process until team leaders run their own "sanity check" on the plans passed back to them by their team members. Another sanity check and planning review follows, and then it's off to dev.
It all makes a lot of sense, but there is enough complexity and hand-off to invite confusion and breakdown-if you don't have a plan for the process going in.