In the PLAN phase, the team designs the selected project. Most of the work performed in PLAN becomes the foundation for implementation and post implementation management and it helps guide successful completion of essential project work. Here, the project team estimates and establishes the scope of work, defines and refines the project objectives, develops the course of actions to attain those objectives, and establishes methods for managing and controlling the project.
During PLAN, the project manager on-boards the project team. A formal kickoff for stakeholders and non-project team participants may be needed if the project is large and/or complex.
The first formal step in planning is determining the current state, if it has not already been mapped, to help support design of the desired future state. This is accomplished through a business process reengineering (BPR) evaluation, which documents the current processes and business needs, and identifies where waste, redundancy, and inefficiency may exist. Thereafter, the focus shifts to identifying the desired future state and analyzing the gaps between the “as is” and “to be” states. BPR does not eliminate all manual processes and some new processes may be a combination of manual and automated activities.
The sponsor and project manager, with assistance from other key participants, diagram the current state and the desired future state. These diagrams are used to help define the depth and breadth of organizational change that will likely need to occur. In projects involving end user organizational change in multiple agencies, each agency should conduct its own development of process maps upon commencement of its portion of the project. The process diagrams can be attached to the task in the project management software
Participants from the diagramming event should also develop an outline of key process changes and other factors that will need to occur during implementation and document them in the project plan for later reference. This can be accomplished in tandem with process mapping. Dependencies should be highlighted to ensure that critical steps are not overlooked. Similarly, stakeholders not immediately involved in the process should be considered in the event that a process change in one function has a significant impact on another.
Participants are encouraged to use a benefits dependency network diagram or similar tool, to illustrate the logical relationship between and among desired outcomes and other tasks that have a direct or indirect relationship to a project benefit and which must occur in order for the benefit or outcome to be achieved. The benefits dependency network diagram is retained in the project repository.
The project manager, in consultation with the sponsor outlines the project deliverables and documents them in the project plan. A deliverable is a unique and verifiable product, result, or capability to perform a service that is required to be produced to complete a process, phase, or project. A deliverable is a work product produced by a project team, team member, contractor, or consultant in accordance with the terms of their requirements or contract.
As a component of deliverables, the project team documents business requirements. Business requirements grow out of the product vision, which in turn, are driven by mission, or business goals and objectives. A business requirement can also be a condition or capability that is required to be present in a product, service, or result to satisfy a contract or other formally imposed specification. These may be used to evaluate to what extent a solution offered addresses the problem. Deliverables and requirements are maintained in the project documentation. Additional guidance on business requirements can be found in the Procurement – Contracting for Benefits Realization guidance.
The project team, in consultation with the sponsor and key participants and business/process representatives, identify measurable benefits/key performance indicators (KPIs). These are measures of success that may be defined by lower level metrics and are documented in the value register. They will be used to ascertain if the solution is performing as desired. The benefits toolkit or a similar template can be attached to the task in the project management software, or may be submitted with the phase review information.
The organizational change manager begins documenting lessons learned using the lessons learned template. Lessons learned may be collected throughout the project at various, different types of meetings and events, or at separately scheduled sessions at the conclusion of each phase. Maintaining lessons learned throughout the project allows the team to recalibrate future phases to address issues that may have arisen and ensure that lessons learned will not be forgotten.
The organizational change manager begins to identify and document relevant organizational change management (OCM) metrics to ensure that the leading indicators for people readiness and organizational adoption are achieved. These are documented in the Agency Engagement Center OCM Metrics tool.
The change manger also completes the communication matrix, which is revisited at each project phase, and uses the communications drafting tool to begin pre-positioning communications. The communications matrix defines and documents the business-side communication requirements and the approach for how information will be distributed. It describes the communication needs and expectations for the people side of change; how and in what format information will be communicated; when and where each communication will be made; and who is responsible for providing each type of communication.
The project manager creates a separate, parallel communications plan specific to project status and activities. These communications are generally targeted to technical or project team audiences and address things like schedule, scope, and technical issues.
The organizational change manager also begins work on resistance management techniques, with the involvement of the sponsor, and documents these in the Resistance Management worksheet. Additionally, the organizational change manager begins work on the training needs analysis which will be updated, finalized and used as the basis for training development during the EXECUTE and BUILD phase.
Using internal or external resources, the project team and sponsor conduct market research to gather information about potential solutions. Market research is a key factor in maintaining competitiveness. Market research provides important information to identify and analyze the market competition. Project teams should document the market research in a manner consistent with the market research guide and attach the results to the task in the project management software and submit it with the phase review information
Once market research has been completed, the project team analyzes alternatives. This entails breaking down a complex situation to generate different solutions and approaches in order to evaluate the impact of trade-offs. Various alternatives are often based on the results of the market research. The team should document the alternatives analysis in a manner consistent with the alternatives analysis guide and attach the results to the task in your project management software and submit it with the phase review information.
After the project team, sponsor and steering committee have studied and selected a preferred approach, the project team completes the Acquisition Plan/ Sourcing Strategy, which documents cost, schedule, technical, business, management, and other considerations that will govern an acquisition program. It summarizes the acquisition planning discussions and identifies milestones in the acquisition process. A successful acquisition is based on a sound sourcing strategy and the development of the sourcing strategy requires a thorough understanding of the project, a conceptual understanding of the resources required to deliver that strategy and the market forces that the sourcing strategy will utilize.
Once the acquisition plan is complete, the team begins to develop the procurement documents (RFx) in accordance with state and agency policy.
In conjunction with developing the acquisition plan the project team develops and documents acceptance criteria which are the performance requirements and essential conditions that must be achieved before acceptance of project deliverables. Document the acceptance criteria in a manner consistent with the developing and using acceptance criteria guidance or agency practice.
The project team begins work on the Implementation and Transition plan which is updated post-sourcing and during EXECUTE and BUILD.
Finally, the project manager begins development of the quality plan which describes how an organization’s quality policies will be implemented. The purpose of a quality plan is to define how quality will be managed throughout the project lifecycle to meet the stated quality definition, and the committed intent and requirements from a sponsor, stakeholder and or customer point of view. Document the quality plan in a manner consistent with the quality plan guide or apply agency specific requirements if more rigorous.
The sponsor approves the required PLAN deliverables and the project manager submits the materials to agency governance for review. The PLAN phase review is a formal examination of planning deliverables to ensure the project is well planned and basic project management principles have been applied before advancing to the next phase of the project.
At the completion of the PLAN phase, approval to proceed by agency governance releases funding for the EXECUTE and BUILD phase.
After the PLAN phase has been reviewed and approved, the project team releases a request for services to the market. The RFx may be developed during the sourcing strategy and acquisition plan development and should accompany the PLAN phase deliverables for review by governance before being released to the market.