Project Management Central
|
Please login or join to subscribe to this thread
|
|||
|
|||
Keith Novak
Tukwila, Wa, USA
Consider what a baseline is and how it's used. The term originates in land surveying, where it is a straight line at a known location that serves as the reference system. It is like the x-axis on a graph.
Baselines are created or "struck" (like driving stakes in the ground with a hammer) early in a project when you need every contributing plan aligned with the over arching master plan. The baseline is typically end to end, but often the near term activities are in much greater detail than the distant ones due to the many unknowns. The baseline is updated infrequently, as if you have a highly complex plan, whenever you move the baseline, everyone else needs to adjust so it creates "churn" which = overhead. We often show schedule slides compared to the baseline plan rather than moving the baseline dates so that we can see the slide and the impact. The baseline is either updated at pre-planned milestones such as gates, rolling wave updates, major project reviews etc., or when so much has changed that we need an ad hoc baseline update to avoid confusion. If everything on the master schedule has slid several times, it's hard to read the schedule, so we might "blockpoint" the baseline, update the work statements with the latest known plan, and clean-up the master schedule in-line with the current plan. It doesn't matter what industry you are in (remember it came from surveying), the purpose is the same. Even in a more agile environment, if you can't have some notional plan of when and how the project will end, you are not managing a project. The most important thing when considering when to revise your baseline is understanding the function: It is the reference system for all lower tier plans. When everything is getting out of synch such as working to different plans or many late deliverables or when stakeholders don't understand the plan, that is when you consider updating the baseline to bring everyone back into alignment with your reference system. ...
1 reply by anonymous
Mar 25, 2020 10:22 AM
anonymous
...
Thank you, Keith. That certainly helps and is insightful.
You mention the baseline is updated infrequently, but that it's updated at pre-planned milestones during gates, etc., so does that mean a new baseline is being created and approved or the project schedule is being updated with the current baseline and merely refined/adjusted? The example I'm thinking of wouldn't be a change in scope. 
Let me edit my reply, does anyone know what baseline is used for?
...
1 reply by Jason Eberhardy
Mar 25, 2020 11:28 AM
Jason Eberhardy
...
Hello Andrew,What's your initial response/reaction? Are you asking regarding baselining a project or a schedule? To me the project schedule's baseline is the approved version of a schedule that serves as the basis/starting point for how the rest of the project actually goes, so that the team and executives have something to measure against for the actual results of how the project goes. 
Anonymous
Mar 25, 2020 10:05 AM
Replying to Keith Novak
...
Consider what a baseline is and how it's used. The term originates in land surveying, where it is a straight line at a known location that serves as the reference system. It is like the x-axis on a graph.Baselines are created or "struck" (like driving stakes in the ground with a hammer) early in a project when you need every contributing plan aligned with the over arching master plan. The baseline is typically end to end, but often the near term activities are in much greater detail than the distant ones due to the many unknowns. The baseline is updated infrequently, as if you have a highly complex plan, whenever you move the baseline, everyone else needs to adjust so it creates "churn" which = overhead. We often show schedule slides compared to the baseline plan rather than moving the baseline dates so that we can see the slide and the impact. The baseline is either updated at pre-planned milestones such as gates, rolling wave updates, major project reviews etc., or when so much has changed that we need an ad hoc baseline update to avoid confusion. If everything on the master schedule has slid several times, it's hard to read the schedule, so we might "blockpoint" the baseline, update the work statements with the latest known plan, and clean-up the master schedule in-line with the current plan. It doesn't matter what industry you are in (remember it came from surveying), the purpose is the same. Even in a more agile environment, if you can't have some notional plan of when and how the project will end, you are not managing a project. The most important thing when considering when to revise your baseline is understanding the function: It is the reference system for all lower tier plans. When everything is getting out of synch such as working to different plans or many late deliverables or when stakeholders don't understand the plan, that is when you consider updating the baseline to bring everyone back into alignment with your reference system. You mention the baseline is updated infrequently, but that it's updated at pre-planned milestones during gates, etc., so does that mean a new baseline is being created and approved or the project schedule is being updated with the current baseline and merely refined/adjusted? The example I'm thinking of wouldn't be a change in scope.
Keith Novak
Tukwila, Wa, USA
Unless you're lucky enough were everything is going perfectly, the working level project schedules are being updated and aligned with the current baseline frequently.
The baseline itself is updated when there is some major shift. If a single milestone on the baseline moves and there is sufficient float or slack so that it has limited affects on detail level plans, then typically you might just show that slide on the master schedule. If there are changes with significant impacts to the overall schedule, you generally want to revise the baseline itself. Some examples that drive a new baseline: A pandemic shuts down your offices for weeks and there will be an overall schedule slide. A major issue was found that requires rescheduling all downstream activities to account for the resolution. High level preliminary plans are now detail level working plans, which require shifting many dates due to greater knowledge. Budget changes mean either accelerating or stretching out a project to match the funding levels. Re-baselining a project schedule can be driven by a scope change, but to avoid unnecessary work for everyone downstream: If changes are relatively small and isolated, then update the detail level plans but don't revise the baseline. If there are major shifts to significant milestones, or many different changes required throughout the plan, then create a new baseline so that the plan is clear and everyone is able to align their own work to the new plan. 
Jason Eberhardy
Oregon, Wi, USA
Mar 25, 2020 10:14 AM
Replying to Andrew Soswa
...
Let me edit my reply, does anyone know what baseline is used for?
What's your initial response/reaction? Are you asking regarding baselining a project or a schedule? To me the project schedule's baseline is the approved version of a schedule that serves as the basis/starting point for how the rest of the project actually goes, so that the team and executives have something to measure against for the actual results of how the project goes. ...
1 reply by Andrew Soswa
Mar 25, 2020 11:53 AM
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.
Mar 25, 2020 11:28 AM
Replying to Jason Eberhardy
...
Hello Andrew,What's your initial response/reaction? Are you asking regarding baselining a project or a schedule? To me the project schedule's baseline is the approved version of a schedule that serves as the basis/starting point for how the rest of the project actually goes, so that the team and executives have something to measure against for the actual results of how the project goes. 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. ...
1 reply by Rami Kaibni
Mar 25, 2020 7:29 PM
Rami Kaibni
...
Very well said Andrew - Spot On !
Arthur Johnson
Managing Partner| Ecosistemica Engenharia e Meio Ambiente Ltda
Porto Alegre, Rio Grande Do Sul, Brazil
I guess it depends on the type of project and how predictable your tasks can be.
In construction, for instance, you have an overall idea of which tasks will be performed and how long they'll take. So you could set a baseline for the entire project earlier on, given you take the time to detail the tasks on a more granular level. I, however, prefer to use a more phased approach. As in: detailing the 1st phase, leaving the remaining ones on a higher level (defining at least a completion target), setting the baseline and adjusting it as the upcoming phases become clearer. In the end, you even compare what was your initial target and how far/close you've managed to achieve it, thus giving insights on how to become more precise for the next project. 
Yes, sometimes baselines are moved during the project. I suspect millions of projects will re-baseline due to the COVID-19 pandemic.
David Portas
Ny, USA
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.
...
1 reply by Andrew Soswa
Mar 25, 2020 8:17 PM
Andrew Soswa
...
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
I tend to see a baseline schedule as part and parcel of an agreement; the charter, a letter of understanding or even a contract. It represents the third element of costs (budget), scope and time commitments. .
"This is how we see the project at this time and agree that it meets our requirements." Ultimately the final results will have to be compared with what we set out and agreed to do. There may be mutually agreed to revisions along with cost and scope adjustments however version 0 is cut in stone. |
|||
Please login or join to reply
ADVERTISEMENTS
|
"Each problem that I solved became a rule which served afterwards to solve other problems." - Rene Descartes |
