EXISTING ACCOUNT RESEARCH FOR SOFTWARE DEVELOPMENT & IT INTEGRATION FIRMS

The system meets the brief. The brief may no longer describe the business.

A custom system is accepted against requirements agreed at a particular time. The client's products, delivery commitments and decision rights can change without producing a new software specification.

I examine the original implementation context alongside evidence of business changes, before the team commits to a new technical discovery.

For established client relationships · One account · One written decision

WHAT COMPLETION ESTABLISHES

Technical acceptance and continued business fit are different tests.

The delivery record tells you

  • What capabilities were specified, built, integrated and accepted.
  • Which processes and stakeholders defined the requirement.
  • Which exceptions, dependencies and changes were documented during delivery.

The current business may require you to find out

  • Whether the client now makes different commercial commitments.
  • Whether work moves between teams or systems in a different sequence.
  • Whether the original data model and decision ownership still fit the operating model.

An old brief is evidence of the original scope. It is not evidence that a redesign is required. The business may need a policy change, new process controls, integration or no intervention.

THE POINT BEFORE NEW DEVELOPMENT

Establish the business question before estimating a solution.

01 / BUSINESS CHANGE

The client takes on a different kind of work.

A new product, subscription model, service commitment or geographic footprint may change the work the system is expected to support. The company announcement alone cannot establish the internal consequences.

02 / ORIGINAL ASSUMPTION

The old specification contains a boundary.

The team can identify which workflow, entity, integration or decision was designed around the prior arrangement. The question is whether that boundary is now consequential.

03 / VALIDATION

The owner of the business decision may have changed.

A delivery sponsor can explain the application but may not control cost allocation, service commitments or operations. A preliminary check identifies the question, not the authorisation for a project.

WHERE THE £50 SCREEN FITS

Use a small outside-in check only when it changes the next decision.

Useful when

  • You maintain an existing client system but receive few substantive new requests.
  • You can see a business change, but it is unclear what it means for the delivered scope.
  • Discovery would draw on expensive technical staff before the business issue is established.

Unnecessary when

  • The client already has a clear authorised requirement.
  • The question is primarily code quality, configuration, security or performance.
  • The answer requires private operating data or system access that a desk review cannot provide.

A reason to start discovery — or a reason not to.

The £50 Screen provides a bounded written judgement about one existing client, the original implementation and observable changes. It does not design the next system.

Account Screen · £50