Project Initiation is the process or activities associated with defining the boundaries of a project, or project phase, and gaining the approval of appropriate stakeholders to begin the work of project planning and project execution. Project initiation is always company-specific. While many of the tools of project planning or project control are standard and universal, the initiating tools must interact with the company's business environment and strategy planning process, and therefore are far less formal or deterministic. The project objectives, which form the basis for project boundaries, are directly related to the business strategic imperatives. These are different from business to business and they change over time. The stakeholder analysis involved in approving a project are based upon a combination of the business organizational structure and the personalities of the individuals involved.
The Project Management Institute identifies several outputs from the Initiating processes. These are the Project Charter, a Project Stakeholder Register, and a Stakeholder Management Strategy. On small or simple projects I recommend that these all be rolled into one document. On larger more complex projects, I suggest that two deliverables are created during project initiation, a Project Charter and a Stakeholder Register that incorporates the stakeholder strategy decisions. I use a variety of tools and techniques to create these documents, depending upon project complexity and uncertainty. These include: W's, In-Frame/Out-of-Frame, Project Dimensions, Project Requirements Document, Communication Strategy Matrix, and Collaboration Strategy Matrix. The project leader needs to determine which of these tools and techniques are appropriate for their project. Typically only two or three of them are used. The project leader should always follow corporate policies and directives with regards to required tools or techniques. In addition, unique characteristics of the project may require different tools.
Project Charter
The Project Charter documents the basic attributes of the project, essentially the project boundaries. As such it captures the understanding of the project by the project sponsors and senior management at the time they approve the project to go forward into a planning phase. The charter is not an in-depth project plan. It is a high-level document. It describes the expectations of the customers of the project and the senior management for the project results. A charter is normally developed by the portion of the business that is sponsoring the project, not the project team. On small projects the charter may only be a one-page document. On larger projects, the charter may require many pages.
A project team uses the charter document to assist in the planning process. The team attempts to develop a project plan that has a strong potential of achieving the project objective while staying within the project schedule and budget boundaries found in the charter. An example of a Project Charter format that I have used on small projects with several clients is shown.
Stakeholder Register
The Stakeholder Register documents the stakeholder planning process. It is often started during the initiating process. However, this is a living document. While created during the initiating process, it is continuously updated throughout the life of the project. During the project new stakeholders are often identified and the role or interest of stakeholders may change due to changes in business priorities or reorganizations. The Stakeholder Register tracks these changes and guides the project leader in making decisions with respect to stakeholder interaction planning.
A project leader uses the Stakeholder Register to guide elements of the Project Communication Plan. In addition, project risks, reviews and decision meetings are often structured based upon the strategies documented in the Stakeholder Register. Further, the project attributes associated with the stakeholder's "Wins" will inevitably become linked to entries on the Risk Register.
W's
The "W's" are one of the simplest methods for identifying the boundary conditions for a project. This technique is often used with small projects. It consists of discussing with the sponsor the answers to several questions that have a "W" in them. These questions can be asked in any order.
"What?" What is the project intended to do or deliver?
"Who?" Who is the primary customer and are there any other key stakeholders?
"When?" When does the project need to end? When does it need to start?
"Where?" Where will the project activity be conducted?
"Why?" Why is this project needed? Is it related to a specific business strategy or goal?
"How?" How should this project be accomplished? Are there any constraints on the approach, any procedures or regulatory guidance that must be followed, or any financial or resource constraints? (The "w" was on the end of "How")
In-Frame/Out-of-Frame
The "In-Frame/Out-of-Frame" analysis is an excellent technique for clarifying project boundary conditions with stakeholders who are vague or often change their mind. An effective use of this technique at the beginning of a project will significantly decrease the incidents of scope creep. This technique identifies all of the major elements that are to be accomplished and puts them "In the Frame." It also lists activities, analysis and work that, though potentially related to the project, is not requested or required by the stakeholders. These items are listed as "Out of the Frame." An important clarification is that the "Out of Frame" items are not itmes being withheld from the stakeholders, rather there is an agreement with the stakeholders not to expend project time and project money on those items.
The "In-Frame/Out-of-Frame" analysis assists the project team in setting a clear definition of scope. Often there are several possible interpretations of a project requirement. This analysis clarifies the interpretation. This analysis minimizes the likelihood of scope creep because it forces the stakeholder to clarify the boundary of acceptable performance. Many instances of scope creep are due to stakeholders asking for "just one more thing." This analysis defines the limits of what can be done with the available time and money in the project. If at the time of project initiation the "In the Frame" list is more extensive than the desired end date or budget can reasonably be expected to deliver, the discussion with the stakeholder occurs at that time to either limit the project scope or increase time and/or money.
Project Dimensions
Karl Wiegers introduced the concept of categorizing the various project requirements into different "dimensions." These dimensions are related to the criticality of the requirements. This tool is useful on larger, more complex projects and programs. When discussing with stakeholders the nature of their requirements, determine how strategically important each requirement is. Some requirements are "Constraints." There is no flexibility with respect to these requirements. If this requirements cannot be met, the project is canceled. Very few requirements are truly in this category. For these requirements, the project plan should be constructed to minimize risk in those areas. The next category of requirements is "Drivers." These requirements are often expressed by stakeholders in terms such as, "As much as ..." or "As soon as ...." These requirements should be optimized to achieve the best overall mix among them. If you have many stakeholders, this may prove to be difficult as some stakeholders will probably need to compromise on there preferred solution or actions in order to accommodate some others. The final category is "Degrees of Freedom." These are items that are not requirements in the minds of any stakeholders, yet are elements of the project that must be accomplished in order to complete the project. Since there are no stakeholder imperatives with respect to these requirements, these are the areas where the project team should be the most creative and take the most risk. When completing a Project Dimensiopns I normally use a spreadsheet to capture the items. There are often more than one hundred items between all of the categories.
Project Requirements Document
A Requirements Document is a formal document that describes all of the requirements for a project. It is most commonly used in government contracting or large commercial construction projects and programs. This document is prepared by the buying organization in order for sellers to fully understand all requirements of a project when they prepare to bid on the project or portions of the project. When a government agency determines that it will source a major project effort, the agency develops the requirements document. The document contains all of the technical and managerial requirements appropriate for the government agency and the type of project work. The document can easily be hundreds of pages in length.
Communication Strategy Matrix
The Communication Strategy Matrix is a tool for determining the communication strategy to be used with each stakeholder. On a small project with one or two stakeholders, the matrix guides the project leader to determine the specific communication techniques to be used with those stakeholders. On larger projects with many stakeholders, the communication strategy for each stakeholder is a major input used when developing the project communication plan.
Each stakeholder is considered individually. The stakeholder is placed in one of the four quadrants of the matrix. Based upon the quadrant, the communication strategy for that stakeholder is set. One caution with this technique, a stakeholder's oversight or interest may change as the project moves from one phase to another or as business conditions change. Therefore, the stakeholder's position within the matrix should be periodically reviewed and updated.
Collaboration Strategy Matrix
The Collaboration Strategy Matrix is a tool for determining the type of collaboration that must be done with each stakeholder. Collaboration in this context implies that the stakeholder must be involved in the activities and decisions of a portion of the project. On a small project with only one or two stakeholders, the matrix guides the project leader in determining the level of involvement required from the stakeholder. On larger projects with many stakeholders, the collaboration strategy drives decisions on project planning and on project review meetings.
Each stakeholder is considered individually. The stakeholder is placed in one of the four quadrants of the matrix. Based upon the quadrant, the collaboration strategy for that stakeholder is determined. The selected strategy indicates the level of involvement by that stakeholder in decision-making, both during planning and execution phases of the project. The more stakeholders involved, the more project management effort required to manage the relationships and interactions with stakeholders.
