Craig,
Kind of an open-ended question with lots of possibilities which may or
may not be appropriate for your situation (which from the information
you provide I can only imagine).
Some random thoughts in no particular order (except for the first which
I deem essential):
: make a team rule that any changes the result in changed finished dates
(or other things you care about) must be informed to you by the person
making the change. (If they don't inform you, you remove their rights to
the file to make changes). Even if you cannot enforce this automation
(practically), IMHO the people involved in the project must have this
attitude.
: remember it is normal (and desired) for Project to recompute project
end dates as the project progresses. You *want* Project to give you an
indication of the current forecast on end date, which can and should
change on every update of the plan. (If you have hard-coded finish dates
on tasks then Project isn't being used as it is intended to be used).
: ensure the plan is baselined so you can remember the basis you are
trying to compare to. (However, people who have access to the file can
change these baselines should they be so inclined ... reinforces the
need for the first item).
: remember it is hard/impossible to lock down the contents of anything
in the MPP file. Once opened, anybody can change anything. The only
control you have is granting access to the file to a) get it, and b) put
it back (via email, file shares, document management check in/out
process, whatever ...). The key control risk is having the permissions
to put the file back into the "official" place for re-use by others with
the possiblity of a "wrong" change becomes "right" simply by being
published.
: Project provides a handy field called Deadline. Put deadlines on key
milestones on tasks that you want to watch. As long as recomputed
finish dates are within the deadline, do you really need to immediately
know that a change to the plan occurred.
There are surely other things to consider that are perhaps more relevant
to your team and organisation.
--rms
www.rmschneider.com