Three routes, from top to bottom: configure, buy and build. Compare each against the same requirement.
Start with the Work That Must Happen
In this example, a team is preparing a confidential supplier transition. A project owner holds the complete record. An external adviser reviews a defined document set. An operator coordinates tasks without needing the commercial terms. The team already uses a shared workspace, but invitations are managed informally and closing a project does not trigger an access review.
The first temptation is to commission a portal. Yet the immediate failure is unclear permission ownership. Building a new interface would leave that problem intact unless the team also decides who approves access and when the approval ends.
Write the Conditions before Comparing Options
For this example, the owner must approve the adviser's document set, the operator must work from a separate task record, and project closure must prompt a review of continuing access. A replacement operator must be able to follow documented instructions. Required records must be recoverable and exportable.
Distinguish a control enforced by the system from a procedure someone must perform. If closure depends on a named person removing access, that dependency belongs in the decision. The team can accept it, provide a reliable operating arrangement or require technical enforcement.
Compare the Complete Arrangement
Use this matrix as a worksheet. Each cell is a question to answer for this workflow.
Scroll horizontally to compare every column.
| Decision | Configure Existing Tools | Buy a Service | Build a System |
|---|---|---|---|
| Requirement Fit | Can separate spaces satisfy the workflow? | Can the service demonstrate the required sequence? | Can the necessary behavior be specified precisely? |
| Access Control | Check actual sharing and closure settings. | Inspect roles, exceptions and revocation behavior. | Design and test enforcement at each boundary. |
| Maintenance | Name the configuration owner. | Review administration and provider dependencies. | Fund updates and assign a maintainer. |
| Recovery | Rehearse restoration and owner replacement. | Verify available recovery and export paths. | Implement and rehearse restoration. |
| Exit Cost | Check what existing formats preserve. | Inspect export completeness and contract terms. | Document formats, deployment and dependencies. |
| Evidence Needed | Test a representative configured project. | Evaluate the service with the actual scenarios. | Review the design and test the delivered system. |
Let the Missing Requirement Decide
Suppose the existing workspace can separate the document sets and the owner can reliably conduct the closure review. Configuration is the provisional choice. It addresses the defined problem while keeping operation within an arrangement the team already understands. Confirm that conclusion with a representative project, including an adviser departure and recovery by another authorized person.
The decision changes if access must end automatically at a project event and the configured arrangement cannot enforce that condition. First inspect whether a suitable service can do so. Development becomes a candidate when the important gap remains and its maintenance can be supported.
Custom code adds dependencies, update work and places where authorization can fail. A purchased service also needs configuration and review. Neither route transfers the responsibility for understanding the requirement or checking the actual behavior.
Record What Would Change the Choice
Write one sentence for the required outcome, one for the unacceptable failure and one for the person responsible for operation. Record the preferred option, its unresolved assumptions and the evidence needed before commitment. Include the recovery and exit conditions.
Revisit that decision when the workflow, information sensitivity or available support changes. The useful output is an arrangement the team can operate and verify, with a clear reason for every important added component.