http://jrothman.com/blog/mpd/2004/12/scheduling-and-managing-interdependent-sub-projects.html Management, especially good management, is hard to do. This blog is for people who want to think about how they manage people, projects, and risk. Mon, 01 Dec 2008 19:14:55 +0000 http://wordpress.org/?v=2.6.5 http://jrothman.com/blog/mpd/2004/12/scheduling-and-managing-interdependent-sub-projects.html#comment-18 Bob Corrick Wed, 15 Dec 2004 00:01:48 +0000 http://jrothman.com/blog/mpd/?p=8200#comment-18 Would the material at http://www.pdinstitute.com/soapbox/2004/11/17-critical-chain-model.html be helpful here? Would the material at
http://www.pdinstitute.com/soapbox/2004/11/17-critical-chain-model.html be helpful here?

]]> http://jrothman.com/blog/mpd/2004/12/scheduling-and-managing-interdependent-sub-projects.html#comment-17 Kimberley Burchett Tue, 14 Dec 2004 03:30:40 +0000 http://jrothman.com/blog/mpd/?p=8200#comment-17 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. 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.

]]>