01
Describe the problem through the work.
A request to ‘integrate our data’ does not yet identify the platform or configuration needed. Explain who reads which material, where the work becomes difficult, and what the next person needs to receive. Following the current task makes the problem concrete.
Calamophyton's adoption review starts with the current problem, the work it affects, the intended result, and the timeframe. The task can be described before a platform is selected. HARBINGER, PÓLYA, and RAIFFA serve distinct purposes, so adopting all three is not an assumption of every review.
02
Define the result alongside its operating conditions.
The implementation work for the same capability can vary with the data and systems connected to it. Examine where people work, the sources and access conditions, the existing systems, and the roles and approval boundaries. The result and the environment needed to produce it belong in the same discussion.
For HARBINGER, shared platform capabilities, domain rules, customer data and workflows, and deployment environments are separate layers. Platform material explains the common capabilities; an actual application review defines the configuration to select. Listing an environment as a requirement does not by itself establish support for it.
03
A review needs a result to examine.
Define what would show that the work has improved. If the aim is to review changes around the same subject, opening a screen is different from a person finding and understanding the relevant change. Expressing the result as a user action makes the evaluation question clearer.
Aligning the timeframe, mandatory requirements, and intended result is part of the business discussion. Distinguish software capabilities from responsibilities for configuration, integration, training, and operational support. Actual provision and terms are examined within the scope of the particular project.