We looked at documentation and communication processes and tools for the project initiation process previously. 

Now I’d like to look at some of the critical things we communicate and document during the very important project planning process. 

Some of these items may have been ‘drafted’ as part of the initiation process or even possibly earlier in the process as someone was working to ‘win’ the project, but this is where they are fine-tuned into usable items on the project.

Budgets

Budgets provide a categorized breakdown of anticipated project costs. They define, by area, anticipated costs for the project engagement. The cost breakdowns are usually available for individual elements and are subtotaled by category and totaled for the project as a whole. Budgets generally serve as the organization’s expectation for project spending.

In most organizations, budgets are established so that funds may be properly allocated to a project. Although I am defining a budget as a planning tool, it may also be used during the initiation process in certain organizations where only well-defined cost plans are used in making the project go/no-go decision. Budgets serve as a spending baseline, to determine when project costs are or are not within the anticipated boundaries for spending.

Depending on organizational preference, the budget line items may be broad in scope (with a heading like “Resources”) or extremely detailed (with individual human and material resources, identified by name – which is how I like to plan, forecast and share my individual project budget information with the team, executive management and the customer when applicable). The budget is decomposed to the degree necessary for the organization to effectively use the information, and to the degree where the information’s accuracy may ultimately be reconciled with actual costs at project completion.

These actual costs normally include a percentage to acknowledge the organization’s investment and expense in administering a project. This burden rate may be different for human and material resources, depending upon the organization’s accounting practices. Normally, budget costs are broken out by resources and materials so that the burden for each can be easily incorporated and so that management can discern between human resource costs and material resource costs.

Some budgets are generated only at a very high level (with virtually no detail) because the information available early in the project planning stages is minimal and much is still unknown and only roughly ‘estimated’. Others break down the hours committed on a per-resource basis rooted in the resources committed at the work package level of the work breakdown structure. In either case, the depth of the budget should be acceptable to senior management, because their authorization is required to convert budget predictions into organizational allocations of funds.

Change control planning

The change control plan allows project managers to document how the organization and the project will handle change and to assert project-specific change control practices and policies in an effort to more effectively manage project modifications. It serves as the common process for all changes, and assets when changes may be deemed as formally “accepted.”

The change control plan is established either independently or with the support of the project management office (PMO) or project support office (PSO). It is provided to all project stakeholders who may either have an interest in changing the project or be affected by such a change. It is used to gain consensus on how and when changes will be implemented (or rejected).  And it is presented to the project customer so the both understand the process and can be accepting of the process and it’s end results.

The change control plan should identify organizationally standard change process information, as well as information specific to the project. It should account for a variety of stakeholders, including team members, customers, management, project office personnel, end users, and the project manager. As such, the change control plan has a far reach and can cross-reference a number of other change-related documents.

Communication Plan

The communications plan provides direction on which stakeholders should be discussing project business with which other stakeholders, the tools they should use, and the degree to which they should be sharing, documenting, and storing that information. Because of the number of stakeholders involved in a single project and their diverse roles, the communications plan orchestrates project communication through a cohesive approach to information sharing. It is a critical deliverable to the planning process.

The communications plan is shared openly with all internal project stakeholders to help them understand how they should communicate, when they should communicate and with whom they should communicate. For external project stakeholders, the communications plan is normally filtered to present information only specific to their role and use.

The communications plan should reflect communications as dictated by the contract, memorandum of understanding, or statement of work, as well as any other protocols that became self-evident during the project’s evolution. Different project participants will use the communications plan in different ways:

  • The project manager uses the communications plan to ensure that the various stakeholders are aware of their communications responsibilities to each other and to the organizations.
  • Team members use the communications plan as a combination contact list and guide, with an interest in the types of communication preferred by the various users.
  • Senior management and customers may use an abridged version of the communications plan to be clear on when to expect certain reports and documentation, and for contact information on their primary points of contact.

Test Plan

Whether it is intended for software, hardware, or process, a comprehensive test plan, as the name implies, is designed to guide an exhaustive test of the system in question. It identifies the potential areas of risk and explains how the system will be evaluated to determine its susceptibility to problems. The test plan also delineates how the test results will be validated.

Because a comprehensive test plan expresses a process to be used and then, later, is married to the results of that process, it is an evolutionary document. It grows as the available information grows. Initially, the comprehensive test plan serves as a road map for test conduct and validation. Later, it serves as a repository for the outputs of the tests, as well. As such the document is essential to those who will be conducting the tests and may be used as a defense for the costs of the tests or the approach.

A comprehensive test plan includes a history and step-by-step process guidance for the evaluation. Items that are likely to be part of the test plan include:

Background

The rationale for the tests is normally the first component of a comprehensive test plan, explaining why the tests were deemed necessary and what environmental considerations led to the primary approaches being considered. 

Testing approach

The actual technical approach to the testing should be defined in detail, including any materials required, the range of parameters the test will evaluate, specific areas to be tested, and indicators or metrics to be tracked. In addition, this may include testing of individual components of the system, as well as integrated systems.

Validation

