Depending on Dependencies
We’ve launched dependencies!
Last night the team stayed up late making sure that the update to the site went smoothly. This morning our users were greeted with dependencies. This is a big deal for us as we were getting quite a few requests for dependencies. In fact, several people asked us why we launched without dependencies. I thought I’d take a minute to talk about that.
I have a love/hate relationship with dependencies. When we designed LiquidPlanner we realized that when you put all of your tasks in priority order you just don’t need that many dependencies. The reason being that if Task-A needs to be done before Task-B you just drag it up above Task-B and (provided they’re assigned to the same person) Task-A gets scheduled before Task-B. So if you slice your big projects up into small enough pieces (say by doing Scrum with one month sprints) then the whole “need” for dependencies just gets a whole lot less urgent.
We have been using LiquidPlanner to plan our internal work since about April 2007. It is now a year later and we have added dependencies, but we never really missed having them. In fact, one thing that dependencies do is make your project plan brittle. They make it hard to alter the plan without breaking a dependency or messing something up. That is not to say that the project can’t change easily, just that theproject plan cannot. This is kind of an artificial penalty for updating your plan to reflect changing reality.
I am all for moderate use of dependencies to build project plans. But I think that products which demand that you put a bunch of dependencies in place in order to get a halfway sane plan have trained many project managers to bad habits. They’ve become addicted to dependencies. And the more you use dependencies to solve your scheduling problems the more brittle and hard to maintain your project plan becomes.
So before you add that dependency ask yourself, “Do I really need this?”
Because if you can just prioritize the work earlier then you’ll end up with a schedule that is much more flexible and resilient to the change that inevitably occurs when a project plan meets reality.