Running an Agile Project in MS Project: Gantt Charts, Slip Lines, and a Weekly Cadence

Most people file Microsoft Project under “waterfall” and agile under “sticky notes on a wall” — and treat the two as opposites. They are not. A Gantt chart is simply a picture of work over time, and there is nothing in that picture that forces you to plan every task up front. Used well, MS Project becomes an honest tracking instrument for a team that plans just enough, just in time — with slip lines showing exactly where reality has drifted from the plan, and a hard close-off milestone keeping everyone pointed at the finish.

This article walks through a lightweight, repeatable way to run a real delivery — the kind where you do not know the full task list on day one and never will until the work teaches you. Think of an infrastructure move: relocating a department to another building, or closing out an office. You know the start, you know the deadline, and you know the team. Everything in between gets discovered week by week. That is exactly the conditions agile was built for, and MS Project can hold the shape of it.

Start With Governance, Not Tasks

Before a single bar appears on the Gantt chart, the top of the plan is reserved for documentation and governance. This is the deliberate first decision of the whole approach: how much governance does this project actually need? A two-week office decommission and a year-long campus relocation do not deserve the same paperwork. Decide the weight up front and write it down, so nobody is surprised later by either too much process or too little.

Two documents do the heavy lifting, and they belong in the project before anything else. A Project Charter locks in the goal — the what and the why, the scope boundaries, the budget envelope, and the authority of the project manager to act. A Stakeholder Register locks in the who — the team, the sponsor, the people affected, and who must be consulted or merely informed. Together they fix the two things that are most expensive to renegotiate halfway through: the destination and the cast.

These live as summary headings at the very top of the schedule — a small governance block before the delivery work begins. It signals, to anyone who opens the file, that the project knows its goal and its people before it starts arguing about dates.

Open the Gantt: Tasks, Dates, Summaries, and Milestones

Now open the Gantt chart — an ordinary MS Project file with the task list down the left and the timeline bars on the right. Nothing exotic here. Tasks are tied to start and end dates, related tasks roll up under summary tasks, and key moments are marked as milestones (zero-duration tasks that show as a diamond). This is the standard structure every Project user already knows.

The discipline that makes it agile is what you choose not to fill in. You do not attempt to enumerate the entire project on day one. You enter the summary tasks and the sub-tasks the team genuinely knows about and can act on now or within the next week. The rest of the timeline holds the milestones and the deadline, but the detailed work is left deliberately thin — to be fleshed out as the team learns more.

The familiar MS Project layout: summary tasks and sub-tasks on the left tied to start and end dates, milestones as diamonds, and the Gantt bars on the right — with only the near-term work detailed in.

Set a Baseline and Turn On Slip Lines

Slip lines are the feature that turns a static plan into a living tracker, and they are the reason this approach works. A slip line is a thin marker that connects each task’s current position back to where the baseline said it should be — so the moment a task drifts, you see the drift drawn on the chart rather than buried in a number.

To use them you first save a baseline (Project → Set Baseline), which freezes the plan as it stands today. Then, on the Gantt chart area, right-click in the chart pane and choose to show the variance — in modern Project this is exposed through Show/Hide Bar Styles and the Slippage option, or by switching to the Tracking Gantt view. From then on, as you update progress each week, the slip lines reveal exactly which tasks have slipped against the baseline and by how much.

Pin the Close-Off Date as a Milestone

Agile without a deadline drifts; a deadline without flexibility breaks. This approach keeps both. Drop a milestone at the date the project must be closed off — the day the lease ends, the building must be handed back, or the new floor must be live. That diamond is fixed. It does not move with the work; the work moves to meet it.

With the close-off milestone anchored on the right of the chart and the start on the left, every weekly update is measured against that immovable point. The team is not asked to predict the whole journey — only to keep filling in the route while keeping the destination date sacred. The slip lines then show, week on week, whether the accumulating detail still fits inside the deadline.

The Weekly Cadence: Plan Just Enough, Just in Time

Between the start and the close-off date, the engine of the whole method is a weekly meeting where the PM and the team update what has been done and decide what needs doing next. This is the agile heartbeat dressed in MS Project clothing. Each week the team does four things.

The key idea is progressive elaboration: the team only ever commits to the deliverables it can genuinely see — this week and a little beyond. As the work teaches them what comes next, they flesh the plan out week by week, allocating tasks to people and driving them to done. The Gantt chart is never “finished” in advance; it grows in step with the team’s understanding while the close-off milestone holds firm.

A Worked Example: An Infrastructure Move

Picture an infrastructure project — relocating a department to another building, or closing out an office entirely. On day one you know very little of the detail. You know the start date, you know the floor must be vacated by the close-off milestone, and you know your team. So the plan begins almost empty: a governance block at the top, a handful of summary tasks (Survey current site, Plan network cutover, Coordinate movers), the close-off milestone on the right, and not much else.

Week one, the site survey teaches the team that the comms room has more cabling than expected. So in the weekly meeting they flesh out a new summary task with sub-tasks for cable audit and decommission, assign them to the network engineer, and set dates. Week two, the movers confirm a date, which becomes a milestone, and new packing tasks appear beneath it. Each week the plan grows a little more solid, always anchored to the same hand-back date, and the slip lines show whether the newly discovered work still fits the deadline. The plan was never wrong on day one — it was simply honest about what was not yet known.

Risks and Issues: Raise Early, Track Honestly

Running thin on up-front detail makes a Risks and Issues register essential rather than optional. The distinction is simple and worth stating plainly to the team, because it changes how they report.

Because the team is discovering the project as they go, the register is never static. New risks appear as understanding deepens; some are retired, others mature into issues. The weekly meeting is where the register is updated — risks raised, issues progressed, and anything unforeseen captured before it is forgotten. In a progressively elaborated plan, the register is the memory of everything the team has learned the hard way.

The Weekly Status Update to Stakeholders

The weekly meeting produces two artefacts that go out to the stakeholders named in your register: a combined Risks and Issues report, and a snip of the project plan showing the task list on the left and the Gantt chart with its slip lines on the right. Together they tell the whole story in one glance — what is on track, what has slipped, and what the team is worried about.

This is where a capture tool like Snagit earns its place. Rather than exporting or reformatting, the PM simply snips the entire schedule — tasks and the Gantt chart together — and drops the image straight into the weekly status email alongside the risks and issues summary. It takes seconds and gives stakeholders the same honest picture the team is working from.

The weekly update: a Snagit snip of the full schedule — tasks on the left, Gantt and slip lines on the right — sent alongside the combined risks and issues report.

The Key Takeaway

MS Project is not the enemy of agile delivery — misused, it is just a way to pretend you know more than you do. Used with restraint, it becomes a disciplined home for a team that plans just enough each week. Fix the governance and the goal up front with a charter and a stakeholder register. Anchor the close-off date as an immovable milestone. Detail only the work you can see, allocate it to people, and let the slip lines tell the truth about drift. Then meet every week to learn, re-plan, update the risks and issues, and send a single honest snip to your stakeholders.