A Procedure is a document written to support a “Policy Directive”. A Procedure is designed to describe Who, What, Where, When, and Why by means of establishing corporate accountability in support of the implementation of a “policy”. The “How” is further documented by each organizational unit in the form of “Work Instructions” which aims to further support a procedure by providing greater detail. For example, a manufacturing facility established a policy that all overtime shall be approved. A procedure can be created to establish “Who” can approve overtime (ranks, roles & responsibilities), “What” forms/systems need to be used, “Where” they are located, “When” overtime is applicable. And the “Why” refers to the management directive established via a “Policy”. The output of a procedures become input into a work instruction which is a set of actions or operations which have to be executed in the same manner in order to achieve intended results under the same circumstances.(for example, in the latter example, the “what” [output of procedure] could be further broken down into a work instruction to describe “how” a manager/employee access the systems for approving/reviewing overtime, i.e. click on this hyperlink, on this button, and choose these fields, and click approve/reject. In telecommunications, this is the premise under which a SOP (Standard Operating Procedure) is generated. A SOP is specifically designed to describe and guide multiple iterations of the same procedure over a broad number of locations, on multiple occasions, and over an open period of time until such SOP is updated for whatever reason, or discontinued. Used heavily in the telecommunications industry, a MOP (Method of Procedure) differs from a SOP in that it contains specific directives for that particular activity, on that particular date, for that specific location or piece of equipment. In today’s business model, wherein telecom providers can be both “provider” and “user”, most “user” organizations require a MOP from the service provider whenever an activity has the potential to cause a traffic-affecting outage. The industry standard is <50ms of traffic interruption. If a "switch hit" or traffic interruption is 50 ms or less, it is "transparent" to the bit stream carrying the traffic, and is therefore considered "hitless" and non-traffic affecting.