Case study · Business analysis

When the business side is involved too late

An anonymised case study about a technical-looking project that reached the application team too late and turned into a major user flow redesign under delivery pressure.

In short

The project was treated as technical, but the impact was business-facing.

The affected team was involved only after the project had already started. What looked like a backend / data change turned into a major redesign of the application flow.

Late involvement

The impacted application team learned about the work only after the project had already contacted other systems and started moving toward implementation.

Wrong sizing

The project did not know the existing application well enough to estimate the work. A one-screen flow became roughly a 5–6 screen redesign.

Outcome

The delivery was completed on time and worked well, but only through heavy coordination, fast analysis and unnecessary pressure on the team.

Context

A technical change can still rewrite the user journey.

The project started around a new data and integration layer behind an existing internal application. Because the focus appeared technical, the work was initially handled mainly through technical roles and architecture discussions.

The affected business and application-knowledge team was involved too late. By then the project already expected development work, even though the user flow, screens, fields and business rules had not yet been analysed from the application side.

The successful delivery did not mean the start was healthy. It only meant the team absorbed the cost of a late impact assessment.

Diagnosis

Three places where the project setup created unnecessary risk.

The issue was not that a new data layer was needed. The issue was that front-end, business flow and team capacity impacts were discovered too late.

Impact assessment

The project did not identify all affected teams and application responsibilities early enough.

Original workflow

the project started with a technical / backend focus;
other systems were contacted before the application impact was clear;
the business / application team was involved only when implementation was already expected;
no prior analysis request or capacity request was made for that team.

Why this was a problem

the project underestimated the front-end and business flow impact;
people who knew the application were not involved in sizing;
the team had to analyse and design under time pressure;
planning started from an incomplete view of the affected system landscape.

Recommendation

run an affected-system and affected-team assessment before project start;
include application owners and business analysts early;
separate “technical component change” from “user flow impact”;
confirm whether screens, rules or operational processes are affected.

Business analysis

The work required much more than adding fields. The application flow had to be rethought.

Original workflow

no user flow had been described before the team was involved;
new screens, fields and rules had to be designed quickly;
the original one-screen operation became a multi-screen flow;
the affected team had to build the analysis almost from scratch.

Why this was a problem

the size of the work was discovered too late;
the project treated the change as smaller than it really was;
the team had to design a near-complete application flow under delivery pressure;
missing analysis could have led to wrong or incomplete implementation.

Recommendation

bring in business analysis before implementation expectations are set;
map screens, fields, validations and edge cases early;
define MVP slices if the flow grows beyond the original assumption;
make acceptance criteria visible before development starts.

Waterfall and agile alignment

The wider project worked in a more waterfall-like mode, while the delivery team shipped in two-week agile cycles.

Original workflow

the project expected fast dedicated delivery from the affected team;
the team was already working in two-week cycles with other responsibilities;
the wider project did not initially accept the team’s delivery cadence;
capacity and sequencing had to be negotiated after the project had already started.

Why this was a problem

the project assumed capacity that was not actually reserved;
ongoing work could have been disrupted;
the delivery team had to absorb pressure created by late planning;
methodology mismatch became a scheduling and expectation problem.

Recommendation

define the interface between waterfall planning and agile delivery early;
reserve capacity based on real team cadence;
agree how scope will be sliced into increments;
make dependencies visible before timelines are committed.

Outcome

It was delivered successfully — but the risk should not have been pushed onto the team.

The application was completed by the expected date and worked without major issues. The problem is that this success required fast recovery work that could have been avoided with earlier involvement.

1 → 5–6

Screen growth

A one-screen application flow became a multi-screen solution.

late

Business analysis

User flow, fields and rules had to be designed after the project had already started.

2-week

Delivery cadence

The team’s agile cadence had to be protected and negotiated.

on time

Delivery

The work was eventually delivered, but at the cost of unnecessary pressure and coordination effort.

Lesson learned

Early impact assessment is not administration. It is risk reduction.

When a project affects an application, the team that knows that application must be involved before scope, timelines and assumptions harden. Otherwise the real work size appears too late.

A technical-looking project can still require product thinking, business analysis, screen design, user flow decisions and delivery negotiation. If these are discovered only during implementation, the team may still succeed — but the organisation pays for it in pressure, rework and avoidable risk.