The post has been translated automatically. Original language: Russian
Budget overruns in IT projects rarely occur suddenly. In many cases, the causes of future problems appear even before the team writes the first lines of code.
A McKinsey study conducted jointly with the University of Oxford on the basis of more than 5,400 IT projects showed that half of large IT projects with an initial budget of over $ 15 million significantly exceed the planned budget. The average cost overruns were 45%.
This problem is particularly sensitive for banking and financial projects: complex integrations, a large number of participants, regulatory requirements and the high cost of errors make changes at late stages especially expensive.
Where does the uncertainty come from?
One of the main sources is insufficiently developed requirements.
The vague task statement, lack of clear roles and areas of responsibility, undescribed integrations, unprepared regulatory requirements and lack of control points gradually turn the project into a process of constant refinement and rework.
The study also highlights unclear goals, changing requirements, technical complexity, lack of necessary competencies, and problems with project planning and management among the reasons for budget overruns.
Therefore, even before the start of development, it is important to form a clear project structure: define requirements and user scenarios, describe integrations, assign roles and access rights, fix priorities and control points.
Project management and decision-making play a separate role. When there is a transparent decision-making structure, a clear list of tasks, regular interaction of key participants and dependency control, it is easier for the team to manage changes and reduce uncertainty.
Business and system analysis are equally important. Well-developed requirements allow you to identify potential integration problems in advance and make testing more predictable. As a result, the team spends less time correcting errors caused by an ambiguous task statement.
How does this work in practice?
For example, when developing digital banking systems, it is important to separate user scenarios for the web and mobile versions in advance, work out integrations with banking systems, formalize roles and access rights, and provide for auditing and change history management.
This approach allows you to reduce the number of unexpected problems during the testing phase, reduce the amount of subsequent improvements, and stabilize the product faster.
At the same time, reducing the development time is not just a matter of increasing the number of developers. The speed depends on how well the work is organized before and during development: how clearly the minimum volume of the product is defined, priorities are correctly set, integrations are formalized, and project management is structured.
Finally
In banking development, speed is a derivative of structure.
The less uncertainty there is at the requirements stage, the fewer unexpected changes in the development process, which means the higher the predictability of deadlines and budget.
That's why working on a project doesn't start with code. It starts with how well the team understands exactly what needs to be created, why the business needs it, and how the product should work even before the first commit.
Перерасход бюджета в ИТ-проектах редко возникает внезапно. Во многих случаях причины будущих проблем появляются ещё до того, как команда пишет первые строки кода.
Исследование компании McKinsey, проведённое совместно с Оксфордским университетом на базе более 5 400 ИТ-проектов, показало: половина крупных ИТ-проектов с первоначальным бюджетом свыше 15 млн долларов существенно превышает запланированный бюджет. В среднем перерасход составил 45%.
Для банковских и финансовых проектов эта проблема особенно чувствительна: сложные интеграции, большое количество участников, регуляторные требования и высокая стоимость ошибок делают изменения на поздних этапах особенно дорогими.
Откуда появляется неопределённость?
Один из главных источников - недостаточно проработанные требования.
Размытая постановка задачи, отсутствие чётких ролей и зон ответственности, неописанные интеграции, неподготовленные регуляторные требования и отсутствие контрольных точек постепенно превращают проект в процесс постоянных уточнений и переделок.
Исследование также выделяет среди причин перерасхода бюджета неясные цели, меняющиеся требования, техническую сложность, недостаток необходимых компетенций и проблемы с планированием и управлением проектом.
Поэтому ещё до начала разработки важно сформировать понятную структуру проекта: определить требования и пользовательские сценарии, описать интеграции, распределить роли и права доступа, зафиксировать приоритеты и контрольные точки.
Отдельную роль играет управление проектом и принятие решений. Когда есть прозрачная структура принятия решений, понятный перечень задач, регулярное взаимодействие ключевых участников и контроль зависимостей, команде проще управлять изменениями и снижать неопределённость.
Не менее важен бизнес- и системный анализ. Хорошо проработанные требования позволяют заранее выявлять потенциальные проблемы с интеграциями и делают тестирование более предсказуемым. В результате команда меньше времени тратит на исправление ошибок, возникших из-за неоднозначной постановки задачи.
Как это работает на практике?
Например, при разработке систем цифрового банкинга важно заранее разделять пользовательские сценарии для веб- и мобильной версий, прорабатывать интеграции с банковскими системами, формализовать роли и права доступа, а также предусматривать аудит и ведение истории изменений.
Такой подход позволяет снизить количество неожиданных проблем на этапе тестирования, сократить объём последующих доработок и быстрее стабилизировать продукт.
При этом сокращение сроков разработки - это не просто вопрос увеличения количества разработчиков. Скорость зависит от того, насколько хорошо организована работа до и во время разработки: насколько чётко определён минимальный объём продукта, правильно расставлены приоритеты, формализованы интеграции и выстроено управление проектом.
В итоге
В банковской разработке скорость - производная от структуры.
Чем меньше неопределённости на этапе требований, тем меньше неожиданных изменений в процессе разработки, а значит, тем выше предсказуемость сроков и бюджета.
Именно поэтому работа над проектом начинается не с кода. Она начинается с того, насколько хорошо команда понимает, что именно нужно создать, зачем это нужно бизнесу и как продукт должен работать ещё до первого коммита.
Share
