“Project Management for IT Departments: A Practical Guide”

What makes project management for IT departments different?

IT project management differs because the project team and the operations team are usually the same people, working on the same systems, with the same change calendar. A construction project can hand a building to a facilities team that was never involved. An IT project hands a service to the colleagues who were already maintaining the last three versions of it.

Three consequences follow. First, capacity is shared, so a project plan that assumes full-time allocation is fiction. Second, risk is cumulative: every change to a production system carries operational risk, even when the project is small. Third, the definition of done includes supportability. A feature that works but cannot be monitored, patched, or restored from backup is not finished.

This is why frameworks converge on the same idea from different directions. PRINCE2 puts “defined roles and responsibilities” among its principles. ITIL 4 treats change enablement, incident management, and service configuration management as practices that run alongside delivery. DORA’s research on software delivery measures both speed (deployment frequency, lead time) and stability (change failure rate, time to restore), which encodes the same tension: shipping faster is only good if the service keeps working.

How should an IT intake process work?

Intake should be one form, one queue, one scoring rule, and one decision forum per week. Anything else becomes a popularity contest where the loudest department wins and the audit finding waits six months.

A workable intake form asks for eight things: requester and business owner, the problem in one sentence, the outcome and how it will be measured, affected systems, estimated effort, deadline and its driver, regulatory or security exposure, and what happens if nothing is done. That last field is the most useful, because it converts urgency into a consequence.

Score each request on four dimensions, one to five: impact, risk of inaction, effort, and dependency on other teams. Multiply impact by risk, divide by effort, and use the result as a starting order rather than a verdict. The forum still decides, but it decides with a number in front of it.

Then do the capacity arithmetic honestly. Suppose the department has six engineers at roughly 120 productive hours each per month, which is 720 hours. Twenty percent is reserved for incidents, patching, and access requests: 144 hours. That leaves 576 hours for project work. At an average request size of 14 hours, the department can absorb about 41 requests a month. If 46 arrive, the backlog grows by five every month, and no amount of prioritisation fixes a capacity gap. The choice is to cut scope, add people, or accept the queue.

Where does change control fit without strangling delivery?

Change control belongs at the point where a change becomes irreversible, not at the point where work starts. Classify changes into standard, normal, and emergency, pre-approve the standard ones, and let the change advisory board spend its time on the handful that carry real risk.

ITIL 4’s change enablement practice describes exactly this split. Standard changes are low-risk, repeatable, and pre-authorised, such as adding a user to a group or deploying a tested container image through an automated pipeline. Normal changes follow a review proportional to risk. Emergency changes get a fast path with retrospective review, because an outage does not wait for a Tuesday meeting.

The number to watch is the proportion of emergency changes. If emergencies are under about 10% of total changes, the standard and normal paths are probably working. If they are 25%, the process is not too slow; the pipeline is too weak, and teams are routing around approval because there is no safe fast lane.

Worked example. A team makes 120 production changes in a quarter. Fourteen are emergency, which is 11.7%. Each emergency change consumes about six engineer-hours in coordination, rollback checks, and retrospective review, against roughly two hours for a normal change. The extra coordination cost is 14 × 4 = 56 hours, or about 1.4 working weeks of one engineer, before counting the customer impact. Cutting emergencies to eight would return about 24 hours per quarter to delivery work. That is a small number that compounds across teams.

How do you hand off to ITSM without losing knowledge?

You hand off by making the service, not the software, the unit of delivery. Before go-live, the project must produce service acceptance criteria, a support model, monitoring, runbooks, and a configuration record. The operations team signs those off, and the sign-off is a gate, not a courtesy.

A practical checklist has seven items:

1. Service acceptance criteria agreed with the service owner, including performance, availability, and recovery targets.
2. Monitoring and alerting configured and tested, with alert routing to the on-call rota rather than a personal inbox.
3. Runbooks for the five most likely failures, written by the engineer who built the component.
4. Backup and restore tested, with the restore time recorded rather than assumed.
5. CMDB or asset record updated with owner, dependencies, and support tier.
6. Knowledge articles published for the service desk, covering the top ten expected tickets.
7. Warranty period with named engineers from the project team available for a defined window, typically two to four weeks.

The warranty period is the item most often skipped and most often missed. Without it, the first real incident becomes a negotiation about whether the project is still open. With it, the project team sees the failure modes their testing missed, and the service desk gets answers in hours instead of days.

