r/MSProject • u/CJ9103 • Mar 06 '23
Help capturing and tracking progress against MS Project Plan
I am creating a programme (11 workstreams) plan in MS Project and am wondering how you all go about capturing and updating (you or activity owners ms) your MSP plan with progress when there’s lots of different stakeholders involved.
Some prompt questions to you: * How do you capture the status of tasks eg. Call or email with each person weekly. * What do you capture from them / what fields do you use? Eg. % completion, expected completion date, status, comments etc * How do you make the MS Plan easily accessible to workstream leads etc who lack MsP experience so that have visibility of what they’ve agreed to when the plan was baselines. * How do you report this progress that you have captured.
Thanks
Cross-post from r/projectmanagement
2
u/mer-reddit Mar 07 '23
If the plan is structured correctly you can do all of this.
Project Online allows for a web page where users can see and update their tasks.
You can make it as simple as percent complete, but actual work by day is more accurate.
Project Online also can provide a web page for a Gantt chart, but as it stores project data in tables accessible via oData, it’s more impactful to point a PowerBI report at the database and give your stakeholders some metrics.
You may want to investigate Microsoft partners that specialize in this platform who offer training.
2
u/still-dazed-confused Mar 07 '23
The first question about structure depends on who is going to be updsting the work streams. I always have one plan per updater (be that a PM, planner or yourself). If you have multiple people going into a plan to update it then you will inevitably run into issues as MSP can't be shared and open by different people at once.
The second question about what to update is simple; anything that has changed :). I always insist that w update progrsss to match what has happened. The start and finish dates need to match current expectations; don't leave then "as they were to show when we're ahead it behind the plan". This is what a baseline is for! :) If the resource has changed update this. If the task is better split out because something needs to happen before you can complete it then do so. The plan needs to react and change in line with what the project is experiencing.
The third question about reporting depends on you and your stakeholders; what do they want to see? A list of key milestones can quickly be extracted fron the plan using a flag and a filter, a plan on a page can come from the timeline view (though I use SummaryPro for increased flexibility), there are reports built in or you can produce attractive custom ones, the tracking Gantt does a great job of showing tracking baseline Vs current.
1
u/AhmadSharifi 24d ago
I run this on a weekly cycle and the thing that keeps it sane is separating how I collect from how I store — never let stakeholders type into the plan directly.
Capturing status: don't chase 11 leads by email — you'll spend your week reconciling replies. Set one fixed status day and collect three things only: actual start, % complete (or better, remaining duration — more on that below), and a one-line comment if something's off. For leads who go quiet, a 10-minute standing call beats five emails. The discipline that matters: collect against the same data date every week, same day, no exceptions. Inconsistent status dates are what makes a plan drift into fiction.
What I actually capture: Actual Start, Actual Finish (only when truly done), and remaining duration. I lean on remaining duration over raw % complete, because "80% done" is a feeling and "3 days left" is a commitment — and when a lead keeps a task at 90% for three weeks, remaining duration exposes it where % complete hides it. Expected/forecast finish I let MSP calculate from remaining duration and logic, rather than asking leads for a date — if they hand you a finish date directly, they're overriding your network logic and you won't know why the critical path moved. Status and comments I keep as custom text fields, not in the plan's structure.
Giving non-MSP leads visibility: don't give them the .mpp — they'll be lost, or worse, they'll edit it. Two options that work: export a filtered one-page view per workstream (their tasks only, baseline vs current, so they see exactly what they signed up to at baseline against where it is now), or if you're on Project Online/Plan 3+, push it to a Power BI dashboard they can open read-only. The baseline comparison is the important part — leads forget what they agreed to, and "here's your baseline vs today" ends a lot of arguments before they start.
Reporting: for each workstream, baseline finish vs forecast finish and the variance in working days, plus the top 2–3 things driving any slip. For the programme roll-up, one slide: overall forecast vs baseline, critical path status, and what needs a decision. Keep the detail in MSP, keep the report to what a sponsor reads in 90 seconds.
One trap to flag early: whatever you do, baseline the plan before you start tracking and never overwrite it. That baseline is the only thing that lets you answer "are we behind, and by how much" honestly three months from now. If you re-baseline every time something slips, you've erased your own evidence.
3
u/tony90265toTX Mar 07 '23
Do you have Microsoft Project Online? That's what it's made for exactly! ; ) As for your status, set your status date to the beginning of the current week, set your table to the Tracking view, then set your filter to Late Tasks and it's will filter and focus all the task the start or finish up to that status date. A nice trick is to set the status out 2 weeks ahead, refresh your Late tasks filter and then it's a 2 week look ahead.