Many tools and forms of documentation are used - and specifically needed during the initiation phase of the project. This is a critical time where getting a project started right is imperative if you hope to end it successfully. What I want to discuss here are various forms of documentation, communication and planning that are required or suggested for projects. Obviously, how much of this planning, formalization and documentation work your team does is somewhat dependent on five things: Timeframe available, budget available, size of the project, your own company's PM methodology, and the demands of the customer or project client.

Below is a list of 17 various forms of documentation, communication and planning that are required or suggested for projects.

Approvals

We all know about project approvals - they are those signatures required to achieve authorization of phases, milestones, resource allocation, or virtually any aspect of the project that requires acceptance or authorization by another party. Projects may be subject to dozens of approval cycles throughout their lifetimes. It's best to formalize them - otherwise it could come back to haunt one or both parties later on. But that may be determined more by the internal or external nature of the project, the size of the project, etc. The communications aspect of approvals is to ensure that they are shared, understood, and spread consistently within the organization. The basic purpose of approvals is to validate and provide acceptance of a project.

Approvals are normally conducted in writing and represent a commitment on the part of stakeholders. To receive an approval, the basic premise for which approval is sought must be documented thoroughly and clearly. This may be done through an approvals template, checklist, or other means, but normally requires a signature.

Approvals can take a host of different forms, but those that are most effective willinclude a succinct statement of what is being approved and a clear representation of the authority of the individual approving it, such as a signature.

Business Cases

The business case is basically the reason for the project. It establishes the fundamental rationale for a course of action. It is the documented history of why a project, effort, or approach was selected. It details the objectives, the projected outcomes, and the projected investments associated with the effort. As such, it allows decision makers to examine the breadth of information currently known about the effort to determine whether or not the project is a good idea in terms of cost, benefit, and organizational objectives. It may include statements about the impacts on existing business practices, resource constraints, and environmental considerations so as to provide a comprehensive understanding of the project. In some instances, risk analysis is a key component. It is the primary document defending the rationale for the project.

The business case is normally applied early in the project and may be developed by senior management, marketing groups, the project office, or by any group or organization responsible for initiating large-scale activity within the organization.

Business cases in mature organizations follow consistent formats to allow managers to review multiple projects in similar contexts.The business case will list the key proponents of the project, the sponsor, the users or beneficiaries of the project, and any deliverables. At a high level, it will describe the approach to be used and the business justification or rationale for that approach. Normally, that rationale will incorporate some form of cost/benefit analysis, although the types of cost/benefit analyses and their applications vary widely.

Business Justification

The business justification is similar to the business case - in many cases you only need one or the other in some form. For those who discern a difference, it relates to the use of the business justification to compare and contrast one project with another in the organizational portfolio. The business justification goes beyond simply trying to determine if a single project has sufficient benefits to warrant moving forward with it. It pertains instead to ascertaining the relative value of the project in comparison to other projects in the organization in terms of the organization's business strategies.

The business justification incorporates the strategic rationale for the project, and it may require an organizational model outlining the various strategies and their relative weight or importance, or it may list or delineate the ongoing efforts withinthe organization and the relative importance of this effort addition, it may incorporate the rationale for one approach in comparison or contrast with another.

Many tools and forms of documentation are needed during the initiation phase of the project. Of course, some are deemed 'extras' depending on the size or length of the project or the preferences of the customer who is paying for all the effort. However, it is extremely important to spend the proper time - during the initiation phase of the project - planning and preparing documentation, estimates and forecasts that will help guide your project to a successful conclusion.

Cost Case

The cost case provides a detailed cost justification for moving forward with the project, highlighting the financials and their supporting data sources. It also incorporates the relative levels of confidence and validity of the information being considered. In some cases and in some organizations, it is a component of the business case. The cost case or cost justification for the project is often considered the single most important component of the business case, but it can also be a standalone document. It is usually used to present information from accounting, marketing, or other internal financial research departments regarding predicted financial performance - for both costs and revenues - in the context of the organizations preferred metrics.

Cost Estimate

The cost estimate is a prediction of project costs either for a phase, the project as a whole, or for the life cycle of the system or product being produced. The cost estimate is most commonly used to determine whether or not the investment in the project will be worthwhile given the perceived gain. It will ultimately contribute to the cost baseline, which is a critical metric for evaluating performance against overall projections.

