Projects and tasks in an intranet: where to stop and what not to touch

The project module inside an intranet is one of the most misunderstood components. The request usually arrives as "we need a project management tool"; the real need is normally different: seeing where work stands.

What it should and shouldn't do

A software team needs a sprint board, dependency graphs and capacity planning; a dedicated tool does that, and the intranet shouldn't imitate it.

The need the intranet's project module actually answers is this: making cross-department, mid-sized, multi-month work visible. Opening a new branch, rolling out a system, preparing for an annual audit, running a campaign.

What those pieces of work have in common is that they don't belong to a single team, and nobody wants to log into a specialist tool for them.

Tasks: owner and deadline

The core of the module is plain: tasks under a project, each with an owner and a deadline. Without those three the list becomes a to-do notebook nobody owns.

The owner being a person is critical; not "Marketing" but a named individual. Collective responsibility turns into no responsibility in projects too — we covered the same principle in our operations article.

Status: few stages

A seven-state workflow looks detailed on paper; in practice nobody picks the right stage. Three states cover most work: to do, in progress, done.

A fourth stage helps and is usually skipped: blocked. When a task is stuck on someone else's work, making that visible is the only thing that shows a project's real state. Tasks sitting as "in progress" that have actually been waiting three weeks make project reports dishonest.

Visibility: who should see what?

Making projects open to the whole organisation by default is the right choice in most companies. Seeing what another team is working on surfaces duplicated work and collisions early.

The exceptions are clear and should stay limited: acquisition discussions, restructuring work, personnel processes. Those projects need to be restricted, and the restriction belongs in the data layer — hiding in the interface isn't enough.

Notification balance

Project modules are eager to generate notifications: task assigned, status changed, comment added, deadline approaching. Sending all of them doesn't raise engagement; it leads to notifications being switched off entirely.

The simplification that works: notify a person about their own tasks, and the project owner about blocked tasks. The rest can stay in the feed. We cover the general dynamic in our engagement article.

Project templates

Recurring projects can become templates: every new branch opening goes through similar steps, every annual audit needs similar preparation. A project generated from a template saves time and prevents forgotten steps.

The template has to be kept alive: if a new step discovered during one run isn't written back, the third project forgets the same thing again.

Requests versus tasks

Two concepts that are often confused. A request is a submission from a person to a department and awaits approval (leave, expenses, IT support). A task is work assigned to a person and awaits completion.

Trying to collect both in one list breaks the function of each. We cover the request flow in a separate article and work sent to the field in our field tasks article.

Living alongside a dedicated tool

If the company already has a project tool, the intranet module shouldn't try to replace it — that creates a pointless conflict. The healthy division: detailed execution in the specialist tool, organisational visibility in the intranet. The project's summary, owner, status and milestones live in the intranet; the daily work lives in its own tool.

Measurement

• Overdue task rate — the share of open tasks past their deadline.
• Time spent blocked — the average duration in the "blocked" state; it points straight at bottlenecks.
• Currency — the number of active projects untouched in the last 14 days.

The last is the most honest indicator: an un-updated project record doesn't say the project has stopped, it says the record has been abandoned — and abandoned records lower the credibility of the whole module.