Project Management for IT Projects

IT projects, not the IT desk

This page is about the initiatives, a platform migration, a new ERP rollout, an infrastructure overhaul, a vendor cutover, a data-centre move, a company-wide tool switch, not the day-to-day support queue. If you're looking for ticket triage and SLA timers on inbound requests, that's a narrower job and a narrower page: internal-facing helpdesk work and support tickets have their own patterns and their own page. IT projects, as we mean them here, are the multi-week or multi-month efforts a team commits to and has to plan, staff and report on like any other piece of delivery work, with a start, an end, a budget and a sponsor asking about all three.

The trouble is that IT initiatives often get managed with whatever is lying around: a spreadsheet inherited from the last project, a shared inbox, a recurring meeting that exists mainly to establish what already happened since the last one. None of that scales past a handful of people, and none of it tells the sponsor whether the go-live date is still real. It also tends to hide the true size of the work. A migration looks like one line item on a spreadsheet even though it's actually forty interdependent tasks spread across three vendors and two internal teams.

ShipSprint gives IT initiatives the same discipline engineering teams take for granted, a board with limits, a forecast built from actual pace, and a place for the decisions that would otherwise live in someone's inbox or a meeting nobody wrote down properly.

Why capacity limits matter more in IT than most places

IT teams get pulled two directions at once: the planned initiative and the unplanned interruption, a server that needs attention, a request from a department head who caught someone in the corridor, a vendor call that runs long because something broke. Without a mechanism to separate the two, the initiative absorbs the interruptions silently and the plan slips without anyone deciding it should. Nobody chose to delay the migration by two weeks; it just happened, one interruption at a time, and by the time it's visible on a report it's already too late to do much about it.

Per-column WIP limits make that trade-off visible instead of invisible. When a column is full, the next item has to wait or something has to move, a decision gets made instead of just happening. New requests land in a triage inbox rather than someone's inbox, so the interruption is a queued, visible item rather than a tap on the shoulder that quietly consumes the afternoon. Whoever owns the initiative decides, deliberately, whether the interruption jumps the queue or waits, instead of the queue jumping itself because someone asked nicely in person.

Reporting up, without building a deck

IT initiatives usually answer to someone outside the team, a CIO, a board, a client whose systems are being migrated. That person doesn't want the board's internal detail; they want one honest answer to "are we on track," ideally without anyone spending an afternoon building a slide to deliver it. The owner command center gives that answer directly, and the Monday digest delivers it without anyone assembling it by hand, which matters most exactly when the team is too stretched to also be the reporting department for its own project.

What this replaces, specifically

• The spreadsheet tracker that only the project lead updates, and only remembers to update under pressure
• The status meeting that exists to answer "where are we", which a live board and a Monday digest answer without a meeting
• The shared inbox for incoming requests, replaced by a triage inbox that's actually visible to the team planning capacity
• Timesheets nobody fills in accurately, replaced by a five-second log next to the task just finished
• A separate wiki or shared drive for runbooks, replaced by pages that sit next to the work and can turn any sentence into a task
• A status deck rebuilt from scratch before every steering committee, replaced by an owner command center that's already current

The multi-vendor problem

A lot of IT initiatives aren't run by one team, they're run across an internal team plus one or two external vendors, each with their own tracker, their own vocabulary, and their own idea of what "on track" means. The internal team ends up doing translation work: taking a vendor's status update, converting it into what the sponsor actually needs to hear, and hoping nothing gets lost in the conversion. That translation labor is invisible on any project plan and it's often where a genuinely on-track initiative starts to look chaotic from the outside, simply because nobody's holding one version of the truth.

Putting vendor-facing work on the same board as internal work, even just the milestones and dependencies that touch the internal team, collapses that translation step. A vendor's delay shows up as a blocked card with context attached, not as a paragraph someone has to write and interpret for a steering committee. It doesn't require the vendor to adopt the whole tool; it requires one person on the internal team to log what the vendor told them, which they were probably already writing down somewhere less useful. That's the real gain: one version of the truth instead of a translation layer someone has to maintain by hand.