IT project closing and receipt

An implementation contract may provide for a single acceptance of the subject matter of the work upon completion of the project, or for several acceptances upon completion of various stages. The primary purpose of acceptance is to confirm that the work has been duly performed. In the case of software projects, this will generally require software testing by the contracting authority's technicians. The parties should estimate the duration of testing and include it in the schedule. In addition, acceptance can also perform other functions, such as conditioning the initiation of payment or the start of the next stage of work.

The first stage of acceptance after receiving confirmation of acceptance of the application created within the project is its installation on the production server.

Sometimes the completion of a project is forced, in which case it does not require formal acceptance by the client. Completion of a project in this way occurs when, for example, a rigid date is specified for when the application must be ready in connection with a specific event. For example, the event website must be done before the start date of participant registration. The client is forced to accept the product regardless of whether it meets all the requirements.

A very large group are projects that do not have such a rigid end date and require detailed verification. However, they require work on the part of the client and the project team and are created in the early stages of the project. In simple terms, it is a list of functionalities that must be verified by one of the project members and received by the client.

Another element of project closure is the preparation of documentation. It is especially important if the product created as a result of the project will be further developed or improved. In such a case, the documentation will be the starting point for the next project, regardless of whether it will be carried out by the same or a different project team. Documentation is also important from the point of view of learning and optimizing the organization's work. Documentation should not be limited to showing how the project was planned, but should also include how the project was implemented, what deviations from the plan occurred and why. The issue of documentation in IT projects is very often associated only with technical documentation. This is documentation intended for programmers who will modify the program. The ability to automate the creation of technical documentation unfortunately also requires additional work for the programmer, so whether it is developed traditionally or generated the time spent on its preparation should be included in the project schedule. In addition to technical documentation, there is also user documentation for users and system administrators. Each document should take into account the updates, changes and corrections made to it during the project.

Partial acceptance is used for extensive and complex projects. One-time acceptance is done at the final stage of implementation, while partial acceptance is done during implementation. Partial acceptance allows for greater control over the execution of a given project. It is then possible to keep track of the stages of implementation and make comments on the implementation of the project. Such action reduces the risk of non-compliance at the final stage during final acceptance.

During the partial acceptance, a summary should be made with the Contractor and conclusions should be drawn to improve the project in further stages. During the partial acceptance, it is worth conducting:

It is possible to introduce the concept of conditional acceptance into the implementation contract. This means that the Contracting Authority performs acceptance despite low-category irregularities, the removal of which should be carried out during the next partial acceptance.

For good cooperation of the parties, it is necessary to define precisely the schedule of acceptance of individual stages of the project. The deadline for acceptance of a stage can be expressed as a specific date or as a lapse of time, i.e. after 14 days, after 2 months. It is also worth remembering to specify a deadline for reporting any irregularities in the software prepared for acceptance. The time given to the Ordering Party should be taken into account by the Contractor when creating the implementation schedule. Another important aspect is to determine the frequency of comments on the subject of acceptance by the Ordering Party. From the Contractor's point of view, it is also worth including in the contract the impossibility of reporting irregularities in software that has already been accepted without objection at a previous stage.

If there are software errors during final acceptance, the following options can be used:

The acceptance protocol is a confirmation of receipt. Most often, the model protocol is an attachment to the contract. The final stage of the acceptance procedure is the final acceptance. In the contract, the procedural mode of signing the acceptance protocol, its form and the persons authorized to sign it should be specified in detail. As a safeguard, it is also worthwhile to condition the moment of transfer of property rights to the software or the moment of granting a license at least on the moment of unqualified acceptance, and the most optimal solution - on the moment of payment of remuneration.

Whether such a meeting will take place at all is usually highly questionable. More often than not, the end of one project is the beginning of another, and there is not enough time to spend additional hours on an already closed project, although practitioners argue that it is worth it. During such a meeting, it is worth answering the following questions:

Today's post on the topic of the software acceptance procedure first of all demonstrates the need for accurate and precise wording of contractual provisions.

In practice, cooperation with DevsPower does not end at the moment of signing the acceptance protocol because the stage of implementation, launch and implementation of the application is followed by another one. Further cooperation consists of meetings with the client's team, during which we pass on knowledge regarding its further editing, updating and scaling.