Project Management

Project Management Central

Please login or join to subscribe to this thread

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!

Thank you!
Sort By:
Page: 1 2 <prev
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 !
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
Page: 1 2 <prev  

Please login or join to reply

Content ID:
ADVERTISEMENTS

I'm lactose intolerent. I have no patience for lactose and I won't stand for it.

- Jerry Seinfeld

ADVERTISEMENT

Sponsors