One of the lessons I learned way back in college math was the theory behind how to build and optimize complex project schedules. By defining all the work to be done and how long each element of the work will take, and determining the available resources and dependencies between activities, you can generate a schedule that guarantees you an end date. Fix the end date, and you have to vary the resources to make the dependencies work.
Back then, it took a lot of computing to do that. Today, you get all the tools in Microsoft Project on a PC.
There are a couple of issues with this approach. As you add multiple projects to a program of work, it gets harder to ensure that you don’t have resource conflicts, especially for critical resources such as subject matter experts and access to key business executives. You also can get into situations in which adding more resources to meet the effort required adds such high coordination costs that the schedule might work in theory, but can’t in practice: After all, 200 effort days can’t be delivered by 600 people in eight hours, no matter how hard you try.
What’s happening here is an inability to satisfy all constraints simultaneously. Big complex programs often suffer from this phenomenon, and there are several ways to address the issue. The easiest way is to relax one or more constraints, but what if that isn’t an option?
Another approach is to move the problem from the traditional “linear” optimization to a “dynamic” optimization approach.
Dynamic optimization uses a variety of techniques that in essence start with a “guess” at the answer and then iteratively improve the initial guess. These techniques often converge quickly to the best possible answer, but unlike linear methods that are guaranteed to get to an answer even if it won’t actually work, dynamic methods offer no such guarantee. With dynamic methods, it may take you an indeterminately long time to get an answer–and sometimes you won’t get an answer at all.
I hadn’t seen an example of dynamic optimization in normal business situations until recently. We ran a dynamic optimization on a complete year’s IT development plan and budget exercise. After four days of continuous computing, we still didn’t have a feasible schedule and had no signs of convergence.
None of the intermediate schedules we looked at were attractive: We were always failing at least one set of constraints. We had to decide if we should continue to run the optimization program and hope that we eventually got to a workable answer or tell the business that what it wanted was impossible.
This was a difficult decision. The theory behind all of the above is pretty esoteric, and even well-educated business managers don’t always have a math background. Plus, they have been widely trained to believe that, in a sense, every problem like this has a solution: You just have to try a little harder and a little longer, and an answer will emerge.
Here’s where the relationship between IT and the business becomes critical. If there’s a high degree of mutual trust and confidence, you can admit that what’s wanted is impossible and start to work on relaxing the constraints to get a feasible schedule.
That’s what happened for us. I don’t like to think about what might have happened if the relationship was less strong and the sense of trust absent. Happy planning.