Saving Baseline (Project for the Web)
One of the biggest advantages of the MS Project (and Project Online) to the other compactor products in web based platforms is the possibility of having Baselines. Without a Baseline controlling the plan and having Planned vs Actual stats wouldn't be easy.
Please add the option of saving baseline on any given status of the plan without overwriting them so w can compare current status with multiple baselines.
Thanks for the feedback on baselines. I’d love to hear more, and get a discussion going to understand the needs and usage here.
What’s the most important set of information in a baseline? How often do you take baselines? How often do you compare baselines?
For those of you who have not previously used the desktop client or Project Online, how have you been tracking baselines on your projects?
Stuart Kotchie commented
As per other comments here. When using dependencies the system currently automatically moves on tasks if you alter (for example) a tasks completion date (all other dependent tasks and their dependent tasks and so on move automatically). This is very very hard to keep track of as there is no Version control or no FLAG indicator to highlgiht a task or milestone date has been changed. MAybe even just flagging those tasks in bold for the PM so they can work through the impacts of a date change, would really help and then ideally they could "accept" this new version of the plan.
In terms of baselining - this is key, if for nothing else, than MILESTONES. currently we are having to have two milestones on a the plan - one with no dependencies showing the baseline version and one with dependencies showing the current status. When reporting we have to show if we are overdue (so need hte baseline milestone) otherwise the automatically moved milestone looks on time, when it is not.
I agree with comments below, this is necessary to track actuals and project progress. A "must have" feature
Agree with the comments below - critical for us to have the ability to compare and analyze actual start dates/end dates/durations for tasks vs. initially forecasted start dates/end dates/durations
Oliver Lennartz commented
Before we had baselines in excel which was really complicated to compare actual vs baseline
Sergio González commented
Baseline is very useful to compare forecasts to actual progress within a project, this should be implemented right away.
Sebastian Gomez commented
I think just very simply being able to see what tasks were forecasted to take versus what they actually took would be a great learning feature!
Gary Gastaldo commented
Would like the ability to show variance to the baseline at a task and project level. We can't move to PWA until this feature is enabled
Jamal Wilson commented
I wanted to answer the question the admin had above at least for my organization.
- Most important information captured in the baseline: at the task level - resource, start date, finish date, ETC, duration, project financials
- We typically baseline at the exist of our assess phase, the exist of our plan phase. after which a new baseline would be required if any changes to scope, cost, are approved.
- we compare baselines on a weekly basis leveraging status reporting to compare planned vs actual.
Imagine having a slider that lets you go back in history to the very beginning of your project. You could then replay the evolvement of your project, what a great feature for your lessons learnt session!
Having the possibility to tag a certain point in history of your project gives you the complete Baselining feature, and more.
Baselining is certainly a very important feature because it gives you a snapshot of the hole project, which is worth much more than just the history of all fields alone, like in Azure DevOps.
Governance for milestones becomes less important, when you're able to track every single change automatically.
Jamal Wilson commented
while this feature is urgently needed to track project variance, it's very important that we specify from a requirements standpoint that the baseline needs to be tracked at the task level and not just project level. as well there needs to be governance wrapped around baselining, as typically in a PMO driven organization the project manager should not have the ability to modify the baseline once approved without proper change management. There would need to be permissions around any baseline functionality were it could be set by an admin.
We use baseline to track our estimates with the actual time spent and create reports on the variance between those two. How else are you going to control your budget if you can't compare your current situation.
Marcos Jesus commented
Lack of baselines, complex dependencies (FF, SS, SF), lags and critical path is a deal-breaker for any engineering company to use Project on the web.
Project on the web seems to be conceived with only Agile projects in mind -- fixed timeboxes, flexible scope -- which definitely is not the case when you need to track projects to construct buildings, planes, ships, bridges and other construction types.
It would be useful to have the ability to plan out a project and set the planned/estimated start/end date and effort and then be able to add the actual start/end date and effort for each task. This would then show how well reality is comparing to what was planned and highlight where issues are arising. Essentially a gantt chart.
We set a baseline of major milestones that were approved by a governance committee. We then have a report that compares the baseline to the current plan, and if there is a variance of >3 months for any major milestone, we have to notify the governing body of the change, and, if endorsed, we then set a new baseline.
Therefore, we need multiple baselines, each one having a custom name and datestamp.
From the comments, it seems like project for the web team should be investing more on version controlling projects in pwa compared to creating baselines.
The version control feature should allow users to compare current plan against any previous versions and see changes that have been made not just to time related fields but any fields in that project.
Baseline is absolutely critical to the point that without that, our PMO wont shortlist any software's to implement and that is the current bottleneck with Project for the web.
Baselines are the only reason why we have not moved from Planview Enterprise One to Project for the web.
Most important set of information - Baseline Start and Baseline Finish Date ; Variance visualized as translucent Gantt bars behind current task bars in timeline view, could also be just lines at the bottom of the current tasks in timeline view which when hovered over shows the variance. Also a variance column would be great addition.
Frequency of Baseline Capture - once in 2 weeks and at phase level.
Compare baseline - Every day / week.
We have been tracking baselines since 2013 and is crucial part of our Project Approval committee reviews.
It is essential that only the Project Admin has access to this baseline and no one else, so that would mean, you guys need to take care of user roles as well with this feature.
Now that we have moved to more agile and hybrid project management, We track tasks using Planview Projectplace(no baseline feature) and sync back to Planview Enterprise One(this tool has baselines and syncs tasks and timeline with projectplace 1:1 and is pretty robust but other things are a bit annoying to use) So, we use 2 tools, one agile and one advanced software to track baselines.
Very compelled to move to Project for the web but we really really need the Baseline feature added.
Each week I would review the plan. During the week both myself and other people would modify the plan either directly or through changes to resource availability. Each week I would take a baseline so the following week I could see what had changed.
Having only one baseline was very limiting. I also made a copy every week so I could compare older versions which was a painful manual process.
What I really wanted to do was to keep every weekly baseline, give names to baselines at key points in the project and then be able to easily compare the current plan to any previous baseline.
Another way of looking at it is a file versioning, similarly to the way I can compare any two versions of a Word document on SharePoint.
Version Control = I agree that some form of versioning or version control should be added. When many changes are made to a large project, it is difficult to identify what has change. It is even more difficult to revert back to prior versions if needed.
I do not want to have to print screen every change that is made.
One idea to identify changes is to have a modified column with the "last modified date"
Another idea to support versioning, is to adopt a similar feature like OneNote. When someone makes a set of changes, it will save all the changes performed in that time period in a single version that can be reverted to.
Need to at least have the beginning baseline. This is typically the one which was committed to by the project team.
Baseline is critical. Most important baseline is at the begin - once the plan is officially approved it is saved as baseline. To do this would mean a lot.
Everything else is, sorry, a mess!