 users or customers. Multiple corrections are collected and compiled together as a change delivery of the software release delivered. The main purpose of publishing a change delivery is to correct the existing faults and also bring about improvements of the existing software release. The change delivery comes in a package comprising a storage media from which the change delivery will be copied, documentation and master EPROMs. The change delivery will first be installed in the operator's testbed by the vendor, where it will be tested and verified. If accepted, then it will be taken forward to the network element and a change delivery installation fee will be levied on the operator. Correction Time Failure reports are generated using different priority classes, namely A, B and C, with the severity given in descending order: A>B>C Response Times The failure classes in Table A.2 have an impact on the response timings but even a C class failure can have the fastest response time. Depending on the failure report, different priorities are assigned to the faults and their correction schedules. An emergency situation is referred as an A category failure priority. In such a case correction work starts immediately and a work-around has to be achieved. The B category of priority is given to almost 80 % of the cases, where an answer from the vendor takes about 4 weeks Roll-Out Network Project Management Table A.1 Failure reports in descending order Failure priority Explanation Examples Major outage System restart, all links down Charging lost Repeated restarts of different units Alarms or measurements not coming at all Major service affecting If any basic service is materially affected problem Single restart of signalling units Alarms from one or more network elements lost Major problems with statistics Difficulties with creating new subscribers Difficulties to activate supplementary services Problems with backup Problems with charging or measurement transfer Minor problem that can wait Errors in statistics output (unless ca