The cost estimate may be developed and applied at a variety of different levels. An initial feasibility estimate (sometimes referred to as a 'guesstimate,' or - more crudely - SWAG) is generally presented as a single number or value representing the overall anticipated cost of the project. It is not broken down into components or subcomponents but normally takes the form of a single monetary figure. Even for this value, there should be some explanation as to the scope of the project, the assumptions made, and the relative time frame for completion, because those considerations will ultimately impact the estimate.

A budget cost estimate is perhaps the most common, breaking out the cost estimate into its component parts. This estimate normally includes anticipated resource and material costs, as well as miscellaneous expenses, travel, and organizational overhead. This is the figure most often used to match up against the original sales price for effort and what profitability on the project will be gauged against. This will go into the project schedule and ultimately be viewable by the team and executive management using a collaborative tool such as Seavus Project Viewer.

Customer Requirements

Without good customer requirements - however you come about obtaining them - the project really can't survive. I will always contend that requirements are the lifeblood of the project itself. The customer requirements delineate, in detail, what the customer needs and how the project will serve those needs. Requirements represent a detailed breakdown of the customer's expectations for the project, and often how the project organization will serve those requirements. Requirements documentation provides long-term guidance for development of the work breakdown structure (WBS) and creation of the detailed project schedule - which should always be shared with your team and customer. The customer requirements document serves as an ongoing reference as to what elements of project work are either in scope or out of scope, and in some cases, provides insight into the degree of importance of some elements of scope.

Depending on the nature of the requirements document (functional or technical), it may have radically different applications. The functional requirements document addresses the needs of the customer as expressed in terms of performance. The technical requirements document addresses how those needs are to be met. The functional requirements document is outlined in terms of performance, capability, and customer expectations. The technical requirements document is also outlined in those terms, coupled with the technical response about how those needs will be served. Keep in mind, because of the unique nature of projects, project requirements documents may look different, even when they are generated by the same organization.

Feasibility Analysis

The feasibility analysis is designed to determine whether or not, given the project environment, a project will be successful - but keep in mind there is no perfect predictor of project success that exists in the world! A feasibility analysis may be conducted for a project with an emphasis on financial viability, environmental integrity, cultural acceptability, or political practicability. It is a determination as to the likelihood of success and a description of how that determination was achieved.

Feasibility analyses are used to present an approach or a series of alternatives and to offer decision-making guidance based on the climate in which the project will evolve. They often defend a single or primary approach, incorporating extensive forecasts on the project's development, as well as its evolution after implementation. Because a feasibility analysis may focus on one or many aspects of a project, it may be a very short (one- to two-page) or long (multivolume) document. In any case, it generally begins with an executive summary and a description of the project outputs in their as-built condition.

Impact Analysis

An impact analysis looks at the planned outcome of a project and its potential effect on the environment around the project - the business environment, the physical environment, the financial environment, and the political environment. At the very least, an impact analysis will highlight the differences in the environment between the status quo and the environment after the project has been implemented. At the extreme, the impact analysis may look at many degrees and levels of project impact, as well as the impacts of alternative approaches.

An impact analysis can be used to either heighten or allay concerns about a project's outcome by focusing on post-project conditions. It can be applied either prior to or after the project has been implemented. If developed prior to the project, any assumptions used to determine post-project conditions should be clearly stipulated and any tools applied to achieve the future state or end result need to be identified as such. If developed after the project has been implemented, the sources for any historical information regarding the pre-project state should be acknowledged as well.

The content for an impact analysis is most commonly quantitative in nature. Qualitative impact analyses are fairly uncommon, but not unheard of. However, qualitative impact analyses usually are employed to defend a particular or single point of view. In some instances, qualitative assessments will be converted to quantitative values through preordained metrics or surveys. In any case, the effort should be to keep the assessments as objective as possible.

Mission Statement

At the project or organizational level, a mission statement provides a single-sentence - or one paragraph - statement concerning the object of the project. The mission statement serves as a guidepost for action, establishing where the project is supposed to be headed.

The mission statement is normally used as a public pronouncement, posted prominently to declare organizational intent. It is not used for detailed planning, but instead as a validation of any approaches, processes, or deliverables in terms of strategic direction. The forms for such statements are relatively consistent. Think of it more as a call to action and a unity statement than anything else.

The content for an organizational mission statement is normally developed at the senior levels of the organization, expressing their intent for the long-term goals. The content for a project mission statement is normally developed by the project manager and his team, expressing their desired project goal and how its deliverables will serve the intended body of stakeholders. Although it is not uncommon for the mission statement to ultimately be handed down by someone in executive management who holds the project near and dear to their heart.

