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.

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.

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.

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.

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!