Planning is science and art.
Whatever you call it, it is a challenging and complex process.
A plan should be feasible, challenging, realistic, usable, efficient and optimal.
It is difficult. I get it!
Below are the project planning concepts that will help you to deliver a plan that leads to project success.
Believe it or not, small and medium projects rely on proper planning more than large ones. So skipping or neglecting project planning usually leads to failure.
Project after the project I analyzed good and bad sides of my plans.
I found out that successful projects share similar traits and approaches in planning.
So, I formulated these traits into seven project planning concepts.
1. A plan is Not Only About Schedule
Quite often we understand a plan in a narrow meaning.
For example as a Gantt or a milestones chart or simply a sprint backlog only.
There might be some extra items on your list like scope or risk management plan.
But no more than that.
All the rest is taken as granted at best. Or you have never even thought about the real extent of planning.
I often see that agile methodologies develop the wrong attitude toward planning.
While providing a simplified workflow for planning the work, they imply that many functions already exist in your environment.
They omit a set of roles, processes, and activities that should already be present before you can work efficiently.
Nevertheless, you or someone before you had to prepare a plan in all knowledge areas.
For Scrum, you do it only once and then reuse it during each iteration. Some parts of the plan are constant and are embedded into your working environment. So you do not pay much attention to them.
Today you may work under Scrum or Kanban framework, and an environment is arranged for you. So this topic might seem irrelevant.
However, sooner or later you will get into a project where you will have to set it all up from scratch, teach your team to work and build up a working environment.
PMBOK Guide describes ten knowledge areas that they recommend planning for. To the extent applicable to your project you need to have a sub-plan for each of them.
Therefore, your planning should cover:
Some of the areas required in-depth coverage for each project. Others require one-time effort and can be reused.
If you need a simplified plan check out this article:
2. Key Concept of Project Planning – Planning Fallacy
By default, we are terrible at planning.
And there is not much you can do about it.
It is the key conecept of project planning. Keep it always in mind!
Only by experiencing problems we can learn to anticipate adverse events in the future. If you are smart enough, you know the value of experience and mistakes of others. You add them up and apply to your work.
Planning, in essence, is an attempt to guess the future.
Which is, in fact, a waste of time.
Having too many dependencies and relations, unknown factors and unexpected events… There is no way you can take everything into consideration.
So you can only try to interpret uncertainties using your experience.
So, what does it mean?
In general, you have two conceptually different types of work you need to plan:
The work that you are mostly sure about. You know what, how, and who will do it. You also know how long it will take and what outcome you will receive. It is also good to be sure of the quality of the result.
The second type is the work with uncertainties.
At the given time you may not be sure of how or who can do the job.
Or you may not be sure about the outcome until it is partly done.
Or you can’t be certain about the overall quality due to the interdependencies and the nature of the work.
Professional project managers claim that to manage a project, you need to manage risks. And I agree with them.
A project work (the one that you are sure of) will be done as fast as it is possible until the tasks are feasible.
So once you have a plan, it is as good as the amount of unknown that impacts it. Therefore, the better you manage uncertainties, the closer you will be to your initial plan.
So you should focus planning on managing risks, dealing with unexpected, and clarifying uncertainties in a systematic and controlled way.
3. Planning is Everything, Plan is Nothing
Planning is not about getting a fixed path.
The biggest benefit of planning activities is not the plan itself but a mental simulation of your project.
During planning you imagine how a project will go, what can go wrong, how you will overcome problems, how you will manage changes, etc.
The more “If-Then” cases you will brainstorm and simulate the more problems you will identify. The more prepared you will be.
I really do it.
For example, I sit with a Gantt chart in front of me and try to imagine how the project will proceed day after day. I ask myself questions and attempt to answer them.
Then I imagine unexpected events like sick leaves, technological problems, new risks, etc.
I check if there are a “plan B” or reserves that can cover them.
I also think through possible communications that will be required in case of an emergency.
So what will be the most useful output? It is to be prepared for unexpected.
Secondly, plans should be flexible. They should not change every time something unexpected happens.
Requirements and priorities can change on a daily basis.
So your plan should include measures to handle the changes efficiently. Therefore, choosing the proper methodology (e.g. Scrum, Kanban, Waterfall) and processes is a vital part of project planning.
On the other hand, you need to keep track of your “flexibility” resource.
Whether you apply project risk management and include reserves or you have undefined buffers or just slack in the schedule.
In any case, you need to measure whether your reserves go to the planned risks. Or do you burn your buffer at the expected rate? Or does your burn-down chart go smoothly?
You need a reliable way to forecast how flexible your plan will be in the future.
4. Planning is Iterative
It is a key project planning concept. You can not and should not try to create a project plan in one approach.
The process is simple. When you find a new piece of information about the project – integrate it.
Now go back to the start of the planning process. It might be as far back as reviewing the Project Charter!
Fast Forward through the process and ensure that your input did not invalidate your plan.
For example, you discovered a new big piece of work:
You might just include it into the schedule of your project and carry on. However, it may result in unexpected problems.
First of all, you need to ensure that this work is aligned with the business need. Then, there might be additional quality assurance measures. Moreover, it may introduce new risks, dependencies or even uncover hidden requirements.
The first natural point where you usually start iterating is right after risk management processes. You can learn more about the Risk Management Framework in the following article:
So whenever, you find a new input to your project you need to integrate it into all knowledge areas.
5. Making Promises
This project planning concept might seem controversial.
If you created a project plan and customer signed it off, you made a promise.
I believe that it is a part of professional ethics to keep to your promises. So now you need to deliver the project results on time and within constraints.
The only valid way to correct the plan is by formal change requests:
It usually comes naturally when a customer or a sponsor asks for a change. But what if you need to make a change due to your mistake. Or due to a change request from an internal stakeholder.
For example, something was missed during scope definition. Which was, again, your fault.
You can not break your promises.
However, you can renegotiate the terms of your promise. And you must do it as early as possible. You should never delay or hide problems. Even if it means a hit on your reputation.
But hear this:
More often then not stakeholders will be open to such negotiations. Especially if you come with a contingency plan to fix the problem early on.
They may even help you to overcome the issue or find the best alternative. It might not even be a problem yet. In the long run, they should all be interested in a successful outcome of the project.
If key stakeholders are not interested in project success, it is better for you to quit the project (organization) as fast as possible.
However, keep in mind that from time to time someone may make a promise based on your promise.
A lot of money and resources may be put to work. Though, there still might be a place for renegotiation. In any case, you must ensure you are aware of such commitments beforehand.
6. Do Not Plan Alone
Engaging your team in planning activities has a set of benefits.
First of all, you can delegate part of your work to the team.
If the team is appropriate to the project at hand, they will do some planning activities far better than you.
Therefore, you will get a deeper analysis and input from different perspectives.
If you delegate the activities correctly, you will also gain the team’s buy-in, it will be a great team building effort, and most importantly team member will feel ownership and responsibility for the project.
If you are in doubt whether it is worth the effort, breakdown and analyze the Scrum framework.
It is built around this concept of delegating planning and responsibility for commitment to the team. And Scrum works. Learn more about Scrum here:
7. Project Management Concepts for Small Teams
There is no clear line when a team becomes large enough to have a comprehensive planning in all knowledge areas.
However, I believe, that small teams can be managed in a more efficient way by applying project management concepts for smaller teams.
I will not cover this topic now, but I want you to keep close at hand the manifesto for small teams doing important work created by Seth Godin.
Read about leading small teams here:
Following these project planning concepts is not easy.
It all takes precious time and resources. Moreover, stakeholders may not see the benefits because you try to avoid problems in the future.
What’s the point then?
For me, the most practical result is that projects became more predictable than before.
Unexpected problems are mostly disappeared because there is always a defined way to handle them. Even without my personal participation.
Liked the article? Please share it on LinkedIn with your network. Click the share button below.