Organizational chart

As with the mission statement, the organization chart may be developed at the project or organizational level. At the organizational level, the chart is used to define the hierarchy of who works for whom and to delineate the reporting structure of the organization. At the project level, the organization chart may focus slightly more on who works with whom, in terms of project task integration.

Organization charts are used to communicate the staff hierarchy. They are usually publicly available and provide staff with the ability to see the chain of command from the worker level up to the highest levels of management. Some organization charts may be used to determine peer status with other components of the organization.

The traditional organization chart identifies the chain of command, as well as the peer-to-peer hierarchy. Because of the depth of the reporting levels on the chart, for example, the vice presidents know that they are all at the same relative level of importance and the same is true of the managers beneath them.

A project organization chart is virtually identical in structure, but it may differ if it is broken down by deliverables, as well as function - because the two are of similar importance. Some project managers may link the organization chart directly to the WBS, creating an organizational breakdown structure of the work to be performed. However, the depth of information provided in an organization chart is limited.

The way in which the organization chart is broken down is largely a matter of personal preference, although professional need may enter into the decision. Because the project organization chart can be broken down by function or deliverable, the question should be asked as to which approach provides the greater understanding of the project and the interactions of those serving the project - and this probably depends on the project AND the organization. Some organization charts may feature dotted or broken lines representing secondary reporting relationships. A clear legend should accompany the organization chart if alternative types of relationships are displayed in the chart since understanding and comprehension is important and it may become cumbersome.

Press kits

Press kits are a key component of a press briefing, normally held to inform members of the media about a new project or the status of the project, its environment, or its supporting organization. Obviously, they are intended to present the project organization in the best possible light.

Press kits are constructed when a project or its impact is sufficiently significant that public information campaigns using mass media are appropriate. They should be developed whenever the project has achieved sufficient recognition that the project organization's perspective on the effort will be deemed to be of public interest or when the press requests information on the project. Keep in mind that public recognition may be positive or negative in nature, and may be proactive or reactive, depending on the nature of the project and the project organization.

Content for a press kit should be determined well in advance of any press briefing to ensure that the correct information is shared and any information that the organization does not want to share is clearly defined for those hosting the briefing. The press kits will highlight corporate history, general information, past press releases, and any contact persons' business cards. They may also include small product samples, if this is relevant to the project. The press kit should also include a press release.

Press release

A press release is issued to provide public awareness on an issue of importance to the organization. It serves as a formal expression of the organization's stance on that issue, and frequently provides commentary from someone in your organization's executive management - often a key high-end stakeholder or even sponsor. It may be in response to environmental conditions affecting the organization or may be initiated to promote the organization's perspective.

Press releases are used to encourage favorable media coverage of the organization. They are used by the media, either in whole or part, as a component of news or public service coverage. They may be used as written, but are frequently rewritten to fit the style of the media outlet. Because major media outlets may receive hundreds of press releases in a given day, releases are often managed by large media services, who channel the information to as many outlets as possible. Some press releases are accompanied by media information kits, providing background information, samples, or novelties to encourage more in-depth or favorable coverage.

A press release normally includes a headline, contact information, a dateline, andthe body of a story that the organization considers of interest to the public or to the intended audience. It is normally written using newspaper-style guidelines to facilitate its use without significant editing. The top third of the page should contain most of the information essential for an editor to make a decision as to whether or not the story is appropriate for use. The content should reflect the traditional depth of understanding of the intended audience. For instance, the content of a press release for a local newspaper may be less in depth than the treatment of the same story for a professional journal or trade magazine.

Project charter

The project charter is a foundation communications tool in project management. It serves to grant the project manager the authority that he needs to manage resources and to clarify the scope of the project - at least in general terms. In theory, it is drafted by executive management as their means to clarify the roles and responsibilities among the project staff, but in reality it is most frequently developed by the project manager, who then directs it to management for their approval.

The charter is used as a reference document to affirm the level of resource commitment and organizational support for a project. After it is created, it is maintained by the project manager, and provided to functional managers on request to confirm intended resource utilization and rationale.

The charter normally incorporates a general scope statement, as well as a list of the resources that will be applied to support the project objective. It may include both internal and external resources, as well as the signatures authorizing their use through the life of the project. The charter should also include a specific time frame in which those resources will be applied, indicating when they will be returned to their traditional or functional responsibilities...in a perfect world, of course.

Project proposal

