“In preparing for battle I have always found that plans are useless, but planning is indispensable.” – Richard Nixon quoting Dwight Eisenhower in “Six Crises” (1962)
“Plans are worthless when the fighting is once begun.” – British war correspondent in “The Daily News” (1877)
“The best generals are those who arrive at the results of planning without being tied to plans.” – Winston Churchill in “A Roving Commission: My Early Life” (1941)
I like these military-esque quotes in that they capture the paradox of planning IT projects well. IT Project Managers develop and publish elaborate project schedules only to find them repeatedly disrupted in the thick of project execution. Don’t get me wrong – I’m not suggesting that we should not develop project plans. However, what I am saying is that the planning is much more valuable than the completed plan.
Maybe it’s not more valuable to our senior management for whom we must publish a plan to hold the team accountable. Maybe not to our client who will be tracking our every milestone. Maybe not even to our teams for whom the plan establishes a shared understanding of our common delivery objective. But certainly for ourselves as we think through every possible assumption, risk, opportunity and pitfall of the project ahead.
Here are 11 ideas that I found very useful whenever I planned major projects:
- Think strategically. A Project Manager’s greatest temptation when developing a project plan is to immediately go to process and technology. But he/she should put on his/her business hat first. In my opinion, a Project Manager that does not have business acumen should not be managing projects. Projects are put in place to meet the goals and objectives of the end-user organization and to bring value to the customer. As such, Project Managers must be able to effectively communicate with the organization’s management and understand where the project fits within the strategic goals of the business.
This business orientation helps the Project Manager develop a more effective project plan oriented to the business rather than to just process and technology.
- Involve the Project Team. Project Managers must include the team (or at least team representatives) in the planning process. Team members want to know the roles and responsibilities for themselves and their teams. Their involvement in planning establishes an immediate sense of ownership of the project. Similarly, if end-users have been assigned to the project, they should be included in the planning process as well.
If you have been following my articles for a while, you are aware that my basic premise as to why our industry has such a dismal track record is that we forget project management is first and foremost people management. Yet we continue to focus on managing the process and technology. The project plan should have time allocated for periodic check-ins with IT staff, end-user staff, and other stakeholders, whether that time is formally on the schedule or informally throughout the duration of the project.
- Begin simply. So often Project Managers get so caught up in the myriad of details that are required to build a comprehensive project plan that they don’t know where to start. Certainly, if the IT organization has existing templates for project planning, these can take the stress out of the planning process with reminders of what should be included in the plan.
But more importantly, it is important to just get started. Project Managers don’t need to know it all or do it all. Team members fresh from another project bring recent experience to the planning process, and their involvement solidifies their commitment. The important thing is to put keystroke to computer screen and begin. Just begin.
- Use a rolling wave approach. Activities and tasks that are upcoming can be planned in detail. Activities and tasks of phases that are further out may be skeletal in the early planning stages. These can be detailed in the future as predecessor phases are completed and more knowledge is acquired for what is required.
- Work from a detailed statement of scope. While the development of a statement of scope is one of the first project activities (and therefore should be detailed in the initial project plan), a solid scope statement is the foundation for a solid project plan. Refer to my previous article, “This is How to Develop a Great Project Scope Statement” for concepts that can be used in defining scope clearly and thoroughly, involving the end-user team in the process. Included in the scope statement are those areas that won’t be completed as part of the project.
Along with a detailed scope statement, the Project Manager must be familiar with the project objectives and requirements. True, the detailed requirements will be elicited in an upcoming phase, but the high-level requirements help define the boundaries for the project. Those boundaries are clues to the Project Manager as he/she develops the plan. Involving team members who are most familiar with the requirements and scope aids in developing a more realistically executable plan.
- Estimate well. Poor estimating can ultimately result in project failure. I discussed estimating techniques in an earlier article (“The 4 Best Techniques for Estimating Activity Durations”), and recommended that the Project Manager request assistance in this activity. Peers and team members who will be delivering the project can be of the greatest assistance in developing a good baseline estimate. They know how long activities will take and where to leave space for unexpected issues. Based on their input, the Project Manager can set more realistic timelines.
- Avoid analysis paralysis. Planning is a detail-oriented, time consuming activity by itself. Care should be taken not to spend an inordinate time in planning at the expense of doing. Project managers should rely on their own experience or that of others to find an optimum level of required detail to enable the delivery teams to proceed.
- Request Peer Review. The deeper that a Project Manager is immersed in project planning, the greater the potential for blind spots. A review of the plan by peers who are expert in their areas (e.g. specialists in infrastructure, experts with development tools, knowledgeable facilitators for end-user activities) is invaluable. Similarly, using team members who will be on the project provides valuable insight into the plan’s viability.
- Document Assumptions. Nothing is more frustrating that that inevitable question, “Does anyone remember why we did …?” The intent of documenting assumptions is not for the purpose of later defending some action, but rather to map out why certain decisions were applied in defining the plan. Not only are these assumptions useful as the project progresses, but they prove to be valuable when analyzing execution results for lessons learned.
- Automate the Planning (and Tracking) Process. Developing project plans and then managing to those plans is hard work. If too many manual processes are required to create the plan and then track to it, too much time will be spent in “administrivia” and not enough in execution. Plus, too much manual process invites error into the management of the project.
The optimal solution is to maintain the plan in a central location allowing team members to access those aspects of the plan that directly affect them. Similarly, tracking progress against the plan should use a comprehensive work management system that allows team members to concentrate their time on delivery, not on organizing their time and updating time sheets.
- Build in Measurement Tasks. Every project should undergo an end-of-project review to document lessons learned, among other items. To assist in this review, the Project Manager should build in analytical and reporting tasks to capture relevant information along the way. Goals and Key Performance Indicators (KPIs) that are set at the beginning of the project can be tracked for historical purposes at preset points during project execution.
What was it that Eisenhower said? “In preparing for battle I have always found that plans are useless, but planning is indispensable.” Using these 11 elements in building project plans over the course of my career has resulted in some very good executable project plans. However, what I found through this process was that the actual planning activity, not the resulting plan, made for a more successful execution, as we could respond quickly whenever anything threatened to take us off track.
Get Your Free Guidebook
Subscribe and receive your free guidebook,
5 Ways to Master the Art of Managing People, Projects and Profits.