One of the first activities a project manager performs when starting a project is to create a project work plan showing all the activities, dependencies, and durations required for the project to determine when the project will be delivered. This activity can take as much time as the project manager has and more, so it is important to make sure to focus on what you want out of the project work plan during the creation process. This focus will allow the project manager to determine whether spending more time on figuring out whether creating API #3 will take two weeks or three weeks is important to know.
The point to creating a project work plan isn’t to show that you know precisely what is going to happen on the project from beginning to end. (Typically, five days into project execution something has changed and you have to change the work plan.) The point is to help you focus on the important things and avoid getting caught up in the noise. A large project might have 5-6 simultaneous work streams with multiple sub-teams each. Each team is always producing something. The interface team, for example, might be generating 10 ETL jobs and 5 APIs in that month.
All of that work is important, but the project manager doesn’t need to know every detail. You’re really interested to know that API #3 is required input for the reporting group, which won’t be able to meet their deadline if they don’t receive a working version of the API by two weeks from Monday. Therefore, knowing that API#3 is going to take two weeks versus three weeks is important but knowing whether APIs #1 and #2 are going to take two or three weeks is less so.
When going through this effort, always remember why the exercise is important. It is very easy to waste time on minutiae, so focus is critical.
For me, the key questions you want to be able to answer after the plan is complete include:
- What is the critical path? People will always believe that something can get done “in two months”. It sounds like a lot of time, but you won’t be able to tell them why it will take longer until you’ve lined all the tasks and groups up to show that, no, really, this is a five-month project because of the following three key activities that can’t be shortened.
- Who are the stakeholders involved and when do they need their inputs? A perennial favorite of mine is the networking/infrastructure team. They tend to get told that the project needs a new production environment five days before the production date, but have lead times of 2+ months to procure the environments, open the ports required, do penetration testing on the application (which by itself generates more work for the project team), etc.
- What does one work stream require of another? Following up and managing cross-team dependencies is a key place where the project has issues. An adept project manager will help smooth the way.
- Is it complete? Have you been able to anticipate all of the activities required? Typically the answer is no. That is OK. Showing the plan and then asking for feedback always helps improve the quality of the plan.
Focusing on the questions you want to answer will help you focus on the important things (cross-team dependency dates and dependency dates) and accept a lower level of accuracy on things that won’t likely affect project execution as much (when will APIs #1, 2, 4 and 5 be complete as long as it is before testing).