The project proposal is a pre-project document that recommends a project for initiation, provides a rationale for the project, and suggests approaches and staffing. The proposal is an early component of project documentation that serves to launch the project. It does not necessarily consider or incorporate the entire technical solution for the project, but does offer a suggestion that the project is appropriate, necessary, and worthwhile. And it usually comes with at least a draft project schedule planned out to show understanding and ability to deliver (i.e., available resources, understanding of tasks and deliverables, etc.) that can then be turned into the baseline schedule that can be shared with your team and customer using a tool like Seavus Project Viewer.

Less detailed than a formal feasibility study or analysis, the project proposal is intended to raise awareness that a project may be appropriate and viable. It can be used at almost any level of the organization and is usually drafted by a team member or senior executive. At a minimum, it provides a general description of what the project is supposed to accomplish and how or when it could be implemented. At the extreme, it may describe not only the project deliverables, but the approach, the resources to be applied, and the alternative approaches that could be used for implementation. It is used to present ideas to anyone responsible for project selection and to initiate the selection process.

The project proposal defends a particular perspective or approach to solving a problem or creating a solution. Some of the items, as noted in the following list, may be considered 'optional' content for the project proposal. However, they will ultimately have to be included in some project analysis before a final go/no-go determination is made. The project proposal should incorporate the following items:

• Name of the project
• Initiator
• Project sponsor/champion (optional)
• Technical/support organization (optional)
• Project description and justification
• Recommended manager/resources
• Project budget/schedule (optional)

Project request

Because different organizations interpret project requests (as a practice) differently, their purposes may vary as well. A project request may be a simple one-paragraph description of a project that has been formally submitted to management (either through a chartering process or proposal process). It may also be a specific form or format for submitting initial information about a project that may be of interest to the organization or that may serve an organizational need. For the sake of this discussion, the latter is assumed.

A project request is used as a means to initiate ongoing analysis (feasibility study, impact analysis) of a project concept. Information available for the project request is generally somewhat scant, as the project request is used only to trigger other processes.

A project request form often includes only the most elementary information about a project concept:

• Project name (or a few-word description)
• Project description (may include a brief description of the goals or objectives of the project, as well as any problems/concerns it is designed to resolve)
• Timing
• Special resource needs (may include material or human resources essential to project initiation or implementation)
• Support organization (the anticipated 'home' for the project if it is determined to be viable)
• Name of person completing the form

Although other information may be incorporated, these are the essentials for initiating a project request and ensure that a consistent baseline set of information is available for any project that will undergo further study or scrutiny - and, of course, expansion.

Scope statement

The scope statement may be embedded in a variety of other documents, including the project requirements document, the project charter, and the project proposal. It provides a single-statement, single-paragraph, or single-page overview of the project and its boundaries. It describes the project in clear objective terms, highlighting the outcomes and any deliverables associated with the effort. If there is a significant probability of misunderstanding, the scope statement is used to refine what is not included as part of the project, as well...meaning, 'it does not include this, etc....'.

The scope statement may be an integral component of a variety of documents such as the business case, the business justification, customer requirements, feasibility analysis, project charter, project proposal, and project request. It is used to convey a consistent vision of the project and its outcomes and to clarify project intent. In discussions about a project's goals and objectives and what should or should not be included, the scope statement is often the final word in a summary format. The scope statement is comprised of a clear description of the project, its outcomes, and approach. This brief statement captures the nature of the work to be performed and of the work not to be performed.

Statement of work

The statement of work (SOW) serves as a guideline of the agreements on performance between a purchasing organization and a seller of goods and/or services. It is frequently an attachment to a contract or a memorandum of understanding between two organizations, but it may also be its own stand-alone document. The SOW affirms how the purchasing organization wants the work to be performed and the context of that performance, including any specific management practices or protocols the contractor must follow.

Often it becomes something that I base most of my kickoff meeting materials on - hoping to lay the project out using this document for everyone to see and agree on scope and expectations.

The SOW is normally used as an attachment to the contract or agreement and isone of the very earliest documents developed to clarify communications betweenorganizations. As a component of the contract, it is frequently used to settle disputes over what work should or should not be included in a project in a more detailed form than presented in the scope statement discussed above. It establishes expectations for a variety of issues in the contract relationship.

Because the SOW is normally an attachment to the contract or agreement, it is a primary reference document for the project manager throughout the life of the project. Also, because the SOW is most often developed by the organization requesting the project product or service, it normally reflects a functional, rather than technical, perspective. Although the customer may have technical expertise, the work they will identify in the SOW is frequently performance oriented or performance based.