How to Build a Project Plan?

What do you need to build a successful Project Plan?

1. What information do you need to start?

2. How to choose the right approach?

3. How to build a Project Plan?

4. How to validate the Plan?

What information do you need to start?

Before preparing your Project Plan, the Project Charter was created (see the blog “the 5 key steps to start a Project”).

With that information, you know some key information such as:

1. The Project Goal

2. Scope

3. Product Go Live and other key dates

4. Assumptions and Risks

5. Required stakeholders and end-users

 Based on this the project has some reference points to guide the next steps.

Collecting key information — Timelines and Staffing Plan

Before you start the plan, it is best if you can get a bit more detail on the most important aspects of the detail planning:

1. Key Actions and Dates — to allow you to confirm your critical path of actions need, such as when the project is due, when users can test, etc.

2. Key Staff — it helps to document the estimated number of staff hours and roles available upfront. This sets expectations about effort available in any phase and time period. Knowing this and the expected time for the work to complete can give a reasonable sense of how long each phase will last.

Actions and Dates

Before you start detailing the project plan, note the big picture with key actions and dates. This way, you can test the reasonableness. Confirm you are covering the critical success factors in this planning as this will inform your project plan.

Roles & Staffing Plan

After the Charter is complete and agreed, draft a list of the expected project Roles and Staff to allow you to start preparing the detailed Plan.

Summarize the key roles by type. Add all staffing including Steering Committee and Stakeholders if there time will be accounted for and cost allocations expected.

Why a step between the Charter and the Project Plan? 

Making a detailed plan can be overwhelming. Starting with the overview of timing, milestones, and staffing will save you effort and avoid significant rework when building a ''plan from scratch'' in MS Project or other tools.

With these 3 documents: Project Charter, Timeline, and Staff plan, you are now ready to create a project plan. This process will likely lead to iterative reviews, but that is part of the process for many Project Managers.

Note: if you plan to use Agile processes, the above points will still impact initial planning for the sprints since this collection of data normally starts before scrum sprints begins.

Keeping these documents as part of the Project Book, as discussed in the "5 key steps to building a Project," will help to ensure you have a place to start while keeping the ''big picture in mind.''

Choosing the right Plan Approach 

Projects can be managed in several different ways depending on the type of project and personal preference. Project methods differ in the type of project fit and approach benefits, drawbacks, and uses. We will review these at a high level now. Later we will discuss these processes in more detail.

Workflow or Waterfall

This traditional approach uses a discrete start and stop points that flow into the next step. Each phase ends in a milestone and requires review and, often approval.

Make the level of detail fit the project needs. Most plans need: phase, task, timing, staff, and status.

There are many tools used for workflow approaches, from excel to MS Project, there are now on line tools, such as Clickup, TeamGantt, and GanttPro.

Many projects actually have more of a fluid approach to this method, and phases can overlap.

Phase Options

The phase categories used for each project can be based on the project goal or work planned:

• Simple project: (Start, Plan, Do, Review, Complete)

• Digital project: (Requirements, Design, Build, Test, Assess)

• Project Management Institute PMBoK: (Plan, Initiate, Execute, Monitor, Close)

A simplified example of an excel Workflow project. Note that structures can be flexible based on your needs, but all need timing, task, and owner; phase, milestone, hour estimate and sign off may or may not be applicable to your requirements.

Agile

Agile or Scrum process are used when speed and high user acceptance. A Scrum Sprint is normally 1 or 2 weeks in duration. This is an iterative approach which focuses on all of the key project steps in every Scrum.

Scrum Sprint Planning

A fluid way to conceptualize tasks toward a goal. Visual work processes make managing a team easier and work assignments natural to team skills and availability. A good project approach where speed and flexibility are important.

Agile/Scrum can apply to the entire project, or just a part of one planned using another approach. When this is done it can be considered a hybrid project approach.

Some projects are workflow-based with build sections in Scrum sprints. The Agile approach still needs a project charter and Project Book. However, day to day activities are run from the Scrum board.

Scrum tools can be based on a “white board” and post-it notes or an online tool such as Trello.

An Agile/Scrum team process and role overview

What makes Agile different? The Roles, timing, and focus on rapid feedback from users. Work is scheduled based on the available team and effort estimates, and is designed, built and tested during a Scrum, instead of in phases (as in workflow). At the end of the Agile scrum period, the team reviews the backlog and new input from Users testing. A new scrum board of work is created for the next period. The process is started again.

Agile subprocesses can be used together with larger waterfall projects to allow for some agility and flexibility where beneficial while still allowing for the larger project to meet stricter guidelines and oversight.

Which to Choose - The Agile/Waterfall dilemma

Ultimately, it is the projects needs, the requirements of the Project Owner or Stakeholders, and corporate requirements determine the right approach. And, as mentioned, most projects use some form of a hybrid. This allows for oversight for qualitative processes, and fast, flexible sprints for build work and other actives where agile scrum cycles fit best.

How to build a Plan?

You have your baseline documents. Charter, Key Dates, and draft Staffing Plan.

Now it is time to build the plan. Below is a simple step-by-step high level plan on a page.

Build the Goal into the Plan

The Project Plan is the tool to navigate the details. So make sure the Goal is aligned throughout the Plan.

The framework of the Plan should reflect the:

• Project Goal

• Scope

• Outcome

Breakdown the work Tasks

This is to the core of the project plan or Work Breakdown Structure (WBS) be sure to document tasks:

• By milestone

• Dependencies (the task order and relationship)

• Quality review (do it, then check it is done correctly)

Estimate time and effort

Timing is more than a date, you also need to estimate the amount of effort needed for each step. Define:

• When the work needs to be done

• When materials are available

• How time is documented (hour, days, effort, elapsed time)

• Note project ‘blackout periods’ such as holidays

Create the Staffing Plan

As noted above, document Staff details including:

• skillset

• availability

• role assignment

• cost (if needed)

Also consider the staff framework and behavior (see more on the link to this blog)

Assess the Risks

Every plan has risks and assumptions. Consider options in advance to counter your potential problem (see more on the link to this blog ). Document the key facts:

• Risk type

• Likelihood the risk will happen

• Options (and put them in place in advance)

How to validate a Plan?

Regularly review and update the plan as new information is available or as work is done.

1. Review the plan with team members and stakeholders for completeness and to keep the plan realistic. Once reviewed, formally document the plan as “approved”.

2. Adjust the plan based on work done and new information (such as staffing changes). Once you have history of work with the existing staff you will be able to improve your initial estimates.

3. Save plan versions to allow for comparison as changes are made. This can help when reviewing overruns and looking for deltas in costs.

4. Stay consistent with how and when you update the plan to avoid confusion for the team.

5. Keep version control of all records as you update them. When the project plan changes, budgets, staffing, risks, assumptions and more may also change. Update all of the documents together to keep everything synchronized. See more on this and get the free example of these documents in the Project Managers Toolkit.

How do you start your project planning process? Do you have a preferred approach? Let me know in the comments. Thanks!