Organize your work

• A project holds ongoing work: a client, a team, an internal area.
• An iteration is a deadline inside one project.
• An initiative is a promise that crosses projects, or that depends on something that is not a task.

See Projects and iterations and Initiatives and work items. Pick the way below that looks most like you.

One project, one deadline

The situation. One client, one project, one date: “Launch, 15 October”.

The setup.

• Project “Acme”.
• Iteration “Launch”, ending 15 October, with the tasks.
• No initiative.

If the client must sign something off, add the client as a managed member and make the sign-off a task assigned to them. It goes overdue like any task, and the iteration goes red with it.

Why. One project and one deadline is an iteration, by definition. An initiative here would be the same thing with a second name, and you would end up keeping two things in sync.

When to change. When a second project appears with a piece of the same promise, or when what can block you is a decision or a contract that no task can carry, promote the launch to an initiative. Until then, stay here.

One person watching everything

The situation. You are the delivery lead, the founder, or the consultant with a bench of subcontractors. You want to know what is slipping. Your team does not want another tool.

The setup.

• One company, Free plan, one sign-in: yours.
• Every person on the team added as a member without sign-in. Set their weekly capacity to what it really is. Record their leave.
• One project per client or per team.
• Iterations for each deadline that fits inside one project.
• An initiative for each promise that crosses projects, or that depends on something that is not a task.

Why. SRP’s picture is only right if everything is in. Members without sign-in let you model the whole team without asking anyone to adopt anything. Nobody gets an email. If the picture turns out to be useful enough that someone asks to see it, invite them then. Their history comes with them.

What to look at each morning. The dashboard. The needs-attention list shows the iterations and initiatives that are at risk or critical, with the reason. My Work Today shows what is due from you.

Agency with several clients

The situation. Six people. Fifteen client accounts. Most are retainers with a steady stream of small work. A few have a launch with a date that the client is watching.

The setup.

• One project per client: “Acme”, “Globex”. Long-lived, with the board, iterations and the client portal. The retainer work lives here.
• An internal project or two: “Legal”, “Ops”.
• Iterations inside each project for the team’s cadence.
• An initiative per client promise with a date: “Acme site relaunch, 15 October”.

Inside that initiative, work items:

• “Homepage build”, a deliverable, links four Acme tasks.
• “Copy approval from Acme”, a blocker, links nothing. There is no task anywhere for it.
• “Pick hosting provider”, a decision.
• “Cookie banner legal check”, a deliverable, links one task in the internal “Legal” project.

What you get. The Acme board is green. The initiative is at risk, because the copy approval went stale. That is the case iterations cannot see: the piece that is not a task, and the piece that lives in another project.

Client portals. Make one portal per client, scoped to that client’s project, with a visibility label such as client-visible. Apply the label to the tasks the client should see. Send the client the link and the passcode. See Set up a client portal.

Product team in GitLab or GitHub

The situation. The engineers live in GitLab or GitHub. The plan lives in SRP. Nobody wants to update two tools.

The setup.

• Connect GitLab or GitHub under Settings → Integrations. Read-only. SRP never writes to your repositories.
• One project per team: “Backend”, “Mobile”, “Marketing”.
• The engineers added as members. Most of them without sign-in. Their work reaches SRP through the links.
• An initiative per promise: “Payments v2 live by 30 November”.

Work items on that initiative link GitLab or GitHub issues and merge requests, SRP tasks from the Marketing project, and a blocker “PSP contract signed” with nothing linked. When the linked work closes or merges, SRP recomputes health on its own. See Integrations.

Why members without sign-in. The engineers need to exist in SRP as people so their load and their leave count toward capacity. They do not need an account for that. Add them as managed members, and invite the ones who want their own view later.