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.

Waterfall or Workflow — so named because the main steps have a discrete start and stop points that flow into the next step. The Requirements step or phase is a precursor to the Design phase. You may think this only works in theory, but it often also works in practice, too. Primarily steps are discrete when milestones are reviewed, or approval is needed at the end of each phase.

However, many projects actually have more of a fluid approach to this method, and phases can overlap. This has long been the industry standard and is most often used in complex construction or regulatory processes requiring high quality, inspection, and documentation levels. The duration of projects using this method may be from 1 month to several years.

The exact types of main 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 — This method also includes the Scrum process, which originated from technology development (app building and similar work). These projects require speed and high user acceptance. We will discuss this more in future blogs, but if your end-product depends on user adoption, then this approach may be right for your project. 

The concept is to work in fast-paced stages similar to a waterfall (analyze, define, design, test), but with speed, a cycle in normally 1 or 2 weeks in duration; however, from start to complete a full project may be 1 to 6 months.

What makes Agile different? The Roles, timing, and focus on rapid feedback from users. Also, the roles of the Scrum team are different. Some of the ways of working specific to Agile: 

• A Scrum Master to track the tasks and team

• Standing meetings to evaluate work status quickly; this is important since this approach is about speed.

• A Process Owner to make decisions on behalf of the end-users

• Work is taken from the Scrum board by team members as they become available.

• As work moves across the board, all team members can see the status,

• Work items not done during the current scrum move to a backlog.

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.

An example of a Scrum board using the Agile method may look like this.

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.

Alternatives approaches

Some Project Managers prefer alternatives to these predominant approaches which may fix the projects needs better as they are simpler and more visual.

Action Planning — focuses on the related tasks to an outcome. This is best used in small projects where the final work or outcome is known in advance. 

Mind Map — an approach often used for brainstorming, linking like items, or managing tasks. This approach has been used for projects since many learn this method and related technology tools. 

Once the approach is selected, review the tool provided by the organization or order your tool. Take time to learn the tool's functionality before you start to make optimum use of your time and the tool's capabilities. The simplest tool for the job is generally 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!