DevsPower logo

Services

Company

EN

The person handing the folder labeled "Project" to the other person over the desk, which ugerates the exchange of project documentation or the transfer of the project

IT project closing and receipt

The software acceptance procedure is an extremely important part of the implementation contract, which should be carefully developed by the parties: the ordering party and the contractor. Today's post is devoted to issues related to the receipt of programming work.

DevsPower Logo
DevsPower

28th September 2022

Introduction

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.

Project documentation

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.

Which way to choose for acceptance: one-time or partial acceptance?

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.

Acceptance of project stages

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:

  1. A detailed test of the donated software modules. Time should then be found to conduct detailed tests of the operation of the modules that are being received. At the stage of partial acceptance, there should be no situation that the module that is the subject of acceptance does not work.

  2. Summary in terms of the implementation of the specification. A good solution is to create a summary that includes two elements: Description from the specification and Implementation Evaluation.

Conditional acceptance

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.

Schedule of acceptance of project stages

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.

Final acceptance

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

  1. Postpone the acceptance of the software to the next date, during which the demonstrated errors will be corrected.

  2. Sign an addendum to the contract with the Contractor, which will include the described errors along with a deadline for their correction.

  3. Identify the errors in the acceptance protocol and determine their correction within the framework of the warranty provided. It is important to specify the time within which the errors will be corrected.

Acceptance protocol

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.

Evaluation meeting of the project team

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:

  1. Were the project goals achieved as perceived by the project team and the client?

  2. Was the project completed on time, within the specified budget and did it meet the requirements specified in the specifications?

  3. Was the client satisfied with the results of the project?

  4. Was business value achieved?

  5. What conclusions can be drawn about the project methodology?

  6. What worked and what didn't?

Summary

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.

DevsPower Logo
DevsPower

5 minutes read

Contents:
1. Introduction
2. Project documentation
3. Which way to choose for acceptance: one-time or partial acceptance?
4. Acceptance of project stages
5. Conditional acceptance
6. Schedule of acceptance of project stages
7. Final acceptance
8. Acceptance protocol
9. Evaluation meeting of the project team
10. Summary

DEVS Sp. z o.o.

29/8 Święty Marcin Street, 61-806 Poznań, Poland

VAT ID

PL7831851750

REGON

52124537900000

KRS

0000954492

© DevsPower. 2024. All rights reserved

When you visit or interact with our web application, services or tools, we or our authorized service providers may use cookies to store information to help provide you with a better, faster and safer experience and for marketing purposes