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?
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!
Back-up and version history is required or at least a way to export the Project file. Currently there is now way to revert a older version of Project when a mistake is made. It has happened several times that one team member checks one major task as done which after all subtasks got checked and if the user doesn't undo (Ctrl + Z) right away all the progress data is lost. A fix is needed soon as this is a major issue!
Q: What’s the most important set of information in a baseline? How often do you take baselines? How often do you compare baselines?
A: The MVP is that there is one set of baseline fields that can be set and re-set. I think a better implementation is dynamic versioning. E.g. Wrike uses multiple snapshots which are auto-generated as plans are updated and can be - optionally - named. You can then compare current plan to any of these versions. There are other similar versioning models to this, like e.g. Google Docs on OnShape, where a new version is automatically created every time the model/document/project is updated and can be named. I think this is the ideal functionality.
Comparing to baseline is something you would typically do almost daily, but certainly weekly.
Q: For those of you who have not previously used the desktop client or Project Online, how have you been tracking baselines on your projects?
A: You can't! Other than managing it a spreadsheet or something.
Baselines are very important from a lessons-learned perspective. A PMO needs to be able to compare planned vs real timelines at the end of each project's phase and assess the impacts on them so they can make sure to avoid for the future.
Baselines are crucial, especially for bigger teams: PMO needs to compare planned vs real at the end of each project's phase, so they create a baseline at the beginning of each phase and compare it to real at the end. PMs change short-term plans and dates within the projects but the baselines give PMO a chance to check how effectively they delivered at the end, no matter the changes.
Adrienne Radesky commented
Microsoft Project Team- is there any update on baselines? This is so important to tracking changes made in Project 4 the Web (actuals). I am having to export my tasks lists manually and comparing the variances manually to understand the changes.
It is important for clients to track the original estimated hours that was sold for the delivery of the project to ensure we deliver on target and do not go over. The wbs on the project can change alot throughout the project and so can not be used to hold as the original estimates. I am being asked about this a lot with PSA also