Scheduling and Managing Interdependent Sub-projects


In my project management class today, one of the students asked about how to schedule interdependent sub-projects. The scheduling tool he uses doesn't deal well with pieces of one sub-project having dependencies of other sub-projects. It's difficult to see the critical path, and to know what's really going on. (It's too easy to have circular dependencies in the scheduling tool.) I asked if they scheduled by architecture component or by feature. I'm not sure if I understood the answer (or if the student understood the question), but I think they're organizing around architecture pieces.

If you have a number of sub-projects and they're coupled (have dependencies on each other), try rethinking how you organize the work. I bet if you organize the work by feature instead of by architectural component, you'll be able to schedule easier. My student wasn't so sure this would work — he has some scarce people resources who need to work on multiple features. I suggested they rank the features by priority (1, 2, 3, 4, …) and have the scarce people work on features in rank order. This requires cross-functional teams and the ability to recreate small feature-driven teams. This would be a huge change for the student's company.

I'm a bit stuck. I only see program management (treating each feature like a project, managing all the projects, and using cross-functional development teams to perform the work) as a solution when you want to break tightly coupled interdependent sub-projects. Since I can't think of three alternatives, it's time to ask for help. Do you know of any alternatives?

2 thoughts on “Scheduling and Managing Interdependent Sub-projects”

  1. If you have two projects A and B, both of which depend on each other, perhaps you can break out a third piece, C, and have them both depend on that instead?
    For example, perhaps project A is “implement feature X”, and B is “test feature X”. In an agile programming shop, you could see these two activities as interdependent, since the testing might show up design bugs, which then need to be fed back into the implementation project. In that case, the project C might be “come up with a spec for feature X”. The tests can test against the spec, and the programmers can write to the spec. This might add more overhead than you’d like, but if the overriding goal is to break a cyclic dependency, it’s one way to do it.
    In general, I suppose it depends on the nature of the interdependency.

Leave a Comment

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: