Steve,
One more question. I did get the critical path to calculate properly after
applying your suggestions.
As a test - I added back some Must Start On constraints which then affected
the critical path. The tasks that I am trying to add are software parallel
dates - they must happen on these specific dates - due to the company's
financial calendar. How can I reflect these dates properly without
negatively affecting the critical path calc?
Thanks again,
Darin
Darin,
Steve and I have a long standing debate on the use of constraints, so
I'll give you a different interpretation of how they are used. I
believe that they apply to more than eclipses of the sun. What would
be the point of even having them? The criteria of "no force on earth
can prevent them from happening" seems extreme to me. They way I use
them is that it's deemed crucial to the Project that this event happen
on time. This does not mean something like, "management would like it
to happen", but something like, for example, a scheduled event that
needs to take place or major problems will arise. A specific example
might be a meeting to bring together project stakeholders to discuss
key issues on the project. If You've planned it for Monday, Sept. 12 a
month in advance, and a hundred people have bought airline tickets and
reserved hotel rooms, not to mention opened time in their schedules
for a couple of days that week, you can hardly ask them on Friday the
9th to postpone the trip a week or two. It must happen at that time,
barring acts of nature, etc. This is an appropriate situation for a
MSO constraint. Others might be announced product rollouts, government
mandates, training, etc. There are lots of things that are cause for
MSO or MFO constraints, but they aren't usually daily kinds of
events.
In dealing with these, they can create slack, and cause your CP to
dissappear. When you have an "M" constraint (MSO or MFO), and the work
that needs to be done afterwards doesn't fill the time between that
and your end date, or another "M" constraint, God forbid, you have
slack in your schedule. There's no way around it. It's a fact of life.
Like many unpleasant facts of life, we can pretend it's not so, or
address it.
The way I address this particular fact of life is to insert a dummy
task after the string of tasks following the M task, right before the
Finish Milestone (or the next M task). For example, if I have a task
that must finish on Sep. 12, and the end of my project is four weeks
later, and I have 3 weeks of work to do in that four weeks, the "M"
constraint has caused a week of slack. That's reality. And there's no
CP from that point forward because of that week of slack. So I just
put in a dummy task with a week duration at the end of the string of
tasks following the M task. That replaces the slack with a phony task
and restores your CP. If any of the tasks in that part of the schedule
slips, it will try to put off the end date. When you see that
happening, you simply decrease the duration of your dummy task
accordingly and restore your end date to it's planned date and restore
your CP. Hopefully, there are not too many of these, and there
shouldn't be.
Of course, the opposite can occur. You don't have sufficient time
between the M task and the Finish Milestone to get the work done. Four
weeks of work in three weeks! This is even more common. And this is
dealt with by attacking the CP, as in most schedules. Nothing at all
new here!
I hope this helps give you a real world solution for your real world
problem. Scheduling is a pretty exact science, but it does require
flexibility in application to make it fit with reality and still
function as intended.
Best of luck. Let me know if you need further assistance!
