At the very minimum a project plan must answer these three questions:
What is to be done?
When should it be done?
Who should do it?
The project plan generally starts taking shape as soon as a project manager is assigned to the project. The project manager will have some idea of what is required from the scope statement, contract documents if it is an external project, or any information gleaned from those who selected the project or directed that it be done. If the project manager was fortunate enough to have been included in the embryonic stage of the project, then she is way ahead of the learning curve. Otherwise, she must resort to other means to determine what the project is all about.
Determining What to Do
We explored this subject in some detail in the last chapter, but it is beneficial to review the process.
Determining what to do is simple in concept, but not always easy to accomplish. The difficulty of determining project requirements is directly linked to how detailed and well written the customer’s needs are stated. That seems simple enough, but the fact is, more than half of all projects start out with poorly stated or poorly conceived project requirements. So the project manager must first determine what is to be done. He must ask this question: Why are we doing this project?
If the SOW, contract documents, or other written documentation define the project requirements, then determining what is to be done is generally a matter of restating the requirements in a work breakdown structure format and assigning tasks and responsibilities. If the project is internal to the organization, or the customer is not sure what he wants, then the project manager has to determine the requirements. Determining the requirements under these circumstances is done by asking a lot of questions—questions of those who selected or generated the project and questions of those who are for and against the project. Remember that it is just as important, if not more so, to know who is against the project, and why, as it is to know who is for the project. This is because the relative strength of these stakeholders in the organization can shape the final requirements. Without knowing the individual stakeholders’ agenda, the project manager quickly finds himself pursuing requirements that are being subtly changed by a powerful functional manager.
Determining when the project’s deliverables are due drives the number of resources required and vice versa. My personal approach is to first determine when the customer needs the product and then to determine how many and what type of resource skills it will take to complete the job. What I discover from this exercise determines whether I need to acquire more resources, either internally or externally, or whether I need to renegotiate with the customer. In short, the schedule, numbers or resources, and budget are so interrelated that they generally have to be analyzed and developed together. But the first step is to determine when the project’s deliverables are due.
Determining When It Should Be Done
The schedule is driven by first to market considerations, the customer’s operational needs, or maintaining or creating market share. No matter the reason, the project manager’s job is to determine how the schedule can be met.
Almost every project has a dictated schedule, and it is almost always an unreasonable one. Customers do not want to hear that the schedule is unreasonable; they want to know how you are going to meet it. If this sounds far-fetched or even crazy, you may be right on both counts. The reality is that schedules are set for, at least in the customers’ minds, very good and plausible reasons, and it is the responsibility of the providing organization to meet schedules. Therein lies a major communications gap between the provider and the customer, and it is one that usually results in project failure or at least less than satisfactory project success. The sad reality is that there is little that can be done to correct the problem. So what is the project manager to do?
Determining the schedule is straightforward. First, the project documentation will very likely contain a “deliver by no later than” date, that is, a delivery milestone. If so, the schedule is fixed. The task then is to determine whether the date can be met. Usually, the schedule, even an unreasonable one, can be met given enough resources. The problem, of course, is that there may not be enough resources in the company, which requires hiring or contracting for additional skills. Even when there are enough resources, there is a break-even point beyond which it becomes cost-prohibitive.
If the customer does not dictate the schedule—an unusual occurrence, but it happens occasionally—then the project manager and her team can develop a schedule based upon the numbers and skill sets needed. Actually, this is a best-case scenario, and one that the project manager should lobby for because the resulting schedule is reasonable and likely to be met.
The usual scenario for determining the schedule is that the requirements are determined, a WBS is developed, and a network, usually a precedence diagram, is drawn to show the task dependencies. From the network analysis, a good estimate of the schedule can be determined. It is important to remember that when determining task durations for the network analysis, the number and skill sets available for the task have to be considered. Otherwise, the estimate will be inaccurate, and the schedule will not be achievable. Once the network is drawn and analyzed, it is a simple matter to determine the shortest duration for completing the project and whether it is possible to accomplish the project in the time allowed by the customer. If not, then the project manager and his organization can make the decision about how to shorten the schedule—usually this involves who is needed for the project, which is the next important planning consideration.
Determining Who Should Do It
During teaching or speaking opportunities, I often ask whether anyone belongs to an organization that assigns team members to the project as opposed to having the project manager determine who is needed and then negotiating for them. Usually there are a few people who have their resources assigned, so the practice is not uncommon. But more commonly, it is left to the project manager to analyze the need, determine the skill sets required, and then to negotiate for the resources.
Logically, one would expect determining the team makeup to be a relatively straightforward, if not simple, task. The project manager probably knows everyone in the organization and probably has worked with most, if not all, of them. With relatively small or not too complex projects and in smaller organizations, the task of determining skill sets and available resources is actually not too difficult. It is with complex projects, requiring widely different skill sets and cutting across several functional lines, that the task becomes enormous.
The best approach for determining required resources is to elicit the help of what I call an initial team. This team is composed of other experienced project or functional managers and other senior personnel. I call it an initial team because these people will not function as team members once the project gets under way—they are too senior to work as project team members. The function of this initial team is to help the project manager analyze and define the project requirements and to determine the skill sets needed. Once the skill sets are known, the resources can be identified, and this initial team will be able to recommend specific people to serve on the project team.
When negotiating for resources, it is very important to remember that one should ask for a specific person. If the functional manager from whom the resource is requested is not presented with the name of a specific individual, then she will likely provide the first available person, regardless of whether he has the requisite skills and experience. Asking specifically for someone may not yield the desired result, that is, the individual may not be available because he is committed to other projects, but it alerts the functional manager to the specific level of skill and experience needed for the project. From a negotiating perspective, this approach puts the onus on the manager to provide someone of equal or better qualifications.
After the resources are identified and their use on the project guaranteed, the project plan can be more fully developed.