Digital transformation consulting

GitHub Copilot, Cursor, Claude Code, Windsurf and the rest - what you need to know about cost, security and compliance before your organisation commits.

A large financial institution has 50-200 processes that could be digitalised, and every department considers its own the most important. The order is a strategic decision - because if the first project fails, it becomes much harder to win internal support for the next one. This article offers a simple decision framework based on four factors - pain intensity, feasibility, business impact and visibility - illustrated with three concrete examples from an insurer, a bank and a leasing company.

Summary: Digital transformation is usually discussed as an abstract concept, but automating reporting is the most concrete and least risky entry point: half of finance teams still work manually, while automation can deliver up to 40% time savings and 90% fewer errors. This article explains why reporting is the ideal first step, how the cloud helps, and why this is where an organisation's cultural acceptance of digitalisation begins - not at the end of the project.

In a financial services mobile app, login is not a simple username-and-password question - PSD2 requires strong customer authentication, and it has to be built into the architecture from day one, not bolted on at the end of development. From a real project: how we implemented Keycloak-based two-factor authentication, and what we learned about balancing UX and security, biometric authentication and account recovery.

Developers don't miss the bugs in their own code because they aren't good enough - but because they test with the same mindset they used to write it. Through real project examples - an insurance mobile app, a leasing workflow and more - we show why this is a structural problem and when independent QA is not optional.

Formal Scrum often fails to deliver the expected results in large financial institutions - not because agile principles are wrong, but because the context is different. Slow decision-making, non-autonomous teams and a compliance-driven backlog are organisational problems that a change of methodology can't solve. What really works is the agile mindset - iterative delivery, transparent communication and continuous prioritisation - without the ceremonies.

Most digital transformation projects fail not for technical reasons but because business thinking, real process understanding and change management are missing. Drawing on 25 years in financial services, this article sets out the five most common patterns behind the 70% of companies that don't achieve the business results they wanted. Real examples from insurance, banking and leasing show that successful transformation is not about new systems but about well-defined business goals, an honest assessment of legacy systems, and collaboration between business and IT.

Outsourcing software testing isn't always the best option - but in four specific situations it clearly is: at project peaks when recruitment can't deliver a team in time, when domain knowledge is missing (especially on financial services projects), when you work with an external development partner and need an independent eye, and when QA isn't a core activity but quality is business-critical. This article provides a decision framework - and also tells you when NOT to outsource.

Many IT projects slip not because of technology but because nobody truly owns the business requirements. A business analyst's role isn't administrative documentation - it is preventing misunderstandings, scope creep and expensive rework. Using real project examples and market figures, this article shows that the cost of a missing BA is often several times the cost of bringing one in.

Most legacy modernisation projects fail not for technical reasons but because they try to solve the wrong problem. Scope often follows the logic of the existing system rather than business value, the business isn't involved as a real partner, and the human factor is neglected. The key to success is a value-driven approach: fast, tangible business results, incremental modernisation (e.g. API encapsulation), and deliberate organisational and operational change management.

We would be outraged if our fridge needed repairing every day... yet our software receives patches and fixes daily. Is software quality really that poor? In our view: no.

Scope creep is not a single big disaster but a slow leak - the cumulative effect of small requests that seem harmless on their own. Paradoxically, it is more dangerous in agile projects because "flexibility" disguises it: if every change counts as agile adaptation, nobody says out loud that uncontrolled growth is actually happening. This article explains who is responsible for managing it and offers a practical toolkit that works - inspired by the puppy-turned-seven-headed-monster meme.

A legacy system is not a dirty word - it carries value. Four situations where modernisation isn't worth it: when you don't know exactly what the system does, when IT fashion drives the decision, when you lack the in-house skills for the transition, and when a deadline is forcing the decision. And four clear signs that you must modernise after all - with a decision framework.

Scrum creates value in iterations, Kanban in a continuous flow - but in financial services organisations you rarely have to choose: development teams work best with Scrum, operations and BA/SA teams with Kanban. A four-question decision framework helps you find which methodology fits your project - and when neither is the right answer.

Most digitalisation projects fail because they are treated as IT projects, when in reality they are about organisational change. Three missing roles cause most failures: the business process owner, the business analyst who translates between IT and the business, and the person responsible for change management. As long as the business remains a passive recipient, even the best technology won't bring real change.

This article explains why many requirements and functional specifications don't work in practice, even when they are professionally sound. From an experienced business analyst's perspective, it sets out five typical signs that a specification isn't being read or is being misunderstood. The main message: a specification is not just a document but a communication tool - and its quality directly affects the success of IT projects.

Does your project need a business analyst or a product owner? When do you need a BA, when a PO, and when both? How do the two roles differ? This article answers these questions.

How long does a business analyst's work last? When can a BA say the job is done? Three behavioural signs that show a BA is really working effectively.

COVID brought huge changes to the project management methods we need: shifting team dynamics, a new toolset, different stakeholder management - and a look ahead at what is still to change. This article explores these questions.