Scheduling is defined as "the process of deciding how to commit resources between a variety of possible tasks." In the software industry, most of us use this term interchangeably for project scheduling, which builds on prior project planning. This idea has always been one of the most challenging areas in software construction: How do I complete all artifacts required for a specific release? How do I manage and commit the resources available? What happens if something goes wrong? The goal of this article is to bring a different perspective to the table, hoping that the reader will start rethinking scheduling in a different way.
The Empire State Building History
Let us all remember that famous quotation "Those who ignore history are destined to repeat it" while we revisit some successful cases, such as the building of the Empire State building. Demolition started on September 22, 1929, and the building opened on May 1, 1931, exactly on time and 18 percent under budget. How did they do it in a time before computers? They focused on the flow; on their constraint.
In the book Building the Empire State. Builders Notebook by Carol Willis, the builders mention that they focused their schedule on steel and that they thought of work as if it were a band marching through the building. In other words, they did a simple scheduling of their constraint: "material flow." Without that focus, there was no point scheduling other resources, such as workforce (which by the time, was abundant). This is like finding the critical path  and scheduling to that, which is certainly sensible. The critical path won't remain fixed though. It has to be tracked as any unpredictable events unfold. The important take away is that we can borrow these types of ideas and apply them to the software development world.
Lessons Learned? Know Your Constraint, Schedule It, and Follow Through It
Perhaps, in the software industry, we have been too focused on too many things. My personal experience as a technical lead has been that we try to schedule too many variables, and when we lose sight of one of those variables, even for a valid reason, we offer excuses and finally end up throwing away the schedule. Without the vision that a schedule offers, we end up sacrificing functionality or quality. Sound familiar?
But, what if we stop scheduling too many variables? How should we focus? We focus on the constraint. For example, within the projects that I participate on, most of the time our constraint has been the information about the problem to solve; however, we schedule our resources based on a perfect flow of information, which never happens. So, you must know your constraint and schedule it. The constraint could be:
- Information about the problem to solve
- Understanding the best solution to the problem
- Available developers, quality analyst, business analyst
- Available equipment
Meet with your team members and gather input from them on what the real constraint is and the risks that may trigger other, greater, constraints. This comes from borrowing some of the lean manufacturing ideas, which are all about taking care of what provides value to the customer and eliminating everything else. In this case, we are defining what brings value to the schedule (the constraint) and getting rid of the other variables that will not impact it (e.g., if I have more available resources than I need, then I should not focus on that). Of course, learning to eliminate what is not needed from a schedule in order to focus on what's really important is more art than a science. Womack and Jones are a good reference on lean .