Any validation processes, whether internal or independent, should be defined as objectively as possible. The validation processes should address the specific components being tested, as well as any integrated systems.

Outcomes anticipated

Test plans will sometimes include some explanations of the outputs anticipated from the testing process, so the anticipated outcomes can be compared with the actual outcomes. This should not be used to guide the testing outcomes, but should be used to identify if the testing process spelled out in the plan will actually produce outcomes of the type desired.

Outcomes tested

As stated earlier, the test plan can evolve over time. This information will only be incorporated after the testing is completed. This information may be incorporated in stages as preliminary and final testing may span several weeks, months, or years.

Design specifications

Design specifications, like blueprints, provide detailed guidance on what the project outputs will look like and how they will be expected to perform. The key difference is that design specifications provide that guidance through the written word, coupled with graphics and drawings, whereas blueprints are designate as graphics.  The purpose is to provide clear direction to the project organization on what the final outputs of the project must look like and the tolerances and standards those outputs must meet.

Design specifications are used as soon as they are available to determine some components of the work to be performed and to prepare for the purchasing and allocation of materials to the project. Because design specifications incorporate information about certain performance standards, the specifications can even be helpful in determining which resources are best suited to assist in or perform some of the work, because some work requires more highly specialized workers than others.

The design specifications are used to flesh out the customers’ functional requirements and technical requirements, expressing specifically how those needs will be addressed by the look and feel of the final deliverables. The components of the design specification should be traceable back to the functional and technical requirements, and there should be evidence that each component of the design specification will be addressed by some component of the work breakdown structure.

In deliverables-oriented organizations (in contrast to service organizations), the design specifications often become the document used to define project intent, expectations, and commitments. They are often referenced in project litigation as the rationale for certain approaches.

As with many project documents, the differences in design specifications may vary widely with the type of project being created. Since the design specifications are often the most detailed of the project documents, they can span dozens of pages (or even volumes) in larger projects. The common elements of design specifications are discussed in the following subsections.

Project resource plan

The project resource plan, in its many forms and formats, provides an understanding of when and how team members will be onboarded and utilized on the project and when they will be removed. Basically the project resource plans service as extension of the project plan that you would normally share with the team and customer using a viewing tool such as Seavus’ Project Viewer and input to the project plan and it defines what resources are required to achieve the project goals.

The project resources plan is used on a variety of levels. For senior management, it identifies all of the resources that have been delegated to a given project and the degree to which they will be working on that effort. For the project manager, it provides pinpoint information on which resources are working on which tasks. For the team members, it affords them the ability to know what they will be working on, for how long, and with whom.

The project resource plan includes either the names or the skill sets of the resources assigned to the project and the degree to which they will be used. Normally, this information is parallel to the activity list or the work breakdown structure. In either case, it is ideal when the list (and concurrent resource usage) can be condensed into summary levels for management review and then broken out into extensive project detail for team member application. The chart should incorporate the resource, the time and degree of usage, and the task or areas to which the resource is being applied.

Issue management plan

The issue management plan is a clear description of how the organization (or individuals) will contend with environmental, cultural, technical, and project-specific concerns that either exist or will inevitably come to pass. Because issues are conditions that must be dealt with (unlike risks, which may or may not occur), the issues management plan identifies concerns that must be either acknowledged or addressed.

The issue management plan is primarily used in two environments: management reporting and problem tracking. For management reporting, the plan is used to raise management awareness of concerns (in many cases, concerns that they have authority to help fix or somehow overcome through technology, resources, etc.). For problem tracking, the plan is shared with team members to ensure a consistent understanding of project issues and how they are being addressed.

The issue management plan includes details on specific issues and their potential resolution. Once an issue is raised, its status is updated regularly either through the end of the project or until it is uniformly considered resolved.  It’s good idea that your issue management plan also incorporate ownership details for each issue to ensure that someone is tracking the issue and determining whether or not escalation to a higher level of management is appropriate.

Kickoff meeting agenda

The kickoff meeting is one of the most critical elements of the planning phase, because this is the meeting at which team members, project managers, vendors, and the customer gather together for the first time. It is the opportunity to set the stage for the remainder of the relationship and to set expectations for what is to be delivered, how the project will be run, what assumptions are being made, and what key milestones should occur during the project – just to name a few things. Thus, the kickoff meeting agenda becomes one of the first true planning documents to be shared universally with all project stakeholders. It provides the outline of what will happen at the official project kickoff meeting.

A kickoff meeting agenda is used for both the internal and external kickoff meetings (if there are separate meetings – often there is just one ‘official’ meeting) to inform participants about the topics to be covered, the schedule, and the general intent of the meeting. It is provided, in advance, to all participants to allow them time to evaluate the meeting approach and to determine if there is any supplemental information they will need to gather prior to the meeting.

These meetings can be used internally to ensure that all participants convey the same messages to the customer. They can be used with external stakeholders to build a sense of excitement about the project and to ensure that the project organization’s vision for the effort is aligned with the vision of the customer. Internal and external kickoff meetings are normally different meetings with different objectives. The common elements for both include the effort to build the team and the clarification of project objectives.