Start with a conversation
If uncertainty and delivery are intertwined, describe the current state and desired change. Model selection can follow initial clarification rather than guesswork.
How we work together
Choose the working model that fits the decision and the outcome
The technical service defines what we help with. The engagement model defines how scope, ownership, collaboration and change are organized between your team and XIVTech.
Three questions organize the choice
- 1. Scope: Is the work a question to investigate or an outcome to deliver?
- 2. Ownership: Who makes the decisions and who owns implementation?
- 3. Change: How will new evidence or requirements affect the work?
Available engagement models
Two ways to organize the work
Both models can connect to several XIVTech services. What changes is the starting point, the allocation of responsibility and how the work moves forward.
Client decision ownership
Consulting
Collaborative technical assessment, direction and agreed hands-on work, with the client retaining final decision ownership.
- Scope
- Question-led and adaptable
- Best fit
- Direction under uncertainty
XIVTech owns agreed delivery
Project Delivery
XIVTech plans and implements an agreed project outcome, with explicit dependencies, review, acceptance and handoff.
- Scope
- Outcome-led and bounded
- Best fit
- A result ready to be delivered
Compare the models
The ownership differences at a glance
The comparison uses one canonical record shared with every child page. It contains no pricing, capacity or billing claims.
| Decision dimension | Consulting | Project Delivery |
|---|---|---|
| Scope shapeHow clearly the work can be bounded at the start and where detailed priorities are established. | Question-led and adaptable The engagement starts with a decision, constraint or area to investigate; findings can refine the agreed next work. | Outcome-led and bounded The desired result, delivery boundary, dependencies and review expectations are clarified before implementation. |
| Delivery ownershipWho owns the main technical direction and responsibility for organizing the work toward the intended result. | Client decision ownership XIVTech investigates and recommends; designated client owners make the final business and risk decisions. | XIVTech owns agreed delivery XIVTech organizes and completes the technical scope while the client owns its requirements, inputs and approvals. |
| CollaborationHow XIVTech and the client team combine context, decisions, implementation and review during the engagement. | Review and work alongside Specialist guidance and selected implementation happen with the client team and its system context. | Delivery with review points XIVTech leads implementation; the client supplies context, decisions, dependencies and planned review. |
| Handling changeHow new evidence, requirements or priorities are reviewed when they affect the original understanding of the work. | Reframe from evidence New findings are reviewed for their effect on the question, priorities and any hands-on implementation scope. | Explicit scope decision Material requirement or dependency changes are assessed before the agreed plan or boundary changes. |
| Work continuityWhether continuity follows a question, a defined outcome or a client-directed need for ongoing contribution. | Follows the decision need Work continues through the agreed investigation, recommendation, validation or implementation need. | Follows the project outcome Work proceeds through shaping, implementation, review and handoff of the defined result. |
| Best fitThe buyer situation in which the model's ownership and scope structure are most useful. | Direction under uncertainty Best when a team needs technical judgment, an independent review or a practical path before committing to delivery. | A result ready to be delivered Best when a meaningful outcome can be bounded and the buyer wants clear responsibility for implementation. |
How to choose
Start with what your team needs to resolve
A model is useful only when it reflects the real uncertainty, desired outcome and ownership your team can support.
Start with the uncertainty
Choose Consulting when the immediate need is to understand a system, evaluate options or make a consequential technical decision.
Start with the outcome
Choose Project Delivery when the result can be bounded and you want XIVTech to own implementation of the agreed technical scope.
Responsibilities
What shifts between the models
Technical quality is not the only difference. The practical choice is who investigates, who decides, who delivers and who supplies the dependencies.
Consulting
Consulting works when advice, access, implementation and approval are not blurred. These boundaries are clarified for the actual engagement.
XIVTech responsibilities
Technical investigation · Options and recommendations · Agreed hands-on work
Client responsibilities
Context and access · Decisions and priorities · Adoption and internal alignment
Shared responsibilities
Define useful evidence · Review decisions and changes
Project Delivery
XIVTech owns the agreed implementation, while the client owns the business and organizational inputs only it can provide. Shared decisions connect the two.
XIVTech responsibilities
Delivery planning · Scoped implementation · Delivery documentation and handoff
Client responsibilities
Requirements and priorities · Access and dependencies · Review and acceptance
Shared responsibilities
Scope clarity · Change decisions · Handoff readiness
The right shape can become clearer as the work becomes clearer
A team may begin with Consulting because the direction, risks or delivery boundary are uncertain. Once the decision is made and an outcome can be bounded, a separately agreed Project Delivery engagement may become appropriate.
A change in understanding does not silently switch the model or its terms. Both teams review what changed, which responsibilities move, what remains in scope and what new agreement is required before work continues in a different shape.
- Use evidence from discovery to refine the work, not to hide an expanding scope.
- Reconfirm ownership whenever the engagement moves from advice to delivery.
- Make handoff, continuation and unresolved risks explicit at each transition.
Shared expectations
The model changes; working clarity should not
These principles apply to every published model without claiming a particular commercial term, cadence or staffing promise.
Scope and boundaries are explicit
The engagement starts with a shared understanding of the need, included work, exclusions and important assumptions.
Responsibilities have named owners
XIVTech, client and shared responsibilities are separated so access, decisions, implementation and review do not fall between teams.
Progress and blockers stay visible
The working rhythm makes completed work, open questions, dependencies and decisions understandable to the responsible stakeholders.
Changes are discussed before assumptions spread
New evidence and requirements are assessed for their impact on priorities, boundaries and ownership before the plan changes.
What we can work on
Connect the engagement shape to a technical service
Services explain the capability and problem space. Engagement Models explain how the work and responsibilities are organized.
Common questions
Choosing an engagement model
These answers focus on the shape of the work. Commercial facts are discussed only when they are confirmed for a specific engagement.
What is the difference between a service and an engagement model?
A service describes the technical problem space, such as cloud, DevOps, Kubernetes or product engineering. An engagement model describes how XIVTech and the client divide scope, delivery ownership, decisions and change while doing that work.
How do we choose between Consulting and Project Delivery?
Choose Consulting when the key need is investigation, direction or decision support. Choose Project Delivery when a meaningful outcome can be bounded and you want XIVTech to own delivery of the agreed implementation scope.
Can an engagement include advice and hands-on work?
Yes. Consulting can include agreed implementation or validation, while Project Delivery includes the technical work required for its agreed outcome. The difference is the primary ownership and scope shape, not whether engineers touch the system.
What happens when discovery changes the original plan?
Both teams review the evidence and its effect on priorities, scope and responsibilities. A material change is made explicit before different work or ownership is assumed.
Do these pages promise pricing, availability or a minimum commitment?
No. The public model descriptions contain no hourly rates, billing periods, staffing availability, minimum commitments or similar commercial promises. Specific terms belong to an approved engagement discussion.
What should we bring to the first conversation?
Bring the current system or delivery context, the change or decision you need, known constraints, important stakeholders and any timing or dependency information that affects the work.
Discuss the fit
Discuss the work before forcing it into a model
Tell us what needs to change, what is uncertain and which responsibilities your team wants to keep. We can use that context to discuss an appropriate engagement shape.