MSP project prioritization matrix: choose what starts next
An MSP project prioritization matrix should tell the client which work can start, which work needs discovery, and what they are choosing to leave exposed.
A ranked wishlist gets you partway there. The highest-scoring project can still need a site survey, a client approver, or the same engineer already booked on a migration. Giving it a red cell does not create a second engineer.
Use this worksheet when you have assessment findings and a client roadmap, but too many projects competing for the next delivery window. It is written for the vCIO or account lead who has to defend the sequence to both the client owner and the MSP's delivery lead.
Put commitments and missing evidence ahead of the score
Separate urgent response work from roadmap planning. An active incident follows your response process. A confirmed contractual or regulatory deadline needs its own escalation and accountable decision. Neither should disappear into an average score.
For the remaining projects, check these gates before ranking:
| Gate | Question to answer | If the answer is missing |
|---|---|---|
| Evidence | Which current client finding or business request justifies the work? | Validate the finding before recommending a project. |
| Obligation | Is there a confirmed deadline, commitment, or unacceptable exposure? | Confirm the obligation and escalate it to the responsible owner. |
| Dependency | What must finish before implementation can start? | Separate the prerequisite or discovery task from implementation. |
| Authority | Who can approve the client spend and operational disruption? | Assign the approver and decision date. |
| Deliverability | Do the required skills, client availability, and change window exist? | Move the delivery window or resolve the capacity gap. |
A blank field means there is still a decision to make. Leave the project in discovery or blocked status rather than manufacturing a precise rank.
For security-related work, NIST's CSF 2.0 Organizational Profiles provide a current-versus-target comparison to identify and analyze gaps. Use that evidence when a security finding competes for roadmap attention. The worksheet below is our practical planning method, not a NIST scoring system or a compliance determination.
Use three anchored scores
Score projects that have enough evidence to compare. Keep the source note beside each score so the owner can challenge the assumption without arguing over a color.
| Factor | 1 | 2 | 3 |
|---|---|---|---|
| Business consequence | Convenience improvement with a workable alternative | Recurring operational friction affecting a named team | Material impact on an agreed critical business activity |
| Timing pressure | No confirmed near-term trigger | Useful in the next planning cycle | A documented event or deadline makes the next window important |
| Evidence confidence | Plausible need, but important facts remain unknown | Current evidence supports the need; some scope remains open | Finding and proposed outcome are validated with the responsible people |
Add the three values for a discussion score. A higher total gets attention earlier among comparable projects. It does not authorize a purchase, accept a risk, or override a dependency.
Use confidence honestly. A major suspected issue can need immediate investigation even with a low confidence score. Put that investigation in the queue rather than letting uncertainty push the entire concern to the bottom.
Keep delivery effort outside the score. Record it as a separate constraint. Dividing value by hours can make a small cosmetic job look better than a prerequisite that unlocks critical work. A short job still needs a reason to exist.
Copy the MSP project prioritization worksheet
Use one row per implementable outcome. Split discovery from implementation when they have different approvals or evidence requirements.
Client and planning window:
Client decision owner:
MSP advisory owner:
Delivery lead:
Available delivery capacity by required skill:
Source records and review date:
Project / outcome:
Evidence and source record:
Business consequence of waiting:
Confirmed obligation or deadline:
Business consequence score (1-3) and reason:
Timing pressure score (1-3) and reason:
Evidence confidence score (1-3) and reason:
Discussion score:
Prerequisite and its owner:
Required skill and delivery effort:
Client availability / change window:
Spend approval and scope status:
Decision: implement / discover / schedule / defer / escalate
Decision owner and decision date:
Residual exposure while waiting:
Temporary measure, if applicable:
Revisit date or trigger:
Next action and owner:
Link the evidence to the relevant Connectwise Manage client, opportunity, or project record where your team keeps it. Keep sensitive findings in the controlled client record rather than copying tenant details into a broadly shared planning sheet.
The MSP IT budget template supplies the cost and funding view. This matrix supplies the sequence and the conditions for starting. A funded line can remain blocked; a discovery task can be ready before the larger project has a final price.
Worked example: the biggest score cannot start yet
This is a fictional planning exercise. The scores and hours demonstrate the worksheet; they are not customer results, benchmarks, or recommended delivery estimates.
A client has four proposed outcomes. For this simplified example, one delivery team has 40 hours available in the planning window after its existing commitments and contingency allowance. Treat those hours as interchangeable only for this exercise. In a real plan, separate specialist capacity, procurement lead time, and client change windows.
| Proposed outcome | Consequence | Timing | Confidence | Total | Delivery condition |
|---|---|---|---|---|---|
| Remove confirmed stale privileged access | 3 | 3 | 3 | 9 | Client has approved the remediation scope; delivery lead allows 12 hours. |
| Replace Wi-Fi for an office move | 3 | 3 | 2 | 8 | An 8-hour survey must validate the design before the provisional 24-hour implementation can be scoped. |
| Replace a validated laptop batch | 2 | 2 | 3 | 7 | Approved device list, funding, stock, and deployment window; 20 hours allowed. |
| Redesign a client portal | 3 | 1 | 1 | 5 | Business sponsor wants it, but the workflows and acceptance conditions need discovery. |
The client has already identified access remediation as a required near-term risk response. Reserve its 12 hours before allocating discretionary work. The score documents the reasoning; the accountable risk decision sets that commitment.
The Wi-Fi implementation ranks above the laptop work, but the design is unresolved. Booking its provisional 24 hours as a fixed commitment would hide the very uncertainty the survey is supposed to remove.
A defensible allocation for this window is:
- 12 hours: approved privileged-access remediation.
- 8 hours: separately approved Wi-Fi survey with a named design output.
- 20 hours: the validated laptop deployment.
- Wi-Fi implementation: a later window, conditional on survey findings, client approval, procurement, and a confirmed delivery slot.
- Portal redesign: defer implementation. Ask the business sponsor to define the workflow problem and review discovery at the next agreed checkpoint.
The allocation uses all 40 hours available in the example. It commits no implementation time against the unvalidated Wi-Fi estimate. If the office-move deadline cannot accommodate that sequence, escalate the conflict immediately: change the scope, obtain suitable additional capacity, or move another commitment with explicit client agreement. A matrix cannot make an impossible schedule safe.
Explain the tradeoff in the QBR
Lead with the constraint and the proposed decision:
We can complete the approved access cleanup, validate the Wi-Fi design, and deploy the agreed laptops in this window. Wi-Fi implementation needs the survey result before we can commit its scope and timing. If the move date requires it sooner, we need to change the delivery plan today. The portal stays outside this window while its sponsor defines the outcome.
Then show what waiting means. Record the remaining exposure, any temporary measure, the owner, and the revisit trigger. Silence from the client is not an approval or a risk acceptance.
Keep the client's decision separate from the MSP's commercial approval. A client saying "we want the Wi-Fi project" still leaves scope, price, procurement, and scheduling to resolve. Carry the approved outcome into your quoting process with the assumptions attached.
Re-rank when the inputs change
Revisit the matrix when a prerequisite finishes, the client changes its business plan, a vendor confirms availability, a new finding changes risk, or the delivery lead loses capacity.
Do not quietly change a score to justify an already-promised date. Update the underlying evidence and show the consequence for the rest of the queue. If the new Wi-Fi design needs a different deployment window, the owner should see that before the engineer sees a calendar invitation.
For the broader account process, the client roadmap guide covers keeping the plan current between reviews. Use the matrix as a working attachment to that plan, with one advisory owner and one delivery lead agreeing on what "ready" means.
Where Scopable fits
Scopable's vCIO workflow connects client-linked QBR preparation with assessment, opportunity, agreement, and roadmap context. Use that context to review the client's priorities and carry the chosen next step into follow-up work.
The scoring method here is a worksheet your team can use independently. Your vCIO, delivery lead, and client decision owner still decide the order and confirm what can start.
To evaluate that client-review workflow with your own account, create a Scopable account.
