How to Plan a Project? Try 2-Step Planning with Kanban

I’ve been dealing with Kanban for the past 10 years. In the beginning, it was just my work passion, then it turned out to be my company and to some extent, my life.

There’s a bit of irony in this, however. Throughout this decade of learning and experimentation, I never found a project planning model that worked for me. You’d think that something so fundamental, such as planning, should be one of the first things to figure out but it wasn’t.

We’ve had some ideas for good planning, but they worked for specific contexts that allowed the team and the managers to control what and when should be done. For contexts where planning had to be agreed upon with the customer and where sensitivity towards time was generally higher, Kanban had no definitive answer. At least not one that’s easy to apply in practice, not just in theory.

Now, ten years later, I think we’ve figured it out. Finally!

Actually, none of the concepts involved in this new way of planning projects is new. We’ve seen it all. Yet, I do believe that the way we’re proposing to approach planning in Kanban is quite different from anything you’ve done before.

Let's make one thing clear before we continue. This way of planning has been tested and proven to work in a knowledge work context. It may fail miserably if you’re attempting it in other contexts, so please use it at your own discretion.

Project Initiatives vs. Tasks

Before we dig into the details, let’s introduce a few terms.

Task: This is a work item represented by a Kanban card on a team board. This could be anything that the teams are working on (user story, content piece, design drawing, prototype, legal document, etc.)

Project Initiative: An initiative is a collection of tasks that have to be completed in order to achieve a certain goal or produce a deliverable. Think of initiatives as the building blocks of a project. I.e. a project consists of multiple initiatives.

The first substantial difference between traditional project planning and the planning proposed in this article is the level at which you care about start and end dates. While in traditional project planning, managers plan on the task level, with Kanban planning, we plan on the Initiative level.

Let's dig a bit further into this as it’s a very intuitive approach to our everyday life, but we rarely employ it in business. Imagine that you're finishing work, and then you have to go to the grocery store, pick up your child from ballet, and go home to prepare dinner.

How would you plan for this if you had to go into the details? 

I bet it’s going to be something like this:

I’m yet to see somebody who plans the same set of activities like that:

… and so on, you get it, right?

If we dissect these two planning methods, the first one resembles planning on the initiatives level, and the second one resembles planning on the individual task level. Despite the fact that the second approach is much less intuitive and, in fact, much less accurate, that’s what we typically see in project planning. 

We are asked to estimate every single item and then overlay the items on a big, fat Gantt chart that’s supposed to show us when things are going to end. This rarely works well in a knowledge work context, and here’s why.

Planning Initiatives Is Easier While Providing Almost the Same Value

The value of planning is to allow us to make decisions. First, we create a plan so that we know if we should take the project or not. Then we plan in order to schedule the completion of work and be able to steer in one way or another.

Let’s say it’s 6:23 already, and you’re just entering the store. Do you need to have a detailed plan in order to know that you’re getting late? No, you need a good enough plan. Alternatively, if you’re on time, is it because of your detailed plan? Probably not. Chances are that you had a good enough plan that allowed you to step on the gas or take it easy during the trip.  

The point here is to put as little effort into planning all the details unless absolutely necessary. We should operate on the initiative level and only go to the task level when there’s a deviation from the high-level plan. The high-level plan will bring some 80% of the value, and you’d rarely need the other 20%.

Think of driving in a foreign country with your GPS on. If you’re going in the right direction, you won’t bother to look at the GPS all the time. But if your gas is running out, you’ll dig into the detailed map and look for a gas station. However, for the most part, you don’t really care if you’re going through village X or village Y, right?

Planning Initiatives Is More Flexible

This one should be obvious. If you plan in great detail, then you have no option to change tasks on the spot whenever it makes sense. 

Imagine you planned first to buy cheese, then get the bread, and then the vegetables. But what if the grocery store shifted the products around, and now the vegetables are closer to the cheese than the bread? Would you still get the bread first and then go back to pick the vegetables? Of course not. So, why plan in such detail and risk being wrong most of the time when you have a team of clever people who can think and make this type of decision on the spot? 

Planning Initiatives Lets Your People Take the Initiative

The role of the manager is to create capable teams and then provide them with the right goals. When the team is aware of the goals and has the necessary support (knowledge, tools, etc.), they will get the job done without the need for micro-instructions. 

Self-organization is by far the superior organization of knowledge work teams as it allows the people closest to the problems to actually solve them, which is the most effective and efficient way to deal with issues.

