Information Technology Reference
In-Depth Information
Open Issues
Measures
Responsible
Deadline
Fig. 7.9 Open issues list
these issues still await resolution. Thus the remaining issues list becomes part of the
acceptance documentation. The timely resolution of the tasks still open has to
continue to be tracked after the system has been put into service. Here are some
possible remaining issues:
Training,
Data clean-up,
Access rights etc.
7.3.4.1 Escalation
Just as with any other project at the start one or several escalation paths have to be
defined in case it breaks down for a number of reasons. For test system build these
paths can depend on the tasks outlined below. Accordingly there may be different
addressees for escalations:
Uncertainty about the responsibilities concerning data sourcing or data updates,
Unforeseen change requests for example for interfaces,
Creating system specific training documents,
Responsibilities for customising.
Apart from the above there may be the usual reasons for escalations: passing
deadlines, acceptance rejection etc.
7.3.4.2 Customising
The overall customising subject has been described above.
7.3.4.3
Interfaces
In case specific interfaces are required for system build their adjustments have to be
documented in functional and technical specifications. Furthermore, the necessary
