Blog post #7: Pay for a challenging Proof-Of-Concept

At this stage, you should have a better understanding of the modernization market (main actors, different approaches and products). However, you do not know yet what a modernization project looks for in terms of execution:

What should I provide/do as a customer?
What will I receive (source code, deployment scripts, data migration scripts, reports…)?
Would the result meet the expected KPIs? How to measure them?
Do you really know if modernization option A is better than option B?
Would I be able to drive the project in terms of internal resources (skills and availability)?
Would I be able to receive/validate/integrate the modern modules/applications?
…

The questions are multiple, you can ask all of them to your potential modernization partners and you will probably get smart answers with a lot of “we mitigate risk thanks to”, “we deliver weekly reports”, “we assign our best managers to”, etc. Instead of trusting slide decks and appealing emails, pay the pre-selected companies for a proof-of-concept (POC). They will have to prove the feasibility of the project and actually validate the accuracy of the promises before signing for a full project.

The POC will demonstrate for real the benefits and drawbacks of the different solutions and bring actual answers or, even better, let you rise other questions. Within a pre-defined and limited perimeter (budget, time, source code, datasets and KPIs), order a “small” modernization project.

How to prepare the POC

Preparing a POC is as simple as choosing a set of legacy programs (screens, batches, etc.) that represent the key aspects of your application, representing a reasonable number of lines of code, complexity and heterogeneity with respect to the whole application. Within the source code, you may provide the test scenario (input data, expected output data and the time of processing).

How to measure the success of a POC

Here are the most important points to be checked to measure the success of a POC.
Your modernization partner delivers a runnable application with a documentation explaining how to test it;
The modernization partner meets all of the project metrics (cost, duration, risks);
The methodology is efficiently applied (transparent, iterative, collaborative…);
The modernized application respects your standards (performance, maintainability, patterns…;
All the phases have been performed using proven tools;
Your team questions have been addressed (not just in slides!);
You played an active role in the process;
Your team was able to deliver the required artifacts.

With this POC step, each vendor proves that its offer meets all the expected KPIs regarding the quality, maintainability, performance, delay, cost (ROI) and level of effectiveness. Actually, this is the best way to help you make the right choice based on facts. It is a very efficient way for you to benchmark all possible scenarios. As a result, they can evaluate the relevance of their own acceptance process and rules before the project starts.

Conclusion

From our experience, such POCs are the most efficient way to assist your team on collecting required legacy artifacts. It contributes to mitigate risks at project start and align your expectations with the deliverables. As a result, the POC definitively helps you to experience the process before scaling to the full project and avoid any misunderstandings which could jeopardize the success of your project.