Even the fathers of Lean at Toyota say that they don’t want to use a lot of Poka Yoke measures, as they want the workers to think. If the factory workers at Toyota, who work primarily with their hands, are expected to think, then what about knowledge workers who work with their heads?

The point is that a high-level plan allows you to harvest the true potential of your teams. Just do the goal setting and trust them to do the best job. You will certainly have the means to track progress, just bear with the article for a little longer.

How to Create a Project Plan that Actually Works?

Okay, this was quite some reading just to get to the juicy part. Sorry, but we had to introduce some of the core thinking in order to deal with the actual planning process.

2 Simple Project Planning Steps

You can apply this planning model to any sort of knowledge work, but let’s plan a project in order to illustrate the approach. Our project is going to be a very trivial thing - the new website of a company.

Step 1. Developing a Project Plan with Timelines

At Businessmap, we believe in the timeline as a planning tool. High-level roadmaps are one of the most useful and widespread visualizations of what our future work is going to be. Some may think it’s just another representation of the Gantt chart, which is clearly not effective in Knowledge work contexts, but there’s absolutely nothing wrong with timelines when used on the Initiatives level. 

If you think about it, timelines are simply WIP-limited Gantt charts. If you are not familiar with this, Work in Progress (WIP) is a Kanban term that means how much-started work we have at a particular moment in time. Actually, one of the most effective practices of Kanban is limiting the WIP in a system, and the timelines help us do it on the Initiatives level.

Now, back to our website project. Let’s create a high-level plan that describes the main deliverables that have to be worked on.

The plan suggests that we need to do a short discovery phase, then prepare a spec, finalize the front page design, and do the actual work. Right now, you might be thinking, "Gosh, why the Waterfall planning for a website?" and I'm with you. This is, indeed, a waterfall type of planning, which we all know doesn't work for complex knowledge work projects. However, you will be amazed by the number of websites that are still being built using the "good old" methods. So, with this example, we're trying to make things just a little better while realizing this plan is far from perfect.

The important question here is how you come up with the duration of each of the initiatives. Our answer at this moment is to base your assessment on past experience and not dive too deep into the estimation. At this stage, it’s more valuable to merely state what needs to be done and not that much when it’s going to be done. All we need is the scope with some rough start and end dates. When ready, we can move on to the next step.

Step 2. Breaking Down Timeline Project Initiatives into Tasks

When all the major deliverables (initiatives or projects) are in place, it’s time to break them down into actual tasks on the board. When you’re finished, the board will look something like this:

Note that we have the first two initiatives broken down into child tasks that live right below the Timeline into what we call the tasks workflow. The image does not show all of the tasks for all of the initiatives just for simplicity. In reality, all the initiatives should be broken down.

As the image shows, none of the children's cards have been started yet. Some of them are in the Backlog, which means they are not ready to be started yet. Others are in the Requested area, which is the equivalent of committed work, which the team should start working on as soon as capacity is available.

This two-tiered approach to planning is the second major difference between traditional project planning and the proposed Kanban planning. When the notion of time plays only on the initiative level and does not affect the day-to-day tasks, we are free to apply the principles and practices of Kanban, which gives us a significant productivity boost, often reaching 200-300%.

This doesn’t mean that we do not care about time on the task level. On the contrary - we need to measure Cycle Time. This data point shows us how much time each task took to go all the way to Done. When we apply the principles of Kanban, we ensure that our cycle times are the shortest possible, which in turn speeds up the entire project.

If we track the cycle times of all tasks on the board and maintain them stable enough, we open up the gate for a whole new universe in the project management space. Let’s see what this bold statement is all about in the next section.

The New Paradigm in Project Management

What if someone told you that doing the things described in the article so far would give you superpowers to predict the future? Yes, Kanban can do this for you.

If your bottom part of the board (the tasks workflow) is operated by a stable team, it’s safe to assume that you’ll have collected some historical cycle time data. In other words, the system will know how much time it usually takes for work of type X to be completed.

With that information in place and a bit of magic, the system can evaluate your high-level plan and give you instant feedback about the expected duration of each initiative. This forecast won’t be 100% accurate, as it’s a forecast and that’s encoded in the meaning of the word, but it will be more accurate than most human beings. These predictions are based on proven mathematical and statistical models (Monte Carlo simulations), which is a testament to the correctness of the output result.

Now let’s pause for a second and reflect on this new paradigm. We just showed you how you can plan an entire project without spending a single minute estimating the actual work. All you had to do was define the high-level initiatives and break them down into the corresponding tasks. 

Then, assuming that your team has completed at least 30 similar tasks in the past, the system gives you a forecast about the duration of each initiative and, therefore, the duration of the entire project. How cool is that? It’s pretty cool, but that’s not all.

Keeping It All Up to Date

Once you go past the initial planning process, you may want to keep the plan in perfect synchronization with the work of the team. Typically, this is a tedious job, but if you’re a Kanbanize by Businessmap user you don’t have to worry, as the tool will do it for you automatically.

As soon as the first child task of a given initiative is started, the timeline will be updated automatically to reflect the actual start of the initiative. The end date will also be adjusted automatically based on the completion date of the last child task.

Not only that, but the forecast gets re-calculated on each task move. You start a task - and the system re-evaluates the plan. You finish a task, the system re-evaluates the plan. You do whatever - the system re-evaluates the plan. This is what we call “Continuous Forecasting” and what we believe is the future of Project Management.

Just let that sink in. You, as a project manager, just save yourself all the hassle of:

• Interrupting the team and asking for estimations
• Evaluating whether the estimations of the different teams correlate
• Updating the plan every day/week to make sure it reflects the reality
• Not having the real status of things (status reports are always inaccurate)
• Not having the real answer “What things are going to get done?”.
• Missing the right moment to act on a risk that’s about to materialize

All this is a fundamental difference in how we manage projects, portfolios, and even strategies. We will talk about this in follow-up articles. All we have to do now is address some of the concerns that people have when presented with these ideas.

A Few Words About the Skeptics

There are several objections to this approach that we hear often: 

• This won’t work as task size is always different!
• What if my team is changing?
• What if my project does not look like anything I’ve done before?
• What if I have no historical data?

This Won’t Work as Task Size Is Always Different!

While this is a valid concern, it’s technically not true. Monte Carlo simulations work with any sort of sizes, as they do the forecasting based on your throughput (how much work you produce for a given period of time). So, if your tasks are bigger, the throughput will be lower. If the tasks are smaller, the throughput will be higher.

What will decrease the accuracy of the forecast is task sizes that vary too much. For example, if one task takes an hour and another takes three months, the forecasts will most likely be off. However, if most of the tasks take between 1-5 days and then you have some outliers (you will have them) this stuff will work. The real benefit is that you don’t have to care whether it’s going to be 1 day, 2 days or 3.5 days. All you need to ensure that most tasks take 5 days or less.

What if My Team Is Changing?

This one is a perfectly valid concern and this method has no answer yet. What would be possible in the future is to run different “what if” simulations, but this is a very sophisticated planning technique and tooling support is not there yet.

Your best bet here is to do whatever you can, which probably means manual re-estimation, accumulate some historical data under the new conditions and then resume using the Continuous Forecasting method. In that case you just need to make sure that you only take into account the historical data that’s valid for the current setup of the team.

What if My Project Does not Look like Anything I’ve Done Before?

The answer here is “give yourself a bigger buffer”. From a procedural point of view, nothing in the method changes. You just need to add more slack in the plan, so that you accommodate for the unknown. 

How much bigger should the buffer be? This must be a human decision, preferably of a very experienced person. Tooling is by no means a substitute for experience.

The benefit of this planning and tracking method will be that you will know very soon how accurate your plan is. As mentioned above, as soon as you have some historical data accumulated in the system, you’ll be able to produce reliable forecasts and update the original plan as needed.

What if I Have No Historical Data?

This is definitely a possible scenario, but more often than not, you’ll have it. If somebody asked you how much time it takes to buy some groceries from store A, you would be able to answer with some approximation, even though you may have never been to that store.

You will be able to produce an answer just because you’ve been to other stores in your life, and that’s nothing else but historical data. 

The problem with historical data is that we rarely have it in suitable formats. That’s why we encourage you to use proper tools that are able to collect and digest this type of information, which can later be used to provide all the benefits of continuous project forecasting. Some of the tools will even allow you to import your historical data and then do the analysis described above. In certain situations, this has been a life-saver for many.

Conclusion

This method for planning and executing knowledge work projects is going to be the next big revolution in management. We’ve relied on humans to do this kind of thing for many years, and it’s time to use machines and tooling to get us to the next level. 

When you combine Kanban, timelines, and the continuous forecasting method, you are ready to face much greater challenges while keeping risk low. As a result, you will achieve greater results and ultimately excel in your business.

This method is still very new, and not many companies are doing it. Chances are that this type of project management is going to be the standard in less than a decade, so you still have time to be among the first to adopt it and surpass your competition. Give it a chance now!