none
Question / Baseline Usage

    Question

  • Hi folks,

    Dale assures me that I should be using baselines for my projects, but I haven't quite figured them out yet. Here's why:

    I've always thought of a baseline as saying "This is what I expect the project schedule to be" so that later I can compare to that baseline and say how we're doing compared to that baseline.

    I manage primarily software development projects, and they tend to be pretty grey early on in the planning. We don't really use a PMI methodology and create a detailed WBS before anyone starts. As a result, I'm always kind of afraid to create a baseline, because I never really seem to reach that point where I'm pretty darned sure this will be the project schedule. And I never DO reach that point until after some of the tasks are complete/underway.

    So, what am I missing? Is there a value to using baselines when your company's project management methodology is a little . . . loose? Convert me! :)

    ~Steve


    • Edited by sbattisti Thursday, December 01, 2011 7:32 PM
    Thursday, December 01, 2011 7:31 PM

Answers

  • Steve,

    Yeah, this probably should be a new post, but since it's already here, this is my "take" on your scenario.

    What you do for this scenario is really up to you. If you manage your project on a weekly basis and want to really keep it as accurate as possible, then yes, you can re-allocate the tester resource to 60% now and then adjust it again next week if necessary. Or, if another tester is available, you could temporarily assign he/she to the task to maintain schedule.

    You seem a little unsure whether the reduced test time will in fact impact the overall schedule, but if you reduce the tester resource allocation there certainly is a less likely chance of finishing by the end of this week, unless the original test effort estimate was very "iffy".

    If you make the re-allocation now the schedule will reflect an immediate red flag before it happens. If you leave the allocation as is, the schedule won't reflect that it's in trouble until after the week is complete. However, keep in mind that if you are entering actuals on a daily basis, regardless of the planned schedule, the variances will tell you things are going astray and you can take remedial action. Hey lookie there, a good reason to set a baseline!

    One thing you need to be wary about. You must balance the detail of your schedule with the effort you can afford to spend on it. Some people like to create a schedule with a very high level of detail. As a result they may spend an inordinate amount of time maintaining that plan with what will end up as non-valued added effort. A good plan is one that has sufficient detail to describe the plan such that it is meaningful and beneficial to the stakeholders. It's a delicate balance.

    John

    Monday, December 05, 2011 4:09 PM

