IT projects rarely fail on technology. They fail because nobody wrote down what done means, the task list lived in one person's head, and every hallway conversation added a feature. The migration that was going to take six weeks is in month five, and the client is not sure what they are paying for.
You do not need a certification to fix this. You need three habits: a scope document, a work breakdown structure, and a change control rule that everybody knows about. This post walks through each one with a server migration as the running example.
Scope: write down what done means
A scope statement is one or two pages. It says what the project delivers, what it does not, what must be true for it to start, and how you will know it is finished. Write it with the client, not for them, and get a signature or an email that says 'agreed'.
For a server migration the deliverable is not 'new server'. It is: file shares moved with permissions intact, the application running on the new host, backups protecting it, the old server powered off, and the documentation updated. Each of those is a testable statement. If it cannot be tested, it is not a deliverable.
- Objective: one sentence on why the project exists
- Deliverables: a numbered list, each one testable
- Out of scope: the things people will assume are included and are not
- Assumptions: what must be true (ISP installed, licences purchased, staff available)
- Acceptance: who signs off and against what checklist
- Constraints: budget band, dates that cannot move, maintenance windows
Work breakdown structure: from deliverables to tasks
A WBS is a tree. The project is the root, deliverables are the branches, and the leaves are tasks small enough to estimate and assign to one person. If a task is more than a couple of days of work, break it down again. The goal is a list where every item has an owner, an estimate, and a clear finish.
Once the tree exists, add dependencies. The application cannot be installed until the OS is built; the OS cannot be built until the hardware is racked; the hardware cannot be racked until it arrives. That chain is your schedule, and the longest chain is the earliest the project can finish. Anything that shortens that chain is worth attention; anything off it can slip a little without harm.
- List deliverables from the scope statement as the top level
- Under each, list the tasks needed to produce it, until each is a day or two of work
- Assign an owner and an estimate to every task
- Mark dependencies between tasks and find the longest chain
- Put dates on the chain, add a buffer, and share the plan with the client
Change control: how to say yes slowly
Scope creep is not malicious. The client sees the new server and asks if you can also move the accounting database while you are at it. The right answer is 'let me write that up', not 'sure' and not 'no'. A change request is a short form: what is being asked, what it adds in time and cost, what it affects, and a yes or no from the person who approved the original scope.
The rule to announce at the kickoff: anything not in the scope document goes through a change request, and change requests are answered within a set number of days. Most requests are small and get approved. The point is that they are visible, priced, and scheduled rather than absorbed into an evening that nobody bills.
- Requested by, date, and description in one paragraph
- Impact on schedule, cost, and other deliverables
- Recommendation from the project lead
- Approval from the scope signatory, in writing
- Change log updated and the WBS adjusted
Running the project week to week
A weekly status note keeps everyone honest. Keep it to what was done, what is next, what is blocked, and whether the end date has moved. Send it whether or not there is news. Silence is what makes clients nervous.
Track risks separately from tasks: the vendor part that might be late, the person who is on holiday during cutover, the old application with no installer. Each risk gets an owner and a plan. When one turns into a problem, you already know what to do. At the end, hold a short review: what went well, what to change next time, and whether the acceptance checklist was signed. Then archive the plan with the documentation so the next project starts from a template instead of a blank page.
Frequently asked questions
Do we need project management software?
For most managed IT projects a shared document for scope and a task board or spreadsheet for the WBS is enough. The discipline matters more than the tool. Move to a dedicated tool when several projects run at once with shared staff.
How much buffer should we add to the schedule?
Enough to cover the risks you listed, not a blanket percentage. If the main risk is hardware delivery, buffer after delivery. If it is a vendor cutover, buffer around that. Explain the buffer to the client so it is not seen as padding.
What if the client refuses to sign a scope?
Do the work in phases with a small first phase and a scope for that alone. A client who will not agree what done means for a two-week phase is telling you something about the whole project.
Takeaway
Write the scope with testable deliverables, break it into tasks with owners and dependencies, and put every new request through a short change form. Add a weekly note and a risk list, and most IT projects finish close to the plan. The habits are simple; the discipline to keep them is the job.