The first phase of the PLC is the data-gathering phase. The project manager often is not aware of the project until it has been selected and the company is committed to pursuing it. When this happens, there may be very little available information about the project, at least in written form, and the project manager has to scramble to gather as much information as possible in a very short time.
Every project manager has experienced or will experience the scenario described above—a project handed to her with virtually no background or requirements list. When this happens, the only recourse is to find out where or how the project originated and then to question everyone associated with its selection. The objective is to determine why the project was selected, who is for and against the project, the basis of any budgetary and schedule estimates, and what the expected product functions are. If the project was initiated because of a contract award, then much of the needed data can be found within the contract documents or in any proposal that was submitted. In either case, the project manager's job is the same—ferret out the data he needs to develop the project plans.
Initially, the project manager must interpret the requirements and plan the project with minimum help because the project team cannot be formed until the level of effort is established. The first task of the project manager, then, is to quickly determine the general scope of the project and the skill sets needed to accomplish the requirements. This task is not as daunting as it seems because, according to her experience, the project manager will quickly develop a sense of the project size and complexity. The requirements will describe the project deliverables or products the customer expects. From this, the project manager can determine the types of skills needed. However, the wise project manager will first determine the general scope of the project and then solicit the help of her peers to develop the details. There are three reasons for this approach.
First, it is always better to have the combined experience and knowledge of a team than to try to know or remember or discover everything alone. Second, as the team members develop an understanding of the project, they will not only have suggestions about the needed skill sets but also specific recommendations about the people in the organization who are best suited to each task. Perhaps the most important reason for using your peers at this stage of project definition is their collective "lessons learned" experience. They will be able to help identify the risk areas in both the customer's stated needs and the organization's ability to respond to them.
The most critical activity in this phase is to identify the customer's requirements. In fact, I have devoted Chapter 4 to a detailed discussion of the subject. At this point, however, it is sufficient to understand that identification of the customer's requirements is vital because it defines not only the product, but also the actions and activities of the project team and the functional organizations supporting the effort. In short, identifying the requirements is the first step in defining the project scope.
Once the general scope is determined, the project manager can began estimating the number and types of resources needed for the project. It usually is not realistic to have all the requirements identified. As you will see in the next chapter, requirements identification is not particularly difficult, but it does demand careful attention to all the project documentation available, and it requires a disciplined process to ensure that all the requirements are identified. Thus, a general understanding of the project scope is about the best that can be accomplished this early in the project. Of course, the more information that is available on the project, the more detailed the scope definition. For example, if the project results from a bidding action and a contract, then the requirements and the scope will be well understood from the start. It is those projects that are internally generated, no matter how good or important the reason, that typically lack written descriptions or requirements definitions and are, therefore, difficult to scope.
Whether the project is well defined or the project manager is working with a general scope statement, the next order of business is to develop a high-level WBS. Again, the more detailed the requirements, the better the WBS will be. However, remember that the WBS is needed before any final estimates of the types and numbers of resources can be made, or the cost and schedule estimates can be developed.
As with defining the requirements and scope, it is generally better for the project manager to use a team of experienced people to help with developing the WBS. This decreases the likelihood of overlooking a task and increases the speed of getting the WBS completed. In addition, experienced people will have a wealth of lessons learned, knowledge that can aid in determining resources, usually by name. For those project managers who have to negotiate for resources, having the names of the individuals they want when approaching a functional manager is important. The individuals you want may not be available for your project, but presenting the functional manager with the request puts him on notice about the skill levels you need. In other words, it is a good negotiating strategy that often eliminates the problem of having a functional manager provide you with people who just happen to be available and who may not even have the required skill sets. To repeat, using an initial team of experienced colleagues can provide valuable information and save the project from future problems.
This initial team may or may not become part of the project team. In fact, its members often don't become part of the final team because they are likely to be too senior to be assigned task responsibilities. In addition, some of them may be running projects of their own. When the WBS is sufficiently developed to have an accurate view of what the project entails, what resources are required, and, most important, which functional groups in the organization are needed to support the project, then the major output of the concept phase can be developed—the project charter.
Project charters are extremely important to a project manager's success, and, thus, the success of the project. Yet, most organizations do not prepare project charters. This may be because of a lack of project management training. Or, it may be because these organizations have not embraced project management techniques and concepts as part of their corporate culture. In other words, it is a lack of education on the importance of this tool that likely prohibits its use.
A project charter is not a legal document; it is an internal document that is usually prepared by the project manager and signed by a person who is senior enough to have functional authority over the project and all the supporting functional areas. The primary purpose of the project charter is to name the project manager and to give him the authority to initiate the project. Many organizations will argue that they already have project charters because they send out an announcement each time a project begins. But the charter is more than just an initiation announcement; it is also a commitment to support the project. Each functional manager who is expected to supply resources to the project should sign the charter document. The charter is an excellent way of getting senior buy-in before the project begins.
The project charter usually is short—not more than three pages and often only one page long. The format varies from company to company, but generally it contains a brief scope statement describing the project, how the project supports the strategic goals of the company, who the project manager is, and finally, if possible, the project's priority within the company. The priority is the single most difficult thing to obtain because most companies view all their projects as having the same priority—number one. So even if you do manage to get a project charter written and signed, it is unlikely that you will have a priority assigned to it. However, if you can get a priority assigned, your life as a project manager will be a lot easier when you negotiate for resources. Exhibit 3-3 shows a sample project charter format that can be adapted to any organization in any industry.
Exhibit 3-3: A sample project charter outline.
Purpose (Scope statement)
Project Establishment (Business reason for the project and how it supports the company's strategic goals)
Project Manager Designation and Authority (Names the project manager and provides the range and limit of his or her authority)
Project Team Organization (Describes where the project team is within the organizational hierarchy)
Project Manager's Reporting Chain
Project Organization and Structure
Project Team Composition
Support Organizations and Support Requirements (Describes which functional groups are required to support the project)
Special Communication Requirements (Used if special reports or unique reporting data or cycles are necessary)
Appendixes (Some companies attach a more detailed scope statement to the charter than is usually given in the Purpose, above)