IT Project Template
A board for internal IT work broadly: vendor rollouts, system upgrades, access requests, where tickets arrive from every department, not from one product roadmap.
One board for a laptop request and a six-month vendor rollout: different weight, same intake.
Why IT boards end up as a dumping ground
Internal IT sits at an odd intersection: it runs real projects with timelines, but it also fields one-off requests from every department, and most templates only handle one of those well. A project-management template ignores the request stream; a helpdesk ticketing tool ignores the project. IT ends up running both in parallel, informally, in whatever gaps the formal tools leave.
Requests and projects compete for the same space. A password reset and a six-month vendor migration end up as visually identical cards, so the migration gets no more attention than the reset until it's already late. The board has no way to signal that one of these matters far more than the other.
Approval isn't tracked, so budget-bearing work starts without it. A vendor tool gets purchased and rolled out before anyone confirmed the spend was approved, because there was no step on the board that made approval a prerequisite, and finance finds out about the line item after the invoice arrives.
Nobody outside IT can see what IT is doing. Other departments only find out a project is late when they need it and it isn't there, because the board, if one exists, was never visible to them in the first place. IT gets a reputation for being slow that's really a reputation for being invisible.
Everything looks urgent because nothing is prioritized against anything else. Without a shared view of the full workload, every request arrives as if it's the only thing on IT's plate, and IT either drops what it's doing to accommodate it or gets blamed for not doing so.
The structure, and why each part is there
Both a one-off access request and a proposal for a new system land in the same column, so nothing gets started by word of mouth outside the board. A hallway conversation isn't a request until it's a card.
A cap on how much budget-bearing or infrastructure-touching work is approved and active at once, so vendor evaluations and rollouts don't all start simultaneously and stall. It's the same limit that keeps any ShipSprint board from quietly overloading one column, applied here to the exact spot where an overloaded IT team feels it first.
The person who filed a request can see where their ticket sits without messaging IT to ask. The board is the answer to "any update on this?"
The built-in wiki records why a vendor was chosen, what was evaluated, and what was decided, with page history. That's genuinely useful the next time the contract comes up for renewal and nobody left on the team remembers the original comparison, because the wiki still does.
Multi-week projects are scheduled against who on the IT team is actually free, with approved leave accounted for, rather than assuming everyone can drop what they're doing.
A quick access request can jump ahead of a slower-moving project without the board implying the project doesn't matter. Priority and effort are tracked as different things, so a big project isn't penalized for taking longer to show progress.
Every closed ticket carries a short note on what was actually done, so six months later "did we already fix this for someone else" has a searchable answer instead of starting from zero.
How to use it
- 01Route every request through the inbox, including verbal ones. "Can you just quickly" is how untracked IT work starts, and it's the single hardest habit to break once people are used to walking over to a desk.
- 02Separate quick requests from projects using labels, not columns. They share a board on purpose. That's what makes IT's full workload visible in one place.
- 03Require an approval note before anything moves to Approved. Even a one-line note beats reconstructing after the fact who signed off on a purchase.
- 04Give requesters read access to the board so status updates stop being a Slack message IT has to write by hand.
- 05Log vendor decisions on the wiki while the evaluation is fresh, not from memory when the renewal notice arrives a year later.
- 06Set the approved-column limit deliberately low at first. Two or three active infrastructure-touching projects is enough for most IT teams to run well; more than that and everything slows down together.
The same board scales down as well as it scales up. A one-person IT function still benefits from an inbox that isn't their own memory and a place to log why the last vendor was chosen. The value doesn't depend on team size, just on the volume of requests competing for attention.
- One inbox for requests and projects keeps IT's real workload visible in one place
- Nothing budget-bearing moves to Approved without a recorded approval
- Requester visibility on the board replaces "any update on this?" messages
Common questions
Yes. This one covers internal IT work broadly, including day-to-day requests and vendor rollouts that have nothing to do with infrastructure. The cloud migration template is for one specific initiative: moving existing infrastructure to the cloud, with its own inventory-to-decommission column structure that a general request board doesn't represent well. Teams running a migration often use both, this one for the surrounding IT workload, that one for the migration itself.
They need a workspace login to submit and track requests directly. There's no anonymous form. Most IT teams add colleagues as users specifically for this, which also gives them visibility into ticket status without asking, and folds naturally into the five-free-user allowance for smaller organizations.
No. There are no screenshots, keystroke logging, or activity tracking. The board shows ticket and project status only, not how anyone is spending their time.
Not to start. It's included on the Free plan, which covers up to five users and two projects with no expiry. Small IT teams often run on it indefinitely. Larger teams need a paid plan for seats beyond five, detailed on pricing.
Yes, as separate projects in the same workspace, though most teams start with one shared board and only split by site once request volume genuinely warrants it. Splitting too early just recreates the visibility problem this template is meant to solve.
Related pages
See it on your own work.
A workspace your whole company will actually use is 60 seconds away. No card, no risk, nothing to install.
14-day full-access trial · sample project included · no card required