What is the best way to develop a project baseline?

Question

I am conflicted on how to create a baseline for a project. Which of the following scenarios would be considered a "best practice" for creating a project baseline in which to measure progress and get some schedule-related EVM metrics?

Background: I have multiple project templates consisting of connected tasks that are resource dependent. Assume that these templates are used to create identical projects at some time interval.

1. Schedule all tasks "as late as possible" leaving the entire float at the front end of the project. This would assume infinite resources.

2. Schedule all tasks "as early as possible" leaving float at the back end of the project. Also assuming infinite resources.

3. Schedule each new project according to a master resource schedule. This would mean that any future identical project would potentially have a different baseline than a previous one.

4. Some hybrid of #1 and #2 with float distributed somewhat evenly prior to significant milestones in the workscope.

I see flaws in each of the scheduling scenarios above. What I need is to find some happy medium where I can baseline and report my project's performance in a consistant fashion.

Thanks in advance. RA

Answer 1

I think you are confusing two separate things here: Baseline and Scheduling.

I think a Baseline is a snapshot of a project plan at a specific point in time against which you can compare future plans to assess deviation from the plan.

This holds true whether you front-load your project scheduling, back-load it, or something in between.

You appear to be trying to create some kind of generic template for the project which can be reused in the future? That is not a baseline.

Maybe you have two goals here? 1) Schedule today's project to deliver the output as efficiently as possible 2) construct a reusable project schedule template

As you have pointed out, these goals can conflict. What is a good schedule for this project may not be a good schedule for a similar future project. If it were me I would concentrate on delivering today's project as efficiently as possible and definitely front-load the schedule to get as much done up front as possible before you hit inevitable snags.

Then I would learn from that to build a template that is as flexible as possible whilst retaining as much of the core efficiencies as possible without becoming impractical for future projects. I would probably do his by trying to keep blocks of project activities at a fairly abstract level and not get too bogged down in granular tasks. From there you can build a vision of what a most efficient resource contour is for similar projects and then resource appropriately for the future projects where possible. Or replan the abstract template as appropriate for the resource available at the time.

It's always going to be a trade-off between the reusability of the plan versus the flexibility of the resource pool.

Answer 2

You do not control your float that way. Float is a result of the planning values you choose per work package and the logic of the network you create based on task and resource dependencies. Packages are scheduled based on that logic and your duration planning values. To override that by arbitrarily trying to schedule late or early is merely changing your durations of your packages, thus creating new early and late start values.

No two projects are a like, no matter how similar the project seems. You can have a starting template, but you should have no policy that demands the PM of a new project to somehow stick to that template with little to no change. That is a recipe for disaster. Instead, you need to assess the risk condition of each project--your environment, your customer, legal issues, work issues, staffing issues like availability, whether you are competing for the work, and on and on--that will ultimately dictate the planning values you use.

This risk posture of the new project also dictates the planning values you end up with. For example, if your project is of high risk, you would be wise to choose planning values on the right side of the estimate distribution--vice versa if your risk posture is low.

There is a method of creating slack and building that into your project. I think this is called Critical Chain Project Management. This method calls for cutting your planning values in half and then using the balance as slack somewhere in your schedule. That's pretty much all I know about this method and I might have that wrong. Google it. It is very interesting.

Answer 3

I'm assuming that you have worked with your team to generate estimates for how long it will take to produce each deliverable. I'm further assuming that they have given you a most-likely case scenario and a worst case estimates for each.

Take the most-likely case scenario and create your schedule. Review this with your team against the master resource schedule and confirm that you have the team available to achieve this schedule. If enough of the team is NOT available you wll have to adjust your schedule to account for this, or get team members taken off of other projects in favour of your project, or introduce into your plan activities around getting new hires and training them up.

Once you have your most-likely case schedule aligned to team availability do the same thing for your worst-case scenario. The purpose of doing this is to allow you to report to your sponsors a range of dates for project completion. This will really help you in the long run in terms of managing expectations.

Finally, run the schedule past your team and get their buy-in. Document that they agree that the schedule is reasonable and achievable, ideally getting them to formally sign-off. Distribute the schedule and off you go.

In response to your specific options:

1.Schedule all tasks "as late as possible" leaving the entire float at the front end of the project. This would assume infinite resources.

Probably not a good idea because people will tend to put things off to the last possible moment. Also bad things tend to happen at the last moment. Using "as late as possible" for scheduling poses a significant risk to the project by not allowing for late delivery.

And assuming infinite resources is a very bad assumption.

2.Schedule all tasks "as early as possible" leaving float at the back end of the project. Also assuming infinite resources.

Better than #1, but I would tend to associate buffer with particular deliverables so that when there are internal hand-offs the receiving team is aware that a range of dates is possible. For example, the development team should be aware that requirements gathering and documentation should be complete by date XX but could be delayed by as much as 5 days.

Again, assuming infinite resources is not good.

3.Schedule each new project according to a master resource schedule. This would mean that any future identical project would potentially have a different baseline than a previous one.

By definition a project is a unique undertaking. Even if it is "cookie cutter" you will have different baselines. For example, a project in the USA that takes 3 months to complete if I start in September will likely take longer if I start in November (people are away over the holiday season) or in June (summer holiday season).

I also don't see why you wouldn't consult your master resource schedule so that you are able to ensure your schedule is realistic and achievable.

4.Some hybrid of #1 and #2 with float distributed somewhat evenly prior to significant milestones in the workscope.

This is more what I typically do, see comments under your option #2