The team has delivered the technical specification. Every planned feature works. The system is live, and the acceptance document has been signed. Yet six months later, employees still keep their records in spreadsheets, management does not trust the reports, and every change requires another budget allocation. Can we call this a successful IT project?
In my view, this is where the conversation about the value of software development should begin. Working software is essential. But the customer is investing in change: faster customer service, more accurate planning, fewer losses and more reliable oversight. If those changes do not happen, the system’s technical readiness tells us very little.
Artificial intelligence makes this distinction more visible. It helps create software components, tests and prototypes. Yet speeding up individual tasks leaves the central question unanswered: are we building the right system, and will the organisation be able to benefit from it?
Imagine a company commissioning a custom CRM. Its requirements include customer records, enquiry histories, a sales pipeline, email integration and reporting. That description is already enough to estimate the work and begin development.
But the company may be losing customers because its staff have no shared rules for handling enquiries. One request gets processed twice; another goes unanswered. Nobody has defined when responsibility passes from sales to the service team. In that situation, a new CRM may simply move the organisational confusion into a new interface.
The project should therefore begin with agreement on the change it is meant to deliver. That might mean reducing the time to a first response, ensuring every enquiry reaches an accountable employee, or eliminating duplicate data entry. The team can then make an informed decision about whether custom development is necessary or whether configuring an existing product and changing working practices will be enough.
I consider the willingness to question the original brief a sign of an IT team’s professional maturity. A supplier should be able to explain why a particular feature will not help achieve the goal, or why another problem needs to be solved before that feature is built. The customer, in turn, needs to be willing to revisit their own assumptions.
Once the goal is clear, another demanding task begins: designing a system that can withstand real operating conditions.
A demonstration can look convincing: the user places an order, the system accepts payment, and the warehouse receives a notification. In real life, the customer presses the button twice, payment confirmation is delayed, and the warehouse service is temporarily unavailable. The team needs to determine in advance how the system will behave, what the user will see, and how the data will be restored to a correct state.
This is where the value of engineering becomes clear. It encompasses the connections between components, error handling, access permissions and recovery from failures. The quality of each of these implementations directly affects the business.
That is why I am cautious about claims that “code does not matter”. A software defect can cause financial or data loss. At the same time, a perfectly implemented individual module cannot fix contradictory requirements or a flawed model for interactions between systems. Professional software development requires attention to all these levels.
Architectural decisions also determine the customer’s future freedom of action. Will it be possible to connect a new sales channel? Replace an external service? Hand support over to another team? Retrieve the company’s own data in a usable form? The answers affect the cost of owning the system for years to come.
A more complex architecture is not necessarily better. A small product may need only a simple solution that the team understands well and can maintain. Provision for future development should be justified. Every additional complication carries a cost.
The arrival of AI tools makes this discipline particularly important. When a new feature is easy to generate, there is a temptation to add capabilities without adequately discussing their value. Yet every accepted change adds to what must be tested, secured, documented and maintained.
Producing code quickly does not release the team from these obligations. If validation cannot keep pace with development, more work accumulates whose quality has yet to be confirmed. Productivity should therefore be assessed by the time it takes to reach a validated outcome, including fixes and rework.
The next challenge begins during implementation. The system needs prepared data, clear rules for use, trained employees and support. If these tasks are left until “after launch”, the business will receive software it is not yet ready to use.
Imagine an electronic document workflow in which a document is approved online but must also be printed, signed and passed to the same people. The number of operations increases. To benefit from the implementation, the organisation needs to review its procedures, establish the authoritative approval process and remove duplication wherever it is unnecessary.
This requires the customer’s management to participate. The IT team can propose a solution, explain the consequences of different options and deliver the technical implementation. The authority to change how departments work remains within the organisation. The parties’ responsibilities need to be agreed at the start of the project.
I suggest that leaders establish several things before approving a budget: the problem to be solved, how improvement will be measured, who is responsible for changing the process, and what resources will be needed after launch. They should also define the conditions for reconsidering the decision: signals that the approach should change, the scope should shrink, or development should stop.
It is also important to establish a baseline. If a company wants to process orders faster, it needs to know how long that takes today and where delays occur. Otherwise, after implementation, it is easy to substitute a list of completed activities for an assessment of the outcome.
For Ukrainian IT companies, the ability to have this conversation with a customer has strategic value. It requires industry knowledge, a strong engineering team and a willingness to support the solution in operation. These are the foundations of trust in a technology partner.
When accepting an IT project, a leader should return to the problem that prompted it. Has duplicate data entry disappeared? Have waiting times fallen? Can the business rely on the system in its daily work? The answers should determine whether the effort invested has been worthwhile.
Reference on the capabilities and limitations of AI coding assistants: GitHub Docs: capabilities, limitations and validation of GitHub Copilot suggestions.
The Association’s work in this area: Software Ukraine Digitalisation Committee.