Our "PoC/PoV" offer

Quickly create relevant code to resolve technical uncertainties on a more ambitious project.

Marc Hugon

Technical Project Manager

Do you have a business opportunity but don’t know how to address it technically? Do you have a project but doubts about its feasibility, or even the investment required to bring it to fruition?

Are you faced with a budget estimate that is not in line with the investment you feel is the most coherent?

  • Have you identified a business opportunity that you’d like to test to see if it makes economic sense?
  • Our support proposal is customised, and may include some or all of the following elements:
  • Identifying the precise cause of your indecision
  • Definition of a minimalist project to ensure an unambiguous answer as to how the project should be carried out
  • Development of this project with code that can be reused in your final product
  • Test the code, potentially in production, if it turns out that this is the environment that removes the greatest number of doubts.
  • Report on the findings and documentation to explain the methods and resources used

1 – Understand your project and your doubts

The first step is to understand your business objectives. This is the common thread running through all subsequent work. The aim of this PoC (Proof of Concept) is to help you achieve your business and/or organisational objectives.

We then focus on the problem for which you need outside help.

We interact with your technical and business contacts to get a precise view of the maximum number of parameters to be taken into account. The aim is to identify all the constraints, whether technical or organisational.

The result is a reference document for subsequent stages.

This work is carried out with the technical expert developing the PoC, accompanied by a technical director and supported by the rest of the Kaliop teams.

2 – Defining the PoC/PoV

A PoC (Proof Of Concept) addresses a technical issue, while a PoV (Proof Of Value) is functional. The PoV differs from the MVP (Minimum Viable Product) in that the viability aspect is purely a question that arises. In all cases, the same project approach is used. The people involved will generally be the same, but their degree of involvement will vary. Logically enough, technical skills will be called upon more than functional skills in a PoC, and vice versa.

Before embarking on the project, you need to define:

  • The functional need to be met, and the technical interactions required to achieve it. UX phases can be considered at this stage.
  • How development is to be carried out and deployed
  • The means by which the result will be verified
  • The estimated time investment for the development

This ensures:

  • That the framework corresponds to the expectations you have formulated
  • That the code to be created complies with your expectations, which may include integrating this code into your own applications.
  • That we can verify precisely what the test will or will not achieve
  • That lastly the time spent on this development remains limited, in line with what has been defined as a reasonable and sufficient investment to achieve this objective.

3 – Develop and test

Kaliop recommends the use of agility in general, but even more so for this type of project.

More specifically, it’s the ability to test iterations as quickly as possible that’s crucial in avoiding wasting time on assumptions that turn out to be wrong.

Therefore, the main objective during this phase will be to facilitate regular testing as the project progresses.

As time is limited, it is frequently important that you make personnel available with the requisite knowledge to help the Kaliop team discover your systems. This is a key factor in preventing too much time being wasted on solution development.

4 – Building on experience

All tests carried out during the development and acceptance phases are incorporated in the final report.

They enable us to objectively present the results observed, whether or not they meet expectations. In all cases, we capitalise on improved knowledge, whether to solve the initial problem or to identify ways of achieving the initial business objective.

This feedback contains:

  • The code produced
  • Documentation required to use the code
  • What was found in the tests
  • Depending on results and expectations, a proposal for the next stage of the project with an estimate of the effort required.

Interested in this offer? Our teams are here to answer your questions

Contact us