The project management plan (Plan) is a powerful tool. It describes how the project will be executed. It should be tailored based on the project’s context and needs. A good Plan reduces the likelihood of misunderstanding, conflict, and disappointment. Unfortunately, in the rush to start a project, insufficient time is often devoted to creating the Plan.
This article presents a framework for modeling project context and considerations for tailoring. Enterprise templates and prior Plans can serve as the starting point. The Plan should be sufficiently detailed to provide clarity without being overly perspective.
Project Context
The first step is evaluating the project context. A simple framework considers the following dimensions:
- Problem Complexity. Projects can solve simple to chaotic problems [1]. More complex problems require more detail.
- Solution Complexity. Projects using well-understood solutions and technologies require less rigor.
- Organizational Complexity. The team's size, maturity, tenure, and proximity influence the ease of coordinating their efforts. A small, longstanding, co-located team may have an established operating rhythm. A new, large, distributed team will require more structure.
- Compliance. Projects may be subject to regulatory or enterprise compliance standards.
Project context can be mapped across these dimensions. The further from the center, the more detail and structure are required. Closer to the center, the Plan may be less formal or follow established operating guidelines.
Plan Elements
The Plan is like a book with three main sections:
- Execution Parameters establish how the project will be managed along with the approach, required lifecycle phases, and governance procedures.
- Domain Management Plans describe how the project domains (PMI knowledge areas) will be planned, executed, and monitored.
- Project Baselines and Other Performance Metrics. Scope, schedule, and cost are the primary metrics for monitoring project performance.
Existing organizational assets, such as tools, templates, and standard practices, influence the Plan. Mature organizations often have required or recommended tools and procedures.
Execution Parameters
The execution parameters are one-time, strategic decisions impacting how the project will be managed and executed.
Approach and Lifecycle Phases
The approach establishes the methodology or framework. There is a range of options, from predictive to agile [2]. Problem complexity, technical complexity, compliance requirements, and the cost of change factor into this decision.
Projects where the problem and technical complexity are low, and the cost of change is high may favor a predictive methodology. Complex efforts where the cost of change is low may prefer agile. Hybrid approaches may enable greater flexibility but require more detail.
Lifecycle phases describe the required process steps from inception to delivery. The project type, industry, and compliance requirements inform what steps and phase gates should be included.
Governance
All projects require oversight and governance. The degree is a balance between control and efficiency. All the tailoring dimensions and stakeholder needs inform the level of governance, oversight, and management reviews. Defining these practices establishes clear expectations for the project team, customers, and executive stakeholders.
Domain Management Plans
The domain management plans define the processes for planning, executing, and monitoring the project’s performance; and are sections within the overall Project Management Plan. These subsidiary plans describe the techniques, tools, practices, and metrics used. They establish the expectations and operating rhythms for the project team.
Requirements & Scope
Requirements and scope management describe how stakeholder needs are identified, prioritized, monitored, and the final product is accepted. The project type, scale, compliance, problem, and technical complexity influence these plans.
The project approach circumscribes primary aspects of this domain. On agile projects, the product owner represents the customer. On predictive projects, customer representative(s) needs to be identified. For all project types, establishing the process and rules for prioritizing requirements and accepting deliverables is needed.
Schedule & Cost
Schedule and cost are primary elements for planning and monitoring project performance. The project approach establishes common execution patterns. Enterprise tools, standards, and financial management systems will impact the cost plan.
Traditional projects use a work breakdown (WBS) and Gantt Charts [3] to build the project schedule and identify the critical path. Changes in the critical path and planned versus actual schedule and cost variances are used to measure performance. Acceptable variances, reporting cadence, and status meetings are addressed in the plan.
Agile projects are fundamentally different. Team size is known, and the project duration can be time-boxed which simplifies estimating the project’s time and cost and monitoring its performance. Agile projects favor radical transparency, so the reporting processes are less formal. Burndown, burnup, and velocity charts are used to measure performance.
Stakeholders & Communications
Stakeholder engagement is the key to project success [4]. The stakeholder management plan describes the process for identifying, assessing, and engaging stakeholders. Communications management defines the who, what, when, and how of project communications [5].
All of the assessment dimensions, along with the organization’s culture, inform these plans. A lightweight plan may suffice when the problem and solution space are well-defined, and the stakeholder community is small and aligned. Comprehensive plans are needed for large complex projects with multiple constituencies with low stakeholder alignment.
Risk
Risk management describes the practices for handling uncertainty. The plan may include the categories, processes for identifying and assessing risks, and a framework for developing response strategies. All the assessment domains influence the plan's detail and rigor. Projects with life-and-death implications require greater formality.
Enterprise risk management frameworks can inform this plan but may be scaled for relevance. Defining the parameters for assessing risk (e.g., likelihood, impact, urgency, etc.) creates a common taxonomy and stakeholder alignment.
The plan should describe the practices for creating and monitoring response strategies. Which risks require a response strategy? How frequently are the risks and response strategies reviewed? Decision-making authority and escalation paths may be required for complex projects and high-compliance projects.
Quality
Quality management focuses on both process and product. The plan is informed by compliance, solution complexity, and enterprise standards. Quality managers and SMEs may assist in developing this plan.
Process management is the continuous pursuit of excellence. This section should describe the processes, practices, and tools used. The project type and approach may define the process guidelines. For example, construction projects must follow safety requirements, and software projects may follow process maturity models.
Product quality ensures that the product or service meets the stakeholder's expectations. The plan describes which tests or inspections are to be conducted and the expected outcomes.
Resource and Procurement
Resource management describes the process of identifying, acquiring, and managing the resources required for the project, including people, supplies, and equipment. Procurement management is specific to externally sourced resources.
Enterprise policies, standards, and practices will set resource management and procurement parameters. Human Resources, Procurement, and Legal may provide substantial input.
Understanding the project environment and the organization’s culture will guide this plan. Traditional projects tend toward command-and-control approaches, while agile embraces servant leadership practices.
Knowledge
Knowledge management encompasses both internal and external project needs. Internally, the focus is on developing and maturing the team. Externally, the needs of customers or those supporting the product must be considered.
The organization dimension provides insight into the team’s knowledge management needs. Longstanding, high-performing teams require fewer formal practices than new teams. Formal documentation supports the transmission of explicit knowledge. Wisdom (implicit knowledge) is best shared through planned collaboration activities.
© 2023, Alan Zucker; Project Management Essentials, LLC
See related articles:
· Engage Your Stakeholders [6]
· Knowledge Management: Share the Wisdom [7]
· Project Frameworks: Understand the Choices [2]
· Gantt 101: Building a Better Project Schedule [3]
To learn more about our training and consulting services or subscribe to our newsletter, visit our website: http://www.pmessentials.us/ [8].
Image courtesy of: atoha.com