When do you generally baseline a project schedule?
Anonymous
I am curious about project scheduling practices related to baselines.
When do you baseline a project schedule during a project?
Does that baseline spell out the rest of the project's planned tasks and phases or just the next upcoming phase of the project?
How often do you re-baseline the rest of the project after your first baseline?
Is creating a new baseline during a project a rare occurrence or common occurrence?
I am coming at this from a Healthcare and Information Systems world, but am open to insight from any industry. Much appreciated getting your perspectives on all of this!
Senior Projects Manager | Field & Marten AssociatesNew Westminster, British Columbia, Canada
Mar 25, 2020 11:53 AM
Replying to Andrew Soswa
...
Baseline it at the project's approval. Re-baseline it only upon major project's change. Understand what is changed and communicate with all stakeholder how it affects project.
To add on my original post. PM has to understand what baseline is for and know how to communicate the creep in variance between baseline and actual.
If, as suggested, PM re-baselines every so often (on a milestone) - your variance is small and project's report looks great, PM looks great. However, reality is that the KPIs (ie. AC, PV, CPI, SPI, etc) must be closely managed and HONESTLY reported.
For example, you are 10 months deep into 2-year project, you re-baseline project every month and your CPI is only 0.98 (SPI is 1.10). You celebrate success for being on the budget and ahead of schedule. PM looks great!
BUT if you kept original baseline from the beginning of the project, you'd notice that cumulatively your CPI is 0.50 (your SPI is 0.70) which means that you burned 100% more money that you had allocated for this far in the project and you are deeply behind the schedule.
Very well said Andrew - Spot On ! Saving Changes...
Andrew SoswaTechnology leader| Leading global financial institutionElk Grove Village, Il, United States
Mar 25, 2020 5:27 PM
Replying to David Portas
...
In my field of information systems I would say never. For each iteration we define a goal but a goal is a forecast, not a baseline. Velocity or function points are good measures of productivity and delivery but baselines seem to be of very little value for software projects and often do more harm than good.
I worked on software projects with waterfall-type methodology (requirements plan set baseline manage execution of the plan). In software development based on Agile, baseline does not exist because the end product cannot be fully planned out (yes, once I planned out entire Agile project - but it's an anti-pattern).
In hybrid Agile/waterfall/whatever-methodology, you can still create baseline vs forecasted goal, and measure it accordingly, if that's your business methodology. It's harder to report on such KPIs because these short phases usually are not equal. If these "phases" are equal you are better off to start reporting velocity (burn of total effort per sprint) in addition to burn of the schedule and money per sprint.
My volunteering team learned in last two sprints how to use velocity to report variance between sprints. Here are steps: 1. Ensure that there are following columns in velocity chart: a. Total effort of all US accepted during Sprint Planning b. Total effort of all US completed by team c. Total effort of all US accepted by PO (providing that 1 US = 1 deliverable, if not - then skip it) d. Total time spent on each US in the sprint 2. Never try to calculate effort to time (i.e. 1 US effort point = 4 hours of work) 3. Measure over sprint 3 through n to see the velocity in a, b, c, d 4. Experiment and adjust often Saving Changes...
Anonymous
A project schedule baseline is typically established after the project schedule has been finalized and approved, but before any actual work has begun. This is usually done at the end of the project planning phase. Saving Changes...
A project schedule baseline is typically established after the project schedule has been finalized and approved, but before any actual work has begun. This is usually done at the end of the project planning phase. Saving Changes...
Baseline management varies across industries, but in general, the initial baseline is set once the project plan is approved, typically after key stakeholder alignment. It usually covers the entire project's planned tasks and phases, though in phased projects, some teams baseline only the next phase.
Re-baselining depends on project dynamics—it's common when there are significant scope changes, major delays, or unexpected risks, but it shouldn’t be frequent unless necessary. In my experience with projects, re-baselining happens when there are regulatory changes, technology shifts, or new stakeholder requirements.
How often do you find yourself adjusting baselines in your projects? Saving Changes...
Community Champion
