Depending on Dependencies
Tuesday, April 1, 2008 at 2:35PM
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 the project 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.
Reader Comments (3)
I hear you about dependencies. Two situations that I need dependencies for are:
- sequencing roles (e.g. designer, developer, tester) The developer can't start until the designer is done...
- outsource components; controlling delivery has been a challenge. When my local deveopers are waiting and I adjust delivery of a component they're waiting on that dependency causes some other piece of work to naturally fall ahead in the schedule (hopefully that's clear)
Any suggestions for how to tackle these without dependencies?
I _love_ LiquidPlanner!! Thanks!
I had the same question as John. The client can't review the page until the development is done. Isn't that a dependency? How else would I model that in your system?
Using dependencies to model stuff like "developer can't start until designer is done" is a perfect use of dependencies. Just don't go crazy making everything dependent upon the thing in front of it. Try to limit your use of dependencies to where big sequences of work go from one person to another.
Now the developer might not be able to start on the user interface until the database work is done. But if both the UI and DB work are assigned to the same developer just put them in priority order rather than building a dependency.
Dependencies are kinda like absolute references, they make a schedule very brittle. Move a couple of things around and all of the sudden you're left trying to figure out why your schedule looks so wacky.