How to create a good project plan?

Many people associate a project plan with a project schedule (Gantt chart) that defines the project tasks, assigns responsibility for their execution, specifies start and end dates, and links between the tasks. However, such an association is only partially justified, as a good project plan is a much broader concept.

Before we look at how to prepare a project plan and what it should consist of, let us consider why the project plan is needed and why it is so important. One of the best methodologies for managing projects, Prince 2, states that each project must have at least two logical phases – the planning phase and the execution phase. In short, the execution phase cannot be managed effectively unless you have a reference point, that is the plan.

What is a project plan?

The plan is important because, before you start spending money on the project, you need to think about what you want to do. The deeper you are in the planning process, the more new information and details come up that, if included in the plan, will contribute to the future success of the project. The plan helps to better coordinate and share the work among the project team members. The plan allows for better communication with the project stakeholders. Finally, the plan allows you to determine whether you will be able to finish the project on time and whether you will complete it within its budget, which means that you can manage the project execution phase well.

Many project managers prefer to take action and feel “the wind in their hair” rather than spend hours and days on tedious planning – in project management, it is a false sense of working wisely. A weak plan causes a number of problems of different types during the project execution – if your plan is weak, you can be 100% sure that such problems will occur.

The elements of and approach to developing a good project plan

A FRAMEWORK DEFINITION OF THE PROJECT

You should first define the framework objectives (scheme) of the project:

  • project outcome/product – specify what you want to achieve as a result of the project, define its final product, milestones, and scope. When defining the scope of the project, it is also worth saying what is not included in this scope;
  • the business case of the project – here, you should consider what problems or opportunities for the organisation the project is to address. What the estimated and expected business outcomes of the project are. It is not enough to know exactly what you want to do. It is equally important, if not most important, to know exactly what you want to do,
  • identify what strategic objectives the project will support;
  • specify the framework budget of the project – it is worth considering what is the budget range;
  • define the main project risks;
  • define the main phases of the project;
  • identify the resources and competencies required to complete the project.

Thus defined frameworks of the project are most often compiled in a document called the Project Charter. The Project Charter allows the project sponsor to decide when to start the project planning phase.

DEFINING THE PROJECT PRODUCTS

A good definition and description of the final project product or products and the partial products required to achieve the final result are some of the most important actions to be taken when creating the project plan. It is a good idea to develop the Product Breakdown Structure (PBS) and then the Product Flow Diagram (PFD). The PBS allows the final products to be decomposed into suitable sub-products, while the PFD enables the development of the time sequence for their creation. Each product should be described as precisely as possible so that there is little space for ambiguity among the project team.

A good definition and description of project products are extremely important because they involve planning tasks, the budget, resources and risks. If there are a lot of inadequacies in the product descriptions, they will be characterised by a lack of precision. This lack of precision will be reflected in the schedule, budget and resource plan. It is so because one of the most preferred methods for planning the schedule, resources, and budget is the Product Based Planning methodology.

PRODUCT BASED PLANNING, CREATING THE PROJECT SCHEDULE

With the well-described project products and scope, you know what you want to do. The time has come to determine how you want to do this. We recommend starting the schedule by building the Work Breakdown Structure (WBS), which is a well-structured list of tasks to be performed to develop the defined project products. It is worth including the project milestones in this list. Only when you make sure that you have a good list of all the tasks and that it is complete, you should proceed with defining the responsibility for their execution, specifying the start and end dates for each task and building the interdependencies between the tasks. In this way, you will build the so-called Gantt chart of the project.

DEVELOPMENT OF THE PROJECT BUDGET

When looking at each of the tasks on the Gantt chart, you should consider the expenses you have to spend on the project. In this way, you are going to compile all the necessary budget items and estimate the amounts (there are several methods for estimating amounts, but their description goes beyond the scope of this article). Sometimes, it is sufficient to provide the total amounts for each budget item, and sometimes companies need to break them down into the subsequent months of the project.

DEVELOPING THE RESOURCE PLAN

In the Gantt schedule, you have assigned responsibility for the execution of the tasks, which means that, to some extent, you have listed human resources needed to complete the project. This list should be complemented by all project team members and then, for each individual, the degree of involvement in the project. The degree of involvement in the project can be defined in %/days/hours – all depending on the needs and methodology used. When analysing the resource plan, it is worth asking yourself if the dedicated resources are sufficient and have the appropriate competencies to carry out the project well. Experience says that often this is not the case. If the project requires resources other than human resources, you should plan them in the same way as human resources.

DEVELOPING THE RISKS PLAN

At this stage, it is worth identifying all the project risks, determining the likelihood of their occurrence and the potential impact on the project, and assigning responsibility for monitoring them.

DEVELOPING THE COMMUNICATION PLAN

The communication plan requires the definition of all relevant project stakeholders, the identification of their information needs and the subsequent development of an action plan to address these needs.

All of the above elements together form a project plan. The plan should be approved by the project sponsor before starting the execution phase.

How can an IT system support the creation of a good project plan?

Many companies plan projects using solutions developed in MS Excel. It is possible; Excel allows you to create a relatively good project plan which contains all of its elements. 

However, there are many programmes on the market that are specifically developed for this purpose, such as, for example, FlexiProject software for project management, which supports project planning and contains all the functions needed to create a project plan: 

  • a comprehensive, ready-made Project Charter, 
  • the software is designed to split the project into any number of phases, which means that it is easy to separate the planning phase from the execution phase, 
  • once the project sponsor has approved the plan in the system, you can save the project plan and use it to track the execution
  • advanced project assets and risks management modules – FlexiProject enables you to plan and then track the project execution, 
  • the embedded “Plan Change Request” document, which is completed by the project manager if there are reasonable circumstances to change the project plan. Project changes must pass the path of approval defined in the system, which means that they are fully controlled.