The choice looked like continue or cancel. The useful answer crossed the silos.

A financial-information service had become a troubled investment: a multiyear, multimillion-dollar over-budget development effort supporting a substantial information business.

Howard Pearlmutter's remit was to investigate and recommend cancellation, disposition, or resuscitation.

The question could not be answered by looking only at money already spent or only at the code. It required understanding what existed, how it worked, who needed it, and what useful future it could have.

One system, several different accounts of value.

The service handled more than seventy million documents on a pay-per-use basis. It was also part of a transition from a long-established mainframe operation.

There was technical architecture to examine, including large C++ and Java codebases and parallel-processing search behavior. There were market requirements, stakeholder needs, and multiple-team perspectives.

Each view carried information relevant to the future of the investment. A narrow assessment could have missed the relationship among them.

Howard's investigation connected quantitative code analysis, structural analysis of search throughput, market analysis, and qualitative examination of team and individual perspectives.

The review opened a different route.

Howard offered a solution that preserved investment and opened opportunities beyond those previously considered.

The rearchitecture direction connected several transitions: traditional online services toward web-based commerce; heavyweight interfaces toward lighter ones; platform dependence toward greater independence; and a changing role for Java in the application architecture.

The investigation, recommendation, and rearchitecture planning were accomplished in one week. The service went on to a successful launch.

The significance is the combined examination. Technical details changed the business options, and business understanding changed which technical possibilities mattered.

A rescue question can hide an opportunity question.

Under pressure, an organization may frame a project mainly through the original promise and the cost of failing to deliver it. That can make the useful asset harder to see.

What capability has already been created? Which part remains sound? Which market assumption has changed? Could a different architecture preserve more value than a broad replacement? Is an earlier constraint still the constraint that matters?

These are questions to investigate. They do not imply that every troubled project should continue.

The value of an independent assessment is a more informed set of alternatives, including a responsible stop when appropriate.

Practical breadth changed the available answer.

Howard could examine the implementation and discuss the market purpose. He could follow a search-throughput question into architecture and a stakeholder disagreement into requirements. That reduced the need to pass the central question among separate specialties without anyone holding the relationships together.

This is one reason a multi-disciplinary technical adviser can be useful to founders, enterprises, and investment stakeholders evaluating software as an asset.

The contribution can remain bounded. A review should leave the organization with reasoning it can use, whether the next work stays internal, goes to another partner, or includes further participation from Howard.

Explore legacy and new capability, the work behind a specification, or an independent review. Begin with the question whose answer might change the next commitment.