Intranet requirements prioritization: MoSCoW without endless debate

An oversized intranet wishlist puts pressure on budgets, delays launch, and leaves stakeholders expecting different things. Effective intranet requirements prioritization turns that wishlist into a shared decision: what employees must be able to do at launch, what can wait, and why.

MoSCoW gives your team four categories for making those trade-offs visible. But labels alone will not stop every department from calling its requests essential. You also need clear decision rights, evidence, and a release boundary that holds when new requests arrive.

Here is how to use MoSCoW to agree on a credible minimum viable product (MVP) and keep it shippable.

In this article:

What should guide intranet requirements prioritization?
How do functional and non-functional requirements differ?
How do you apply MoSCoW to intranet features?
How can a prioritization workshop end with decisions?
What makes an intranet MVP credible and shippable?
How should you handle change requests mid-project?
What should your prioritized backlog record?

What should guide intranet requirements prioritization? {#prioritization-ground-rules}

Start with the requirements backlog you already have. Prioritization is not another discovery exercise, although it may expose gaps that need focused follow-up.

Before assigning categories, confirm five release constraints:

Audience: Who must be able to use the first release?
Outcomes: Which employee tasks or business obligations must it support?
Capacity: Who is available for implementation, content preparation, review, and testing?
Budget: What spending is approved, including integrations and launch support?
Date: Is the launch date fixed by an obligation or simply preferred?

Write these constraints at the top of the workshop brief. Otherwise, one stakeholder may prioritize for an organization-wide launch while another assumes a limited pilot.

Connect every requirement to a task or obligation. “Employees can find the current leave policy” gives the team something to evaluate. “We need a modern knowledge hub” does not.

Choose a matching success measure, such as whether employees can locate the current policy without asking HR. A measurable outcome helps distinguish necessary work from appealing extras.

Finally, name the decision-makers. The product owner decides scope within agreed constraints. The sponsor resolves trade-offs beyond that authority, such as extending the launch date or increasing the budget. Relevant security, legal, and accessibility owners confirm applicable obligations.

Seniority, enthusiasm, and repeated requests are not priority criteria. Evidence about task impact and obligations is.

How do functional and non-functional requirements differ? {#functional-and-non-functional-requirements}

Separating these requirement types prevents visible features from crowding out the conditions that make an intranet usable and safe.

Functional requirements describe what someone needs to do. Examples include:

Search for policies.
Publish an internal news article.
Update a staff profile.
Approve a document before publication.

Non-functional requirements describe constraints and measurable operating conditions. These include accessibility, response times, availability, and access protection.

A single need can involve both. Restricting a document to an authorized employee group describes behavior. The organization’s identity, session, and audit requirements constrain how that behavior is implemented.

Rewrite vague requests before prioritizing them:

Vague request	Testable requirement
“Policies should be easy to find.”	Employees in the launch audience can reach the current leave policy through the agreed policy index. HR confirms that the destination is the approved version.
“Restricted content must be secure.”	In access tests, an employee outside the authorized group cannot view the restricted document through navigation, search, or its direct URL. IT owns verification.
“The policy area must be accessible.”	Employees can navigate the policy index and open a policy using only a keyboard, with visible focus and no keyboard traps. The accessibility owner verifies this alongside the agreed accessibility checks.

These examples are individual acceptance conditions, not complete security or accessibility specifications.

Use a consistent structure: audience, task or condition, observable result, and accountable owner. For performance requirements, also specify the workload, test environment, and measurement method.

Record non-functional requirements as backlog items or shared acceptance criteria linked to affected work. Applicable obligations are not optional simply because they are less visible than a homepage feature.

How do you apply MoSCoW to intranet features? {#apply-moscow-to-intranet-features}

MoSCoW classifies requirements for a specific release. The same feature can belong in different categories depending on the audience, outcomes, and available workarounds.

Category	Meaning	Decision test
Must have	Without it, the release cannot meet a critical outcome or obligation, and no acceptable workaround exists.	Would its absence block a viable launch?
Should have	Important, but a temporary workaround makes launch viable without it.	Can the audience complete the task another acceptable way?
Could have	Useful, lower-impact work that can be removed first if capacity tightens.	Would removing it leave essential tasks intact?
Won’t have this time	Explicitly excluded from this release.	Can we document its exclusion without implying a future delivery promise?

A worked example: launching policy access

Suppose the first release must let employees find current policies while protecting restricted documents. The policy collection is small enough that a browsable index could support the launch.

Requirement	Category	Rationale
Permission-aware access to restricted policies	Must have	Unauthorized disclosure would violate the release’s access requirements. An unrestricted launch is unacceptable.
Policy search	Should have	A maintained, permission-aware index provides a temporary route to the required policies.
Personal bookmarks	Could have	Bookmarks reduce repeat navigation, but employees can still reach policies through the index.
Social communities	Won’t have this time	Communities do not support the agreed first-release policy-access outcome.

Search is a Should only if the index is an acceptable workaround. Validate that assumption with representative employees. If the collection is too large or employees cannot reliably find the right document, search may become a Must, or the release may need a smaller policy scope.

For every proposed Must, ask:

What fails without it?
Who is affected?
Why is a workaround unacceptable?

“It is important to our department” does not answer those questions.

Workarounds also have costs. If HR must answer a new queue of policy requests manually, account for that workload. A workaround is acceptable only when its owner can sustain it and it does not bypass an obligation.

How can a prioritization workshop end with decisions? {#run-a-prioritization-workshop}

The workshop should resolve disagreements, not introduce every requirement for the first time.

Send the prepared backlog in advance. Include each item’s description, evidence, rough effort estimate, dependencies, and proposed category. Ask stakeholders to classify items independently before the session so the first speaker does not set everyone else’s position.

Invite the people needed to make or validate decisions: the product owner, delivery lead, relevant business owners, IT, and employee representatives. Bring in legal, security, or accessibility owners where their obligations are affected.

Use this sequence:

Confirm the release boundary. Restate the audience, outcomes, capacity, budget, and date.
Check agreed items briefly. Confirm that apparent agreement does not hide different assumptions.
Discuss disputed items. Compare task impact, affected employees, obligations, workaround cost, effort, and dependencies.
Time-box disagreements. End each discussion with a decision or a specific evidence request.
Assign unresolved questions. Name an owner and a decision deadline.
Confirm authority. The product owner decides within the agreed boundary; the sponsor handles exceptions.

When evidence is missing, make the follow-up concrete. “Test whether employees can locate these policies through the index” is actionable. “Discuss search again” is not.

Publish a decision log after the workshop:

Decision: Policy search is a Should for the first release.
Rationale: The planned index can support the launch audience’s essential policy tasks.
Trade-off: Employees will not have keyword search at launch if capacity runs short.
Review trigger: Task testing shows the index does not support reliable policy discovery.
Decision owner: Product owner.

Keep voting advisory. A popular feature does not outrank an access obligation, and a small employee group may still have a launch-critical need.

What makes an intranet MVP credible and shippable? {#define-a-credible-intranet-mvp}

An intranet MVP is the smallest release that lets the agreed audience complete essential tasks safely and reliably. It is not a collection of partially implemented features.

Check complete task paths. For policy access, an employee must be able to:

Enter the intranet through the approved access method.
Reach the relevant policy area.
Identify the current policy.
Open it with the appropriate permissions.
Understand where to ask a question or report an outdated document.

A finished page template does not complete that path if the approved content has not been migrated. A document repository is not ready if employees cannot tell which version applies.

Validate the delivery plan with the people doing the work. Estimates must cover more than configuration and development:

Content selection, cleanup, migration, and approval.
Identity setup and other required integrations.
Navigation and access configuration.
Security, accessibility, and task testing.
Content-owner guidance and launch support.
Rework and uncertainty around untested dependencies.

Must-have work must fit available capacity with room for uncertainty. If it consumes every available hour, the plan has no protection against discoveries or rework.

When Musts do not fit, do not simply rename them Shoulds. Split broad requirements into smaller usable parts, reduce the launch audience where permissible, narrow scope, or seek approval to change the date or budget. Obligations still apply to the revised release.

MoSCoW categories also do not establish delivery order. Sequence work within each category by dependencies, risk, and task value. An uncertain identity integration may need early validation because several essential tasks depend on it.

Record release acceptance conditions and list deferred items separately. “Not in this release” is a clear boundary. “Coming in the next release” is a commitment that requires its own approval.

How should you handle change requests mid-project? {#handle-mid-project-change-requests}

Scope control should not prevent learning. It should prevent new work from entering the plan without a visible trade-off.

Ask requesters to submit a short change record:

Employee need: Who needs to do what?
Evidence: What observation, test result, or obligation supports the request?
Urgency: Why does it need to happen before launch?
Proposed priority: Which MoSCoW category applies, and why?
Consequence of waiting: What happens if it is deferred?
Possible workaround: Can the need be met temporarily another way?

The delivery team then assesses effort, dependencies, risk, acceptance conditions, cost, and launch timing. Even a small interface change can introduce content, integration, or testing work.

Route each request to an explicit outcome:

Outcome	What must be made explicit
Replace planned work	The item being removed and the effect on release outcomes.
Use agreed contingency	The capacity consumed and the uncertainty allowance that remains.
Defer the request	The reason and the condition for reconsideration.
Change release constraints	Sponsor approval for the revised scope, budget, capacity, or date.

Example: a late personalization request

A stakeholder asks for department-specific homepage content shortly before launch.

First, test whether personalization is necessary for an agreed critical outcome. If employees can still reach their policies through the planned navigation, it may not justify changing the release.

The product owner can defer it or identify work it would replace. Approval should include the full effort: department data, content rules, fallback behavior, access checks, and testing. Personalization itself must not be treated as a substitute for access controls.

A newly discovered legal or security obligation is different. It may require immediate replanning or block launch. But it still has an impact that must be estimated and communicated; it is not work the team can automatically absorb.

After every approved change, update the backlog and decision log. Tell stakeholders what changed, what remains uncertain, and what will no longer be delivered.

What should your prioritized backlog record? {#prioritized-backlog-checklist}

Your backlog should let someone understand a priority decision without attending the original meeting. Use these fields in your existing planning tool or spreadsheet.

Field	What to record
Requirement ID	A stable reference used in decisions, tests, and change requests.
Employee task	The audience, task, and intended result, or the obligation being met.
Requirement type	Functional or non-functional, with links between related items.
Acceptance conditions	Observable pass/fail conditions and any shared criteria that apply.
MoSCoW category	Must, Should, Could, or Won’t have this time.
Rationale	Evidence, task impact, and why a workaround is acceptable or unacceptable.
Effort estimate	The team’s estimate, assumptions, and uncertainty.
Dependencies	Required content, systems, approvals, people, or preceding work.
Requirement owner	The person accountable for clarifying the need and confirming acceptance.
Decision owner	The person authorized to approve the priority or scope change.
Target release	The approved release, or “unassigned” if future delivery is not committed.
Review trigger	The evidence, event, or checkpoint that could change the decision.

Before approving the release scope, run four checks:

Every Must has a defensible reason, including why no acceptable workaround exists.
Essential task paths are complete, including content, permissions, and testing.
Estimated effort fits capacity, with an explicit allowance for uncertainty.
Exclusions are visible, including their consequences and any temporary workarounds.

Review priorities at agreed planning checkpoints and when material evidence changes. Do not reopen every decision in every status meeting.

Keep the published release scope accessible to all stakeholders. It should be the shared reference for delivery expectations, not a private document that differs from what departments have been promised.

Ready to start?

Apply the backlog checklist to your current intranet wishlist. Start by challenging every Must, identifying incomplete employee task paths, and making first-release exclusions visible.

If you want a second perspective on that scope, discuss it with the Open Intranet team. Bring your audience, constraints, and prioritized backlog so the conversation can focus on what your first release needs to deliver and what can safely wait.