In software development there exist things called integration points. This is when any point in the process your working on makes contact with an independent system. You must also include the systems that that system depends on, so the count can quickly balloon. If you’re sleeping with X, you’re also sleeping with all the systems X has slept with.

Every time your dependent on a independent system, the risk of success of your project is reduced. Does your project depend upon a web service? A .dll file? A folder/file on the server? Network permissions to the folder? Each of these integration points can cause a failure in your project, none of which are in the scope of the changes to implement the feature set. Most integration points are unavoidable, but if you’re considering a particular architecture and are considering a web service (for example), think again. If you need to access the service from multiple systems, across networks, or on a heterogeneous architecture it may be the best option. But don’t do it without thoughtful consideration to the risk that you’re adding to all the future projects that require that service to be running, and running bug free.

It’s not the only way to identify risk for a project, but should be considered as a factor.