IT project management: what makes it different

IT project management follows the same fundamentals as any other project — scope, schedule, cost, risk. What changes is not the method but the terrain, and three characteristics of that terrain explain most of the difficulty: what you are building cannot be seen, the people building it are shared with other projects, and the existing system must keep working throughout.

Progress is not observable

On a construction site, everyone sees the floors go up. On an IT project, the only visible signal is what someone declares. That is why reported progress on software drifts towards a comfortable number and stays there — the famous last 10% that lasts three months. The counter-measure is to make progress observable: working software at a fixed rhythm, integration done continuously rather than at the end, and acceptance criteria written before development rather than negotiated after it.

The team is never dedicated

IT people are shared: the same architect serves four projects, the same DBA is on everyone’s critical path, and production support outranks everything the moment an incident opens. A plan built on nominal availability is therefore wrong from the outset. You have to plan on capacity net of support, holidays and the other projects — which is a portfolio question, not a project one, and the main reason IT schedules slip without any single project doing anything wrong.

The legacy is part of the scope

Very few IT projects start from a blank page. Interfaces with existing systems, data migration, cohabitation of two versions during transition, and reversibility if the launch goes wrong are rarely estimated seriously at framing time, and they routinely weigh more than the new functionality. A specification that describes only the target and says nothing about the transition has left out half the project.

Agile and planning are not opposed

Most IT organizations run hybrid whether they admit it or not: agile inside the teams, committed dates and budgets outside. Pretending otherwise produces two disconnected truths — a backlog that says one thing and a steering committee that hears another. The workable approach is to plan the envelope and the milestones, iterate within them, and re-arbitrate scope rather than silently move the date.

Running IT projects with FoxPlan

FoxPlan holds the two levels at once: a planned Gantt with milestones and budget for the commitments, agile boards and sprints for the work itself, and consolidated resource capacity across every project so a shared architect appears as one person and not four. Time entered by the teams feeds both progress and cost, which is what allows an IT portfolio to be reported on without a parallel spreadsheet.