Figure Proj.04 Illustration- element relationships Table 1 - Allowable Project Relationships

<font color="#29313b">Table 4 shows the allowable relationship type combinations for different ProjectElement types. These restrictions would probably be implemented with a rules or policy engine.</font><br/><br/><font color="#29313b">Note that table 4 only gives suggested linking rules. In general, projects should be globally visible but the visibility of WBS elements and Activities should be more restricted. Allowing individual Activities to be linked across Projects means that the detailed structure is then available to other Projects. Changes in the detail can then cause the relationships to become invalid. We need to balance unstructured relationships (which will become a mess) against being too structured (which doesn’t allow us to implement valid requirements).</font><br/><font color="#29313b">Figure 5 shows the specification or knowledge layer. The specification entities have been highlighted in green to make the distinction easier to see. Note that the composite pattern for the specifications will often not match that for the instance entities. Also, the instance layer or specification layer may not have a corresponding composite pattern in the other layer. This is deliberate and not an error. </font><br/><font color="#29313b">The specification layer would probably relate to providing templates for standard situations. ProjectSpecification could provide for common project types to be stored as templates (e.g. ‘Software Project’, ‘Install Remote Switch’, ‘Product Launch’). The Project template could contain standard WBS structures, activities and resourcing that could reduce the effort in creating projects.</font><br/>