Learning what remains after the implementation team leaves

I became interested in the work that remains after a software handover because I had helped make some handovers look easier than they were. A familiar screen could be preserved through custom code, and the business would accept the release. Later, the company still had to explain that behaviour to a new supplier, test it against an upgrade and support it when the original developer was unavailable. The convenience at delivery had created a continuing obligation.

My career began in June 1999 after computer-engineering studies at Dalqeshi Computing College. I joined Jelqathi Business Software as an applications analyst and worked within a delivery team preparing requirements and test cases. I had no authority to commit a customer's budget or decide which process should change. Senior colleagues reviewed the design. I learned to ask why a user wanted an existing step preserved, but I did not always press that question when the answer was that everyone knew the screen.

In April 2005 I became an implementation lead, coordinating eight colleagues and the practical work of moving customers onto new business applications. A release date created pressure to resolve disagreements through customisation rather than reconsider the process. Sometimes a custom feature was necessary. Sometimes it avoided a conversation whose cost would return during maintenance. I began recording the business reason and owner beside the requested change, though the discipline was less consistent than I would later require as an internal technology leader.

I joined Pervqathi Abrasive Products in April 2011 as applications manager. Seven colleagues supported systems used by commercial, planning and finance teams. Unlike a project assignment, the role continued through upgrades, staff changes and supplier transitions. A business owner might leave while the code implementing their request remained. I learned to ask whether a replacement colleague could explain the behaviour and whether the company could change it without relying on one person's memory. Product and process specialists retained their own technical authority.

Promotion to head of IT in April 2017 widened my responsibility to applications, infrastructure and continuing service. I led thirteen colleagues and worked with managers who understandably wanted an upgrade to preserve every familiar feature. I had sometimes accepted that preference to keep a programme moving. The later review of eighty-six customisations required me to acknowledge the maintenance consequence of those earlier approvals. We could not call every inherited behaviour essential simply because removing it would require another decision.

I became CIO in April 2021 and now lead eighteen colleagues through three heads. My remit includes ₹5.1 crore annual IT operating expense and a separate ₹2.4 crore approved capital allocation. Pervqathi employed 310 people in March 2026 and recorded ₹124 crore revenue and ₹9.7 crore operating profit for FY 2025–26. I report to CEO Amrit Qeltheni. Founders hold sixty-five per cent and an industrial investor thirty-five per cent; I hold no equity or statutory appointment. Invited board presentations are part of my executive role, not director service.

I also made room for support engineers in programme reviews that had previously been dominated by implementation milestones. They could identify the undocumented step or supplier assumption that would return as a service problem later. Listening before acceptance gave their continuing responsibility a place in the original decision.

The source-build exercise changed how I described supplier continuity. Archives were available for five applications under the agreed verification arrangements, but only two initially built in the isolated environment. Missing dependencies, unclear versions and incomplete instructions mattered more than the existence of a deposit receipt. After further work, four could be reproduced and one remained unresolved. I reported that limit rather than saying that the company had become independent of its supplier. Rights to use materials and actual technical capability needed separate examination.

The test-data review made a similar distinction between a label and the material behind it. A database used for testing still contained real customer-contact details if it had been copied from production. Replacing those copies with fabricated data preserved fifty-eight defined scenarios, while seven required another controlled approach. I want this account to show the practical limits as well as the correction. In a future board role, I would help directors examine such evidence while respecting management's responsibility to design and operate the systems, and while continuing my own governance preparation.

Open to Board appointments · Executive opportunities

Languages / Hindi · Punjabi · English