Handoff also has a commercial dimension. If the project is delivered by a vendor, the support model and knowledge transfer should be in the statement of work, with acceptance tied to evidence rather than an email confirming completion.

How do on-call constraints reshape a project plan?

On-call reduces effective capacity and raises the cost of a bad schedule. A five-person rotation with one-week shifts puts each engineer on call one week in five, and the week after a major incident produces measurably worse project output. Plan for it instead of discovering it.

Start with the arithmetic. Five engineers, one on call at a time, 24/7 coverage: each person carries 20% of the year on pager duty. During an on-call week, project work typically drops by half, because interruptions break concentration even when they are short. That is 0.5 × 0.2 = 10% of annual capacity consumed by carrying the pager, before any actual incident occurs.

Add incident recovery. A severe incident that runs from 01:00 to 05:00 removes roughly half of the next working day for the responders, and more if they are the only people who can fix the problem. If a team handles two severe incidents a month, that is one to two engineer-days lost per month, or about 3% of a six-person team’s capacity.

Change freezes deserve their own line. Most enterprises freeze production changes during peak trading, financial close, or audit. A project plan that ignores the freeze calendar will look late in December and early in January, for reasons that have nothing to do with engineering effort. Put the freeze dates on the plan as constraints, not as surprises.

What metrics should an IT project report?

Report two sets of metrics: delivery progress and service stability. A project that is on schedule but has doubled the incident rate has not succeeded; it has moved cost from the project budget to the operations budget.

The clever part is comparing the periods before and after go-live. If incident volume rises 30% and stays there, the project delivered a feature and a permanent cost increase. That is a finding for the steering committee, not a detail for the service desk.

What are the trade-offs in structuring IT project management?

There are two common structures, and neither is universally right. A central PMO gives consistency and portfolio visibility but can slow teams down and distance decisions from the engineers. Embedded delivery leads move faster and understand the systems but produce inconsistent reporting and duplicate tooling.

The hybrid usually wins because intake and change control genuinely benefit from centralisation, while planning and execution benefit from proximity. The failure mode is a hybrid that keeps the PMO’s approval layers and the embedded team’s informality, getting the costs of both.

What mistakes do IT departments make most often?

Planning at 100% allocation. The plan assumes eight hours of project work per engineer per day. It never survives a patching week.

Treating the change board as a rubber stamp. If the CAB approves everything, it is not controlling risk; it is absorbing liability. Pre-approve standard changes and reject weak rollback plans.

Skipping the service desk in design. The team that will answer the tickets is consulted after go-live, when the error messages are already in production.

No rollback plan. Every normal and high-risk change needs a tested way back, with a decision point and a named person who calls it.

Measuring project success at go-live. Adoption, incident rate, and support cost are the real acceptance tests, and they take a month or two to appear.

Letting on-call engineers commit to critical-path tasks. The person most likely to be interrupted should not own the task everything else waits for.

How does Doitify support IT delivery teams?

IT delivery needs one place where project tasks, operational work, and approvals are visible together, because the same engineers carry both. In Doitify, tasks and sub-tasks can hold owners, due dates, checklists, and dependencies, while boards and Gantt views show the delivery plan and workload views show who is over-allocated before the sprint starts.

For the handoff, project documents, meeting notes, risks, and constraints live alongside the work, so the runbook conversation happens in the same workspace as the build. Recurring tasks and reminders cover the operational rhythm, and import/export keeps data portable for audits.

Transparency note: Doitify is our product, and we describe it here because IT teams often ask how to keep project and run work in one view. It is a project and team management platform; it does not replace your ITSM tool, and the handoff checklist above still has to be done by people.

Conclusion

Project management for IT departments is operations-aware project management. The plan has to fund run work before it promises delivery, the intake process has to replace the queue of messages, and change control has to be fast for low-risk work and rigorous for the rest.

If you change one thing this quarter, change the handoff gate. Write service acceptance criteria, name the warranty engineers, and refuse go-live until monitoring and runbooks exist. Projects that pass that gate stop exporting their problems to the service desk, and the department stops paying twice for the same delivery.

If this post on project management for IT departments was helpful, you might also enjoy How to Make Deadlines More Visible and Free Project Budget Template.