Planning vs Scheduling

Q1 is done in most places, so Q2 planning is mostly done as well. Or at least what passes for planning. The list of expected (required?) work has been identified, ordered, and scheduled. Names have been assigned to each one. The “planner” now knows who’s doing what and when it will start and finish. How could anything possibly be more planned than that?

In theory, that is planning. But as they say, in theory, there’s no different between theory and practice. In practice, there is. That happens to the plan almost instantly. Someone is out for a day or two, something takes more (or less) time than expected, or some new piece of information becomes available and suddenly something that wasn’t important is now the most important thing. As soon as any of those, or a host of other possible things, happens your detailed plan, with names and dates and expectations, goes out the window.

The fact that the “plan” is invalid is obvious. What isn’t always obvious, and certainly not as well understood or accepted, is that you didn’t have a plan in the first place, so there’s no way that the plan became invalid. What you really had was a schedule, and the schedule that became invalid.

Now schedules aren’t bad. In fact, whenever you need to coordinate two or more people/teams/orgs/groups schedules are critical. They let the second party know when they can expect something from the first party. They provide a mechanism for sharing information about the current validity of those expectations and changes to them. They let you largely decouple things. They let you identify inverted dependencies and places where things won’t be ready when they’re needed.

Schedules are required for planning. The schedule is one of the inputs to planning, along with your overall goals and your priorities. Planning is the process of taking your overall goals and priorities and adjusting those schedules based on the dependencies discovered so that you end up with the thing you need when you need it. Planning talks about contingencies. Planning defines how you respond to things. Instead of a simple ordered list it’s a branching graph that winds its way to the goal. It’s reactive and responsive to the environment as you proceed. If A happens we do B. To ensure C doesn’t happen we do D. If E doesn’t happen we do F, then change A and D and switch the ordering of G and H to compensate.

So you need schedules to make plans. Unfortunately you can’t schedule everything. You need to know what the priorities and goals are. You also need to know what responses to the environment you might need so you can schedule them. But you don’t know those responses until you finish planning. And you can’t do your planning until you’ve done the scheduling. Which leads us to a dependency loop.

One really good way to break that loop is to do them at (almost) the same time. Top down **and bottom up. The goals and priorities give you a small set of things that need to be done, so schedule them bottom up. At the same time, do some sequencing and strategic planning of the those things to identify dependencies and possible environments responses top down. That gives you some new things that need to be scheduled, and the newly defined schedules give more insight into the dependencies. Iterate a few times until it starts to converge. Then stop planning and scheduling.

Start working and monitoring. As you progress you’ll figure out which of the responses you’ll need. Update the schedules with actuals. Feed the reality back into the plan. Adjust the plan. Lather. Rinse. Repeat. Because like Eisenhower said, Plans are worthless, but planning is essential

And one last thing. Consider not assigning tasks to people when you’re scheduling. Don’t ignore capacity, but putting actual names down is just one more constraint you don’t need. There’s lots more to say about that on another day.