In 1989 I received my degree in Urban Planning. I have studied how to make plans.
In 2007 I received my certification to be part of the American Institute of Certified Planners. I have been recognized for making good plans.
I have planned subway systems, technology rollouts, urban growth patterns, transportation infrastructure, housing needs, freeway travel patterns, business projects, software development, building houses, building buildings, and on and on. I have planned.
I have also learned much. About reality. About complexity. About human nature. About how we plan. About politics. About blizzards. About locust plagues.
I understand, despite or perhaps because of my history, that plans are bunk, but planning is essential. The document (the plan) we create will disappoint us the moment it is completed (if not before). However, the act of planning, can only help us.
Planning is knowing what goal we are trying to achieve or what problem we are trying solve (our reason for doing this), what our current workload is (our capacity, our current level of distraction, our likelihood for being derailed), who the current workload is for (how many conversations we have in flight), what that current workload is going to look like in the future, what the other options for other projects we could be doing are, what the expected size of our new project is going to be (day? week? month? Six months? - protip...the longer your project the more wrong you will be about completion times), who we would be working with, and so on. Planning is knowing, tracking, and fully understanding the evolution of your project.
So, I promised four things to remember:
Thing 1: Your Estimate, Your Schedule, Your Gantt Chart is Always a Lie
I have built schedules for 20 years in Primavera. I have made Microsoft Project files that would make your head spin. Beauty in both complexity and foolishness.
Do we want to estimate? Absolutely. Without some sort of guess at the amount of time something will take we have much less of an idea of its opportunity cost.
But we need to remember that our estimate is made at the time we know the least amount about our project. We haven't started. We've learned nothing yet. As we begin to work, if we are tracking our work and measuring rates of completion, we can - in the future - forecast completion dates fairly accurately. But we need to start working.
Remember...the longer the schedule, the less accurate your estimate. You schedule will always wishful thinking. Your Gantt chart is always fodder for long meetings and poor discussions.
Thing 2: Your Current Workload is Worse than You Think
If you ever take on a project without understanding your current workload, you are starting at an extreme disadvantage. You must understand your capacity and your current workload before thinking your new plan has a chance. You are likely already overloaded. That means you have existing relationships with customers and colleagues to complete work. Every one of those relationships takes up time and energy. The more you add, the more unpredictability you have added to your day. Unless you are limiting your work in process and understand how much work you have on your plate (perhaps using a Personal Kanban), your new project is going to be as successful as the annual Hades Snowball Fight.
Thing 3: No Plan Survives Contact with Reality
Reality bites. I have seen projects derailed by locust plagues, acts of congress, tornadoes, blizzards, SARS, staff attrition, and...strangely enough...not understanding the complexity of our work. We simply don't know what is truly involved in completing our work. Again, the larger the project, the more likely you will find delays due to the interactions of everything with everything else.
Thing 4: You Forget Tons of Stuff and Remember the Rest Wrong
If you think doing something in the past makes you an expert in how it's going to work in the future, you are right. People who haven't are just guessing when they are wrong. You, the expert, are right about a lot of things...but you are wrong about a lot of other things. This means your schedule will end up looking slightly better than someone who is guessing. Rosy Retrospection and the Zeigarnik Effect combine to create one simple truth we don't remember the past accurately. We remember bad things as better than they were (which might impact both risk assessments and estimates) and we forget that a lot of work occurred at all.
State of the Planning Art
There's a lot of posts floating around the Internet about how to plan your work. There are products to help you make lists or organize your thoughts. That's all great, read them, take wisdom from them. But know this: the larger the project, the larger the margin of error. If you want to plan well, create small projects. Learn fast, adjust often.
If you want to build a real project, engage in planning. Build a system that asserts, acts, learns, and re-learns. Build a system of honest work like this:
Goal - Have one ... know what problem you are trying to solve or value you are going to create. Know why you want to do this and whom it will help. Let this goal and the options around it evolve as you learn.
Options - Create small projects to help you achieve your goal. Each one moves the needle a little. The faster these are completed, the faster you get value realize your goal. This could make it possible to achieve your goal incrementally. These are Options, make them, throw them out, use them like Lego to build value. You can only learn and adjust this way.
(Flag Waving: This is the point of the blog post. Many small adaptable batches beat big plans every day.)
The Work - Do the actual work.
Learning - Ask yourself how the work went. Was it done in the time you thought it would be? Is it the outcome something you are professionally satisfied with? What did the customer think? What did you learn that will make the next Option you pull easier?
If this seems a lot like PDSA ... it is PDSA with a slightly better push towards small batch thinking.
As always, if you can't describe what you are doing as a system (thanks Dr. Deming) and if you don't visualize your system, you have an assumption, not a system.