Hourly, project based or dedicated: choosing a Microsoft resource model

Start with the shape of the work

A queue of unpredictable support questions behaves differently from a defined portal implementation. A year-long modernization program differs again. Before asking for commercial options, look at the next meaningful block of work. How much is known? How frequently will priorities change? Are the people needed to approve decisions available? These answers determine which model is practical.

Separate uncertainty about the solution from uncertainty about demand. You may know exactly how to build a report but not how many reports the business will request. Conversely, you may have a firm deadline for an integration whose design still needs investigation. The first case needs flexible capacity planning; the second needs discovery before a reliable delivery commitment.

When the Hourly Model makes sense

Hourly work suits focused troubleshooting, architecture advice, small enhancements and intermittent specialist input. It lets you buy time against an approved task without assuming a continuous workload. For example, a team might need a Business Central support consultant to investigate recurring posting errors and document the cause before deciding whether configuration or development is required.

Control the model through priorities, time visibility and review checkpoints. Agree how estimates are approved, when the specialist should pause and what evidence accompanies completed work. Unbounded hourly work can drift when the task description is vague. The remedy is an explicit diagnostic question and a decision point, not pressure to predict every hidden problem before investigation starts.

What to clarify in an hourly arrangement

Ask how preparation, meetings, documentation, testing and handover are treated. These activities are part of useful delivery even when they do not produce visible screen changes. Define the smallest sensible work package and the method for approving additional investigation. If different people can submit tasks, nominate one person to resolve conflicting priorities.

Also distinguish a scheduled allocation from immediate availability. Purchasing a block of hours does not automatically create an emergency support service. Agree response expectations separately from effort. For occasional work, maintain an environment summary and decision history so each new request does not begin with the consultant reconstructing the same background. Continuity matters even when demand is irregular.

When Project Based delivery is appropriate

Project Based engagements work best when the outcome, boundaries and acceptance evidence are sufficiently clear. A hypothetical example is a supplier onboarding portal with defined user roles, forms, document requirements and integration behavior. A Power Pages portal consultant can help identify the dependencies that need agreement before the delivery scope becomes stable.

The model should specify deliverables rather than a collection of optimistic verbs. Identify what is included, which client inputs are required and who approves completion. Project Based does not necessarily mean every uncertainty has disappeared or that every commercial arrangement is fixed price. Confirm the actual pricing mechanism, milestones and change process in the proposal rather than inferring them from the label.

Protect a project scope from silent expansion

Changes are normal; invisible changes are the problem. A new country, interface, approval level or data source can alter testing and support requirements. Record the request, its business reason, delivery implications and decision before adding it to the baseline. This protects the client as much as the provider because tradeoffs remain visible.

Be equally explicit about dependencies. Delayed access, unavailable business reviewers and incomplete migration files affect progress even if development is on schedule. Microsoft's Dynamics 365 governance guidance emphasizes responsibilities and project controls. Translate that principle into a short dependency list with owners and dates, so commercial discussions reflect how the work actually proceeds.

When a Dedicated Resource is the better fit

Dedicated Resource arrangements can suit a sustained backlog, evolving product roadmap or long implementation program. The benefit is continuity: the specialist learns the business context and participates in recurring decisions. A Dynamics 365 Finance functional consultant may work with finance owners across several releases rather than repeatedly rejoining isolated tasks.

Continuity still requires management. Identify who sets priorities, checks quality and decides when other expertise is needed. A dedicated developer does not replace business analysis, architecture or testing simply because the same person is available regularly. Clarify expected allocation, working hours, planned absence and handover arrangements. Avoid assuming that “dedicated” means unlimited availability or exclusive access outside agreed hours.

Compare ownership, not just commercial labels

For each option, ask who is accountable for turning a business need into actionable work. In an hourly advisory assignment, the client may own the larger project. In a project engagement, delivery responsibilities should be defined around agreed outputs. In a dedicated arrangement, daily direction may sit with the client, a partner lead or an explicitly assigned manager.

Testing and release ownership need equal attention. Microsoft's Power Platform lifecycle guidance includes governance, development and maintenance. A hiring model should not leave any of those areas without an owner. The useful comparison is therefore not merely hourly versus monthly billing; it is the combination of capacity, responsibility, acceptance and operational support supplied under each arrangement.

Use a blended approach when the problem changes

Many sensible engagements evolve. A short hourly assessment can clarify a production problem. A bounded project can implement the agreed correction. A dedicated specialist can then support a continuing improvement program. This sequence is an example of matching the arrangement to the work, not a required package or a claim about Sirius Dynamics commercial terms.

Set review points before changing models. Ask whether scope is now clearer, whether demand is sustained and whether the internal team can manage a continuing resource effectively. Preserve documentation and decisions through the transition. Otherwise the apparent benefit of changing models can disappear while the next person repeats discovery or rebuilds missing operational knowledge.

Make the decision with a short readiness check

Write down your expected workload, first outcome, scope uncertainties, required expertise and available reviewers. Then compare the three models against those facts. If the work is uncertain and urgent, buy clarity first. If the outcome is defined but internal coordination is weak, make delivery management explicit. If a backlog is stable and leadership is ready, continuing capacity may be appropriate.

Review the model after actual delivery begins. Repeated idle time suggests the allocated capacity exceeds readiness. Frequent emergency requests suggest support expectations were understated. Continuous scope disputes suggest the outcome was not sufficiently defined. These are signals to adjust the arrangement, rather than reasons to assume one model is universally superior for every Microsoft project.

• Identify whether the immediate problem is missing knowledge, missing capacity or missing delivery ownership.
• Estimate the recurring workload separately from the effort required for the first assignment.
• Check that business reviewers can supply decisions at the pace the proposed model requires.
• Agree a review date when actual demand and delivery evidence can inform the next commitment.