11 Steps To A Good Project Plan

Summary of the webinar "How to make a good project plan". To listen to the whole event, as well as the questions from the audience, follow the link.

1. Communicate openly

Be open in your communication, both with the team and with customers and suppliers.

Even if you are pressured by different circumstances, submitting the wrong information creates difficulties in managing the project afterwards. If we start with missing information or do not share everything we know, we have to be very careful with what we say and how things really are.

Do research.

This is extremely necessary if we are subcontracting a project to a client. It is very useful to get to know the client - what is their way of working, what methodologies are we expected to work with; if we can consult colleagues who have worked with the same client and "step on" their lessons learned and good practices.

2. Build a summary plan

Our goal is to see the basic steps without going into a high level of detail at the very beginning.

No matter how hard we try to plan a complete project from end to end, it subsequently undergoes changes. The concepts in the flexible methodologies also come to the rescue here.

3. Identify the risks

To make a detailed plan for a given stage of the project, we need detailed information about it. In agile projects detailed planning is done up to 2-3 weeks ahead, and in traditional methodologies even more.

For more remote periods, for which we do not have detailed information, it is good to set buffers – mostly regarding time and budget, to have enough time for re-analysis, evaluation and to adapt our current plan, if necessary.

4. Break the plan into smaller pieces

In agile methodologies, the product backlog and sprint backlog are good examples of such a breakdown. In traditional methodologies, this role is performed by the individual phases in which we intend to develop the project.

In the shorter phases, we have a much better chance of accurate planning. Well-crafted tasks will help the team to better imagine what it has to accomplish in each phase.

Tasks must be broken down in intervals that range between 1 and 10 working days. The brain has the ability to retain information for a period of 2 weeks without the risk of losing it, so therefore we will reduce the risk of an important detail being forgotten.

During these periods, it is advisable to monitor the project metrics - man-days or man-hours invested in the project. Other metrics may be included in the projects, but in the most common case these are the costs in relation to the daily rate of each member of the team.

At shorter time intervals, it is easier to plan the costs of non-project activities - such as reporting, invoicing, deliveries - prerequisites that are necessary to implement the project.

5. Don't guess, but ask questions

It is always better to ask specific questions, even if they seem inappropriate, because this will help us avoid problematic situations in the future. The more affected the parties, the more communication there needs to be.

If we still have to make assumptions, it is necessary to communicate with colleagues or stakeholders, as well as to describe them in the documentation. This will avoid the possibility of putting the other party in front of an established fact and provide time for a response if needed.

6. What questions to ask and why

Among the most important questions are "Why?" and "How?".

We first start asking questions inside the organization to make sure we know clearly enough what we want.

The role of business analysis intervenes here. If there is no good business analysis, there are many more risks in the project. The business analyst knows how to ask the right questions to the right people and how to document their answers in the right way.

If we are a client organization and we are looking for a subcontractor, these questions will give us confidence that we will get the service or product we expect.

If we are a supplier, the right questions will help us not to set traps. When giving an assessment, we need to be able to defend it. We need to know what questions the client would ask us and to have prepared answers for that. In this regard, we could do training negotiations within the team, trying to put ourselves in the place of the other party, asking the awkward questions that we may get in the real negotiations.

It is important to be able to deliver according to our real capabilities and to be able to defend our response in order for the negotiations to be successful.

7. Evaluate and plan for change

Every project undergoes changes, regardless of its duration and complexity. We need to have the time and budget to adapt to these changes.

The more changes a project undergoes, the more expensive it usually becomes. It is important to know who is paying for the changes. It is advisable to communicate this issue with the client in advance. It is also important to keep in mind the 'hidden' costs, which are most often costs to third parties.

Assumptions are a risk, so it is important to document them and make the team and client aware of them.

8. Manage change

Once we know that there will be changes, we need to anticipate how to deal with them. This process continues throughout the life of the project.

A plan is drawn up for each risk, if it is implemented (the so-called plan B) - we can eliminate the risk completely, reduce its impact, transfer it to a third party or use other techniques.

For the biggest risks we compile an additional action plan.

9. Defining endpoints in the plan (milestones)

There should be points in each plan to check if we are moving relative to the original plan. The endpoints are defined at the very beginning when the phases are broken down.

This documentation must also be transparent and clear so that we can correctly assess how to continue the project in the event of a forthcoming change.

10. Final phase

The project also determines the final phase with the activities for closing the project. It is important to plan what we need to do to say that the project is completed - final tests, approval, handover protocols and more.

11. Review and optimization

After the handover of the project, it does not really end. After its delivery, there is often a stage of warranty support and optimization.

Retrospective meetings, which are held at the end of each sprint, are also held at the end of the project. This flashback will help us plan our future projects more successfully.