Project Management Central
Please login or join to subscribe to this thread
|
|||
|
|||
Rami Kaibni
Community Champion
Senior Projects Manager | Field & Marten Associates
New 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. 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.
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 |
Please login or join to reply
ADVERTISEMENTS
"I don't like work - no man does - but I like what is in the work - the chance to find yourself." - Joseph Conrad |