By John DeWitt
There is much more to planning a project than the mechanics of defining the work and how long it will take to get it done. The project manager's most important tasks are the coordination and management of the people assigned to the project, and leading that collective group to achieve the project objectives. Tasks on a page provide a great roadmap, but a written plan can never embody everything it will take to get the project done. New project managers can get tripped up if they've been introduced to the role with a big focus on the mechanics of project planning and scheduling, without adequate attention to dealing with people, risk, and other real world effects.
Here's some advice and guidance on what's most important in planning a project—what we think matters most, and what you need to know how to do in leading the team to project success.
Understand the objectives before you jump into planning. You'll have to make some trade-offs eventually, and when that time comes you'll need to know what's most important. Knowing your internal and external customers and their objectives for the project will help to define the entire scope of the project. Then, given business constraints (time, money, competition …), some tradeoffs will be likely, with an eye to achieving the company's most important business objectives within those constraints. At this early stage of project planning, understanding sponsor and stakeholder expectations will help you explain to the team what really matters, and help the team through potentially tough choices. To help you in this task of getting project objectives input from sponsors and others, read the article How to Interview the Project Sponsor.
Build one-on-one relationships with the team members who will get it done. Nothing in the plan matters if it's created without team member buy-in. If not everyone sees the project as a doable endeavor, you're fighting a layer of people issues on top of whatever challenges the plan itself might present. We're convinced that people come to work with the intent to do the best job possible, and that there are usually good reasons behind resistance to participation. Remember that people have perceptions and opinions and need to be heard to give their all to an effort. So project managers need to find, ask about, and understand the root cause of any schedule resistance as the plan is developed and beyond. Maybe there's concern about the level of risk related to the technical approach; or a mismatch between scope, resources, and time to meet the objective; or an uncertainty about how long their work will take.
Be truly genuine in your approach, listen to their position, and seek input from others to get a broad perspective on the issue. You could be surprised how people react when asked for their input, and further surprised when they see their concerns get handled in the plan and integrated into the decision process. If the resistance is still there, be ready to repeat the process to keep getting at the real issues. It's worth it to keep at it. Every team member's attention and commitment is needed for the project to be successful. One good approach to helping develop your leadership with the team is provided in our "Sweet" Team Building Suggestion.
Watch for people who seem disengaged. Are people skipping planning meetings? Rolling their eyes? Not paying attention? Planning is not necessarily a meaningful exercise to everyone! Many individuals would rather just jump into doing the work than take the time to develop a plan, whether because of personal style or perceived company pressure to "go get the real work done." But planning is the team members' opportunity to define what's going to get done and provide their own estimate of the effort required to do their work. The alternative—having someone else plan their life on this project, and having to live with the resulting schedule—should not seem attractive!
So how do you draw people into an activity they don't want to do? One answer is to build their perception of planning as an empowering activity. Tell your team members that the plan is supposed to be a direct reflection of how they think the project should go. It's supposed to be a realistic roadmap of work to achieve the project's objectives and deliverables. They are the subject matter experts who know what needs to be done, and who have the necessary knowledge to estimate the effort. The plan is not a management document handed down, or the project manager's document. It should be seen as a team-owned document, showing the approach the team wants to use to achieve the objectives, and living and changing as progress is made and more becomes known.
To get the team into this mindset, keep the initial planning at a higher level, identifying big blocks of work with the team and showing how everyone's work fits together. Then they can help develop more task detail to ensure that risks are accounted for and ample time will be left for their work. Too many team members see the schedule as something the project manager does, one of those front-end activities they have little input into, and even less control over. By involving your team members in schedule development from the very beginning, you can encourage them to feel accountable for the parts of the schedule that represent their work. It becomes not just the project manager's job, but theirs too. Empower them to contribute the knowledge and estimates, and they become accountable for making it thorough, realistic, and achievable. Involve team members in discussions about what different groups will need from each other, to make the checkpoints and handoffs in the schedule real and meaningful. (They don't want another group to mess them up by not providing what they need for their work at certain points and surely they don't want to do that to anyone else!) You may ask some team members to explain their parts of the schedule at the team meeting, or even present more formally to the team and sponsor in a management review, if that reinforces their critical role in the team-wide responsibility for the schedule. It would also them their chance to convey the time required to get this all done.
The cure for planning disengagement is to make the planning work personally meaningful and relevant. See the guidelines Planning and Scheduling: Task Identification and Work Breakdown, which includes notes on how to involve the team in the planning process, and Planning and Scheduling: Estimating Work and Costs for notes on how team members should be involved in creating the details of the schedule.
Do reality checks, and take action accordingly. As the plan is being developed, ask yourself whether you think the team can really deliver on everything that's being asked, within the realities of the time and resource constraints. Ask them (and judge from their behaviors) whether they think they can. What's the real opinion on the ground? The simple answer to those questions may be no. If it is, determine why, and then evaluate workable alternatives for the project. Don't just say, "Well, this is what management wants, so we'll just do the best we can." Every project has to pick a balance between the scope desired, the time available, and the resources available to get the best approach to meeting the most important business objectives. It's the project manager's job to force those trade-off discussions to happen ASAP when it's clear that scope, schedule, and cost (resources) can't all be met. Our Project Flexibility Matrix provides a team tool for clarifying what matters most, and the Project Alternatives Tradeoff Table compares different project objectives. Finally, Planning and Scheduling: Make Trade-offs and Optimize covers how to go through the tradeoff process using those tools.
Go back to the project sponsor and stakeholders you interviewed earlier in the project to get their agreement or alignment to recommended revisions to scope, schedule, and/or resources in an adjusted plan. These conversations will be more effective using the data generated in the tradeoff process, as the managers and executives will want some understanding of the process, the alternatives, and the impacts that were discussed. Some of these people may well need to be involved in the trade-off discussions, not just briefed at the end. Work with your team and stakeholders so the team finds the eventual outcome doable, and the sponsor and stakeholders agree that the revised plan will meet the business objectives.
Consider task suppliers and customers. We all live in some sort of economic food chain, where the output of one person's work is the input to another's. As you and your team develop the project scope, Work Breakdown Structure, and tasks for a schedule, think about who the customer is for the output of a task, and who the supplier is (the person assigned to do that task). Have these individuals get together to discuss their work and what they need from each other. Early awareness of "customer expectations"—what each person needs from their supplier to get that next piece of work done—will add good, meaningful detail to the plan, improve estimates, and minimize the potential for missed work. One tool that can help highlight handoffs between team members and clarify what's needed is the Responsibility Allocation Matrix worksheet.
Keep it real. Focus the schedule development on "real" things—items which are measureable by look and feel. If you can touch, see, or count the result of various parts of the project as shown in the schedule, the plan will be more meaningful overall and more practical and effective as a management tool going forward. Most people can estimate how long it takes to create something concrete—generate a drawing, write lines of code, create pages of text or test cases. And having a concrete definition of "done" for each area of the schedule makes progress tracking much easier and more accurate. See Tracking with Visible Deliverables for some ideas on how to plan and track concrete pieces of the plan, rather than just making big long tasks in the schedule for everything.