APPROACH / ENGAGEMENTS
Technology project engagement models matched to the work.
A defined implementation, continuing maintenance and recurring production work need different working arrangements. The engagement model identifies what is being delivered, what the client provides and how completion or continuing responsibility will be assessed.
Choose the structure around the outcome and uncertainty, not a label that sounds comprehensive. No model here implies unlimited work, automatic availability or unagreed support coverage.
Use a project scope for a bounded result.
A project implementation addresses a defined outcome, such as an intake workflow or a client workspace. Its scope identifies deliverables, required client inputs, integrations, exclusions and acceptance criteria. Discovery may be needed before that boundary can be specified responsibly.
The client supplies an authorized decision owner and the agreed information or access. Delivery work implements and validates the scoped result. Completion is evaluated against the acceptance criteria; requests that change the result need a recorded scope decision.
Use maintenance for an identified system and defined responsibilities.
Maintenance concerns an existing implementation. The starting point is a system inventory, known condition, access boundary and a description of the continuing work. Corrective investigation, dependency review and operational checks are distinct tasks that need explicit coverage.
The arrangement identifies who reports issues, who approves changes and how responsibilities are reviewed. Enhancements, third-party outages and unsupported components may require separate decisions rather than being treated as interchangeable maintenance work.
Use recurring work for repeatable outputs and review cycles.
A recurring service can support an agreed sequence of reporting, content, documentation or development tasks. Define the input required for each cycle, its responsible owner, the output to be reviewed and the acceptance or revision process.
For example, a recurring reporting workflow needs a data cutoff, validated sources, an approved metric definition and a reviewer. If inputs are incomplete, the output must identify the limitation or wait for a defined decision; recurrence alone does not make the source reliable.
Match uncertainty to the next responsible commitment.
Bring the intended outcome, current systems, unresolved questions and the working relationship you need. A largely unknown problem may call for discovery before implementation. A stable system with defined upkeep may suit continuing maintenance. Repeated outputs with known inputs may suit a recurring scope.
Review the model when the underlying work changes. A maintenance request can become a substantial redesign; a one-time report can reveal a need for a recurring workflow. Establish the new boundary instead of allowing the original arrangement to expand by assumption.
Can discovery be the first step without committing to a full build?
A bounded discovery scope can establish requirements and feasibility before a larger implementation decision. Its deliverables and acceptance need to be clear in their own right rather than treated as a vague preliminary conversation.
No. Deliverables, commercial terms and applicable service expectations are established for the specific engagement. The descriptions explain the kinds of responsibility, not a published package or price list.
Are prices or support levels fixed by these models?
No. Work must address a legitimate need, be feasible to deliver responsibly and create value for society. A commercial opportunity is not sufficient reason to accept a harmful or exploitative application.
Is every proposed project accepted?
Technology Solutions & Business Services