Despite many learned texts speaking of dependencies only in terms of project planning, it is important to consider the above definition in the widest possible context. In particular dependencies may take many forms including:
Physical | my generator is bolted to your concrete slab |
Functional | my sales order message is consumed by your order processing service |
Temporal | we need access to this shared resource at this time |
Commercial | your service must meet these contractual constraints |
Dependency management may be complicated because the 3rd party involved may not be planning in a project environment, and hence the relationship cannot always be expressed by the linkage of tasks in integrated project plans.
In this definition of dependency the interfaces between IT systems are functional dependencies. These are often the most complex of dependencies and require formal definition. Do not however underestimate other types of dependency.
In practice you will need to:
- Define dependencies as completely as practicable, and maintain a dependency register.
- Ensure dependencies are described and managed consistently by both parties.
- Implement a formal sign-off process for dependencies in order to eliminate ambiguity.
- Eliminate dependencies through design and implementation methods wherever reasonably possible. This is known as de-coupling, and is critical in very complex projects.
- Target risk, opportunity, assumption and action management at elimination of dependencies.
NEVER EVER assume that people will manage their dependencies correctly, challenge every implicit assumption, and define every aspect. Also when contracting for products and services, analyse every dependency and ensure the contracts facilitate integrated working and management across these interfaces.
No comments:
Post a Comment
Note: Only a member of this blog may post a comment.