01
Discovery and evidence
Start with the systems, users, sites and business tasks involved. Existing records, usage information and conversations with application owners provide a stronger basis than assumptions. The scope should distinguish a preliminary discussion from a deeper technical assessment requiring access or measurement. A useful technical review distinguishes symptoms, evidence and hypotheses. For a slow application, that could mean recording when delays occur and examining client, network, storage and application dependencies, rather than concluding that a new internet connection must be the answer. Findings should make clear which causes were tested and which remain assumptions.
02
Design and responsibility boundaries
Review how a proposal interacts with existing suppliers and internal staff. Identify account ownership, support boundaries and the approvals needed for change. A good design explains interfaces and responsibilities as well as the selected components, particularly where several parties will contribute. A design decision has consequences for the operating model. Moving a system to hosting changes access paths and management boundaries; introducing a second connection changes routing and testing requirements. Recording these dependencies helps compare options beyond their purchase prices or headline specifications.
03
Implementation and acceptance
Agree what a successful result looks like before work begins. Define tests based on real tasks, an appropriate change window and the information needed at handover. A written recommendation, a migration plan and a managed implementation are different deliverables and should be scoped accordingly. Acceptance criteria describe observable results. A branch-opening project might require authorised users to reach defined applications, make representative calls and use agreed wireless areas. These tests are more useful than a vague requirement that the new setup works, because the business and delivery specialists can evaluate the same outcome.