I've discovered the site Mosaic Projects. There is a wealth of material that I'm starting to go through. A useful paper is titled Links, Lags, and Ladders. It is about the topology of project schedules. In Microsoft Project there are many ways to link tasks with each other. This paper describes a few and speaks to the outcomes of these choices.
Here in Space and Defense, there is only ONE way to link work together.
Now to say this is the ONLY way is a bit of a stretch, but every effort is should be made to use FS for task connectivity. There is one critical reason for this:
To avoid rework, or at least intentionally caused rework, all future work should be dependent on 100% complete prior work. This does not mean rework will be avoided. Requirements change, defect are found, etc. But using anything other than FS intentionally sets up the conditions of rework for several reasons:
- Future work is started with incomplete dependencies - FS minus X Days
- Multiple work streams need to finish on or near the sane day - FF minus X Days
- Multiple work stream start on or near the same time - SS plus X Days
Here's the challenge question for all network topologies.
Wouldn't you want this reason to be based on a 100% completion of the dependencies? Would you want start work on partial information? This doesn't mean you have full information at the project level. No Big Design Up Front (BDUF) or Water Fall process. No this approach does not suggest that.
But for the smallest granularity of work - usually the work package - a firm set of "starting" conditions should be in place. This is the key to deciding how to partition the work. On what sized boundaries should the work be planned? The answer is simple...
Partition the work on the largest "small" boundary that can be assured to be complete prior to starting the subsequent work. This is a trick answer of course, but one that shoudl guide the partitioning of the Work Packages. The useful answer is to partition the work on single deliverables. Deliverables that can be measured in units meaningful to the customer.
The agilest software developers would call this "feature driven development." But a feature is usually defined, not has any quantifiable unit of measure. An since these features tend to emerge and are sometimes discourages from being described within an architecture, this is not very helpful.
A systems engineering approach is more tractable. The size of the Work Package is the lowest element of cost in the system that can be identified with a lowest level requirement. The requirements flow down tree can be the guide here. This is not a hard and fast rule. Like all good guidance it needs a context in which to be tested. And experience developing Work Package structures, WBSs and the sequence of work.
But think about this in terms of "least complexity of the topology of the program." This is a coupling and cohesion discussion. Decrease coupling increase cohesion, and you're on your way.