Download: Free Project Plan Template
How to Develop a Project Plan
A project plan is a detailed document about how a project will be managed and delivered.
There are 4 major phases in traditional or predictive project management: Initiation, planning, execution, and closing. The most important output of the planning process is the project management plan. However, planning is not simply a work breakdown. It’s planning for all the aspects of project work from stakeholder management to risk management. The extent of planning work will vary based on the type and complexity of the project or industry. Regardless, many routine project plans will be developed by following these steps.
- Define the Project Scope
- Gather Requirements
- Develop a Work Break Down Structure
- Assign Resources
- Develop the Budget
- Develop the Project Schedule
Similar Article: The Best Project Management Software For Small Businesses
Step 1: Define the Project Scope:
Before starting any project or drafting a project plan it is important to define the scope of work. Information about the scope of a project can be found in any of these documents:
Read More about these documents or click here to jump to step 2
- Project Brief
- Project Charter
- Statement of Work
- Business Contract
- Business process documents
- Product Requirements Document
Project Brief:
A project brief is a concise document that outlines the essential components of a project such as its scope, stakeholders and budget.
A typical Project Brief will contain the following sections:
Project Overview:
A summary of the project.
Objectives:
Specific outcomes of the project.
Scope:
This section should describe the boundaries and context of the project. It should provide a clear understanding of what is included and excluded from the project work. This helps prevent scope creep and ensures that everyone involved in the project understands its limits.
Deliverables:
A list of the specific project outputs or results. This could include documents, prototypes software or products.
Timeline:
This section contains information about the project timeline including key milestones and deadlines.
Budget:
This section contains information about the project’s overall budget and whether there are any key budgetary constraints.
Roles and Responsibilities:
This part contains information about the responsibilities of key team members. This improves clarity on who is responsible for what
Stakeholders:
A list of all the project stakeholders.
Risks and Assumptions:
You should list potential risks that could affect the project’s success and any assumptions around the project.
Project Charter:
At most traditional project management organizations, the project charter formally authorizes the start of a project. It contains similar information as the project brief. The project sponsor typically approves the project charter based on the information in it. Developing a project charter involves engaging key stakeholders to increase commitment, and ensure robust project requirements.
Statement of Work
This document describes the scope of a project, its objectives, deliverables, deadlines, milestones, quality requirements and, in some cases, the budget and resources required. Essentially, it serves as a guide for both the client and the contractor, ensuring clarity and agreement on what has to be done and how it will be done. Having this document helps both parties manage expectations, and minimize assumptions. It also provides a foundation for evaluating the project’s success after completion.
A typical Statement of Work will contain the following sections:
Introduction:
The objectives of the project and the parties involved.
Scope of Work:
This includes tasks, deliverables, and any specific requirements.
Schedule and Timeline:
This section outlines the project timeline, including key dates (where applicable) and major milestones.
Roles and Responsibilities:
This section defines the responsibilities of each party involved in ensuring the project’s success. This can include prompt response to requests from the contractor or providing a key point of contact for clarifications or project check-ins.
Quality Standards:
This section contains information about any relevant quality standards or benchmarks related to the project deliverables
Change Management:
Outlines the procedure for adjusting the project scope, timeline, or budget.
Payment Terms:
Contains information about the cadence and method of payment for executing the project.
Acceptance Criteria:
Some SOWs will also specify the acceptance criteria for the project deliverables
Business Contract
The scope of a project can also be contained in a business contract. While the structure and nature of a contract will vary depending on the parties’ preferences, it will contain information about the specific goods, services, and obligations of both parties. It will also contain terms and conditions such as payment terms, performance standards, and warranties.
Business Process Documents
Some organizations define the scope of certain projects within standard operating procedures or similar documents. This usually applies to projects that have a well-defined scope.
Product Requirements Document
The Product Requirements Document is well-known in software development for guiding development teams. It details the requirements of a product, including features and functionalities, acceptance criteria, scope and the value positioning of the product. Some PRDs will contain the project or product scope.
Step 2: Gather Requirements
Project requirements are the mandatory specifications or criteria that must be met to achieve the project objectives. They guide the project team in planning, executing and validating completed work. To complete this step, you must review the available business documents, analyze the business environmental factors, and consult with stakeholders. There are different types of project requirements and typically, they can be found in the Product Requirements Document or Statement of Work.
However, reading business documents for requirements is half the job. I can’t overemphasize how important stakeholder collaboration is, before you start breaking down the work.
Read More about these Requirements or Click here to Jump to Step 3
- Business requirements
- Functional Requirements
- Quality Requirements
- Regulatory Requirements
Business Requirements
This describes the high-level goals of the project. The business requirements may be mentioned in the statement of work (SOW), business contract, Product Requirements Document (PRD), project brief or charter.
Functional Requirements
Functional requirements describe the features or functions a product or project must meet to satisfy the business requirements, and they are defined by collaborating with the customer. For example, a customer can specify the features they want in a product, or a product manager can use user stories to describe the functions they want.
Quality Requirements
Most projects or products will have their quality expectations defined in some business process document such as a specification sheet, product dossier or quality requirements document. Where quality requirements are not explicit, always engage the relevant stakeholders in defining the requirements of the product.
Here are some quality aspects.
- Performance
- Reliability
- Conformance
- Aesthetics
- Serviceability
- Perceived quality
- Consistency, Responsiveness
- Efficiency
As a project manager, you would not have to develop these quality requirements because most will be contained in a business process document and would be the basis of the user acceptance test checklist. Acceptance criteria are those conditions that must be met for a task or project to be considered satisfactory.
Regulatory Requirements
These are requirements defined and administered by government agencies. They are developed to protect the public and have the backing of specific government laws or legislation. For example, if you are running a clinical trial project, you’d need certain regulatory approvals before initiating the trial.
Step 3: Develop a Work Break Down Structure
Work breakdown structure is a representation of a decomposed project. It shows how a project is broken down into tasks and milestones based on the project objectives and scope. The main question to be answered is, “What work needs to be done to deliver each deliverable?” Answering this question requires expert judgment and often collaboration with other stakeholders. WBS decomposes large projects into manageable components (called work packages) that can easily be tracked for progress. A phase-based work breakdown structure deconstructs work based on each step or phase outlined in the process flow.
For example, making a batch of cookies will have three key steps or phases.
- Step 1: Gather the ingredients
- Step 2: Mix ingredients
- Step 3: Bake cookies
Hence work will be broken down at each phase.
Step 1: Gather ingredients. Work can be broken down as follows:
- Make a list of ingredients and measurements required (Work package 1)
- Purchase ingredients (Work package 2)
The WBS also breaks down the work according to the order in which it is to be completed.
Step 4: Assign Resources
Resource allocation is another key component of your project plan. The main objective is to confirm resource availability for a project, factoring people’s workload on other projects and their vacation schedule. If you are a functional manager (meaning you deliver projects within a business unit and have direct supervision over the unit’s resources) you will have visibility into the current workload of your team members. If you are not one, you must work with functional managers for resource allocation. Project managers need to build trust and rapport across different teams. Here are some basic but highly effective tips for building relationships with functional managers.
- Model good leadership qualities within your project team: accountability, reliability, integrity, gratitude, and communication. When people enjoy working with you, they tell their functional managers.
- Get their buy-in early on projects: For example, when you are assessing the viability of a product development project, functional managers are one of your key stakeholders because they have subject matter expertise.
- Be willing to negotiate amicably with functional managers. Most functional managers will have other operational priorities besides delivering projects. So collaborate to align work priorities for your mutual benefits.
Step 5: Develop a Budget
All projects will require some level of human resource allocation. However, you might not always be involved in managing a project’s financial budget. If budget estimation is required as you develop the project plan, you can apply the cost aggregation technique. This involves summing up the cost of all the activities and work packages needed to execute a deliverable. This covers both the human and material resources required.
Bottom-up estimation is a cost aggregation technique (costing from the bottom of the WBS) and can sometimes be a rigorous task depending on the project’s complexity. Budgeting requires that you consult subject matter experts and combine their feedback with any available analogous data (for example, the actual cost of completing a previous similar project).
Here are some tips and best practices for creating a budget for your project
- Prepare a contingency fund. Add some buffers to your cost estimation to account for risks and unforeseen circumstances.
- Consider economic factors. Understand the impact of environmental factors like currency devaluations interest rates, and labour cost changes.
- Be mindful of scope creep. Being clear on the scope and requirements of a project is important for adhering to the project’s budget. There’s a relationship between cost, time and scope in project management called the Triple Constraint model. You can’t change one variable without affecting others. So, if the scope increases, the budget and timeline should increase likewise.
Step 6: Develop a Project Schedule
In traditional project management, work is completed according to a pre-defined sequence. So, to create a project schedule you must understand the sequence of activities. You can refer to the standard operating procedure or flow chart that contains this information, or you can schedule some meetings with the project team to understand the sequence. Secondly, identify any dependencies between activities. Dependencies can highlight potential bottlenecks or delays in your project and help when estimating the duration of each activity. Next, you need to estimate the duration of each activity using a combination of techniques.
If you are a technical project manager, you could estimate based on your technical expertise and familiarity with the project. Otherwise, you can seek help from the experts on your project team. Your estimates can also be based on the duration of tasks in similar completed projects. This is called analogous estimation. In practical settings, using the 3-point estimation might not be necessary but it’s a worthy mention notwithstanding. Lastly, to develop your schedule, you’ll assign timelines and due dates based on your work calendars.
In practice, project planning goes beyond developing a project plan. You might need to develop plans around other aspects of the project based on the prevailing situation. These aspects include:
- Risk Management
- Stakeholder Management
- Communication Management.
- Quality Management
- Procurement management
Read More: Asana Play Book For Small Businesses