All replies

  • Steve --

    In your situation, my simplest recommendation would be that you baseline the project when you know the confirmed schedule, even if some tasks are already in-progress and completed.  Remember that when you baseline a project, Microsoft Project 2010 captures a number of important values for every task and resource.  These include, but are not limited to, the following task fields:

    -- Baseline Start
    -- Baseline Finish
    -- Baseline Duration
    -- Baseline Work
    -- Baseline Cost

    Once you have baselined your project, you can track and analyze variance using the Tracking Gantt view, along with the Cost, Work, and Variance tables for tasks.  Hope this helps.


    Dale A. Howard [MVP]
    VP of Educational Services
    msProjectExperts
    http://www.msprojectexperts.com
    http://www.projectserverexperts.com
    "We write the books on Project Server"

    Thursday, December 01, 2011 9:10 PM
  • Steve,

    First, I'm not here to "convert" you, but to perhaps put things in perspective.

    I fully realize how "loose" development programs can be. In my former line of work development effort, whether hardware or software, was full of unknowns. However, most programs desire or are even required to develop metrics to gage a program's progress to the desired progress. Is the project on schedule (as least as far as the stakeholders understand the schedule at this moment), or are things unraveling such that some workarounds or maybe even a new plan is needed. In order to develop those metrics, a method is needed to compare where the project is against where it should be. Thats where a baseline comes in. It puts a "stake in the ground" for the original plan so that it can be measured against the current schedule. It's a reasonable measurement approach. Most of the time it is even carried into the full array of earned value metrics. If a point is reached where it becomes clear that a major change is needed, a new baseline can be set, either using one of Project's multiple baselines (there are 10) or by updating the original baseline.

    As far as a WBS, it doesn't have anything to do with baseline. A WBS is used primarily to provide a functional or cost center tracking for the program. Unless you are self-funded I can't imagine not having some type of WBS to track the effort. It certainly does not have to be detailed down to the lowest level. A WBS at the first or second level of indenture is often more than sufficient.

    I'm assuming others will chime in with their thoughts. Meanwhile, I hope this helps.

    John

    Thursday, December 01, 2011 9:26 PM
  • Thanks folks.

    I guess need to just dive in and create a baseline, rather than waiting for the mystical "project plan that is complete before any work happens."

    I suspect that a good place for a first baseline for the project would be whenever the planned schedule is communicated to management / sponsor / client or whatever...

    ~Steve

    Friday, December 02, 2011 7:10 PM
  • Steve --

    You are definitely on the right track, my friend!  :)


    Dale A. Howard [MVP]
    VP of Educational Services
    msProjectExperts
    http://www.msprojectexperts.com
    http://www.projectserverexperts.com
    "We write the books on Project Server"

    Friday, December 02, 2011 7:42 PM
  • Steve,

    You're welcome.

    The best time to set a baseline is after the project is laid out and agreed to by the stakeholders. When I say "agreed to" I mean that you, the people who will be performing the tasks, your management and your customer/client review the plan and to the best of their combined knowledge all say, "yeah, this looks like it will work." That plan of great expectations may all get flushed away as soon as it hits the first major obstacle but that's what project management is all about and you can always reset the baseline.

    John

    Friday, December 02, 2011 7:51 PM
  • Well, about that...

    So, let's say we do what you suggested. Everyone agrees, and we set a baseline.

    We start going through, say, the analysis piece of the project. In doing so, we are able to more effectively define and estimate the tasks that will be required in a subsequent phase of the project. 

    In a case like this, after I have changed the estimates and added/removed some future tasks, is this a time to create a new baseline? Or is this simply tracking changes against the ORIGINAL baseline?

    That's what confuses me in terms of managing things throughout the project as tasks get added or removed, or re-estimated.

    Thoughts?

    ~Steve

    Friday, December 02, 2011 8:08 PM
  • Steve --

    In my opinion, your old Baseline is no longer valid since you added and removed tasks.  If it were me, I would simply rebaseline the entire project in the Baseline set of fields to reflect the new agreed upon schedule for the project.

    If at any point during the life of the project you should add new tasks through a change control procedure, then I would recommend you baseline ONLY the new tasks, again using the Baseline set of fields.  This way, you can analyze variance on the new tasks as well as original tasks without overwriting the baseline information for the original tasks.

    Hope this helps.


    Dale A. Howard [MVP]
    VP of Educational Services
    msProjectExperts
    http://www.msprojectexperts.com
    http://www.projectserverexperts.com
    "We write the books on Project Server"

    Friday, December 02, 2011 9:06 PM
  • What is a "change control procedure"?

    (Haha, kidding. :) )

    ~Steve

    Friday, December 02, 2011 9:08 PM
  • Steve,

    This is what we did with development programs. The total program was scoped with a statement of work, (later called a statement of objectives), and a defined contract budget. It might have been fixed, cost plus or whatever.

    Most often with a development effort everyone knows where they need to go but the full details of how to get there are not necessarily well defined (i.e. unknown unknowns). However, the major accomplishments, (e.g. milestones), and phases are pretty well understood. After all, they are in this business, they better know what they are doing, and most likely have past history on similar programs. The stakeholders also probably have a pretty good idea of program detail execution for the near term. That may be a few weeks to a few months. Beyond that, the best they can do is to scope the longer term effort as undetailed follow-on phases. We called them planning packages. They consisted of a summary line description with an estimated work content and a budget. As the program approachs each planning package, say within a few months of it, that summary detail is expanded into working detail. That allows the plan to be dynamic and unfold as the longer term unknowns become known. When planning packages are expanded into working detail, the baseline for those tasks is set. Using this approach, the "stake in the ground" baseline "rolls" with the dynamics of the program. If it is determined that a major change in scope is required, that work is laid into the plan either as separate detail or as a modification to the long term planning packages. New or revised baselines are set as needed.

    We statused once a month with a full program review, sometimes including the customer. We also had periodic major milestone reviews (e.g. specification review, initial design review, intermediate design review, software design review, etc.)

    Lots of way to get there but again, the whole idea of baselining is to provide some "base" for measuring how you are doing against your plan.

    Hope this helps.

    John

    Friday, December 02, 2011 9:08 PM
  • Change Control Procedure = A daily occurrence over while the project manager has little or no control!  :)


    Dale A. Howard [MVP]
    VP of Educational Services
    msProjectExperts
    http://www.msprojectexperts.com
    http://www.projectserverexperts.com
    "We write the books on Project Server"

    Friday, December 02, 2011 9:44 PM
  • Dale,

    Sorry, I can't pass it up.

    I'm a little confused. Is it a daily occurrence while the manager has no control, or over which he has no control. Please clarify :-)

    John

    Friday, December 02, 2011 10:39 PM
  • John and Dale have great points here as usual but I have often had clients do something like the following:

    Create a rough plan based on what you know up front. for some of the later stage work this might be pretty high level. Create it anyway and then baseline it.

    Never change that baseline. Make it baseline10 or something out of the way but leave it as it is.

    If a major change happens make your changes and and put them into one of the other baselines. As you know more about the later stages you can update their baseline information by selecting those tasks and saving the baseline for just the selected tasks.

    With all of this keep a log somewhere of what each baseline change was about (scope change, rolling wave update for the later stages, etc)

    Then you have the baseline10 to show the high level up front ideas of the schedule and the 10 other baselines you can use to compare progress against the more realistic data.


    Brian Kennemer – DeltaBahn Senior Architect
    endlessly obsessing about Project Server…so that you don’t have to.
    Blog | Twitter | LinkedIn
    Saturday, December 03, 2011 2:54 AM
  • Steve,

    Here goes with some thoughts about the baseline. It is all very well to be able to look back at how the plan was at some time in the past, perhaps just after the first bit of planning was done and before the execution started,  and to be able to compare that with how the plan is now, or with how the project ended up when it was finished. Everyone would like to be able to see that comparison, and I guess there may be something to be learned from it.

    A baseline allows some of the calculations and functionality in MSP to work as designed, such as Variance and Earned Value and if there is no baseline then those calculations just can't be done.

    However, a baseline may be quickly superseded and rendered irrelevant by events and circumstances during execution, because everything changes, perhaps by only a little or perhaps by a lot. There is not much use in pining for the baseline when the achievement of the project objectives demands that you look forwards rather than backwards.

    One thing that I often see in construction projects is that the baseline is often written into the contract by the lawyers as though they expect that it will not change, because lawyers crave certainty, even more certainty than is possible with something which is inherently uncertain. The building contractor is supposed to be contractually obliged to work to the baseline plan even after it has become irrelevant, and perhaps have to explain why the project is not proceeding according to the baseline plan. Sometimes the contractor has abandoned the plan because it was never any good in the first place. Sometimes the contractor is changing the plan as the project proceeds in a way that is appropriate and necessary. Sometimes the contractor just chooses to ignore the plan from the start because he can't see the value in it, or the desirability of having a plan that can be worked to and then working to it.

    The thing which makes a baseline useful, and keeps it relevant for as long as possible, is to make sure that he plan is very complete and worked out in sufficient detail, and agreed all round, before the project starts execution. Often, however, this is just not done.

    Saturday, December 03, 2011 4:06 PM
  • Hello All:

    This is a great discussion and one that I have had several times with many project sponsors.

    Steve: Eveyone here has provided excellent answers for the reasons to use a baseline.  Every project has unknowns before they start and no project would ever get started if we waited until they were knowns.

    John:  I would respectfully disagree that the WBS does not have anything to do with a baseline.  When you save a baseline this is the agreed upon scope of the project (this is just one part of what PMI calls your scope baseline).

    When you remove scope from a project (hopefully through some form of formal change control system), I never recommend that it is simply deleted from the task list.  I always recommend that the tasks be set to a duration of zero and the baseline (just for those tasks) should be updated.  Your next step should be to place a note on that task explaining why it was deleted and perhaps insert a copy of the approved change request that removed it.  This prevents the lawyers from having a field day with your project file in court. 

    My two cents....


    Gregg D. Richie, PMP, MCTS; Author, Microsoft Project 2010, Microsoft Official Academic Course Series
    Saturday, December 03, 2011 6:26 PM
  • Gregg,

    My comment about WBS and baseline being independent was based on Steve's initial comment that they don't create a WBS and therefore he is reluctant to create a baseline. As I'm sure you are well aware a WBS normally tracks the funding while a baseline is used to track progress metrics. A plan can be created and executed without a WBS and it can also be created and executed without setting a baseline. Is it prudent to do either? Generally not. But the WBS and baselines are independent parameters.

    John

    Saturday, December 03, 2011 9:32 PM
  • Dale,

    Sorry, I can't pass it up.

    I'm a little confused. Is it a daily occurrence while the manager has no control, or over which he has no control. Please clarify :-)

    John

    Yes. :-)
    Sunday, December 04, 2011 4:29 PM
  • John,

    Point taken and understood...thanks for the explanation.


    Gregg D. Richie, PMP, MCTS; Author, Microsoft Project 2010, Microsoft Official Academic Course Series
    Monday, December 05, 2011 4:13 AM
  • Wow, this is tremendously helpful, folks, especially getting multiple opinions.

    So, perhaps this should be in another thread, but let me ask a question based on a meeting I had today:

    Let's say I've set up my plan, and created a baseline. In this plan, I have a tester working 80% on a series of linked tasks this week. In today's meeting, I learned that this tester will be spending time on an unrelated project, and therefore will only be spending 60% of her time this week on my tasks.

    What is the "best practice" for dealing with this? I could change her assignments on those tasks to 60%, but if we make it through this week and they aren't complete, she will be back to 80% next week. If I leave her at 80%, though, the plan doesn't really reflect what I expect to happen given this new information.

    Thoughts?

    ~Steve

    Monday, December 05, 2011 3:10 PM
  • Steve,

    Yeah, this probably should be a new post, but since it's already here, this is my "take" on your scenario.

    What you do for this scenario is really up to you. If you manage your project on a weekly basis and want to really keep it as accurate as possible, then yes, you can re-allocate the tester resource to 60% now and then adjust it again next week if necessary. Or, if another tester is available, you could temporarily assign he/she to the task to maintain schedule.

    You seem a little unsure whether the reduced test time will in fact impact the overall schedule, but if you reduce the tester resource allocation there certainly is a less likely chance of finishing by the end of this week, unless the original test effort estimate was very "iffy".

    If you make the re-allocation now the schedule will reflect an immediate red flag before it happens. If you leave the allocation as is, the schedule won't reflect that it's in trouble until after the week is complete. However, keep in mind that if you are entering actuals on a daily basis, regardless of the planned schedule, the variances will tell you things are going astray and you can take remedial action. Hey lookie there, a good reason to set a baseline!

    One thing you need to be wary about. You must balance the detail of your schedule with the effort you can afford to spend on it. Some people like to create a schedule with a very high level of detail. As a result they may spend an inordinate amount of time maintaining that plan with what will end up as non-valued added effort. A good plan is one that has sufficient detail to describe the plan such that it is meaningful and beneficial to the stakeholders. It's a delicate balance.

    John

    Monday, December 05, 2011 4:09 PM