Project’s request to restrict access of other Users to their project schedules & portfolios seemed to have failed. Unauthorized access remains a problem. Contractors working concurrently in the same database were able to sometime see the client’s schedule and modified certain critical attributes despite the security protocol being enforced. Worst of all, one schedule was completely deleted by someone and have to be recovered from the back-end by the Database Administrator through the existing back-up and recovery protocol.
Dorothy was checking Marco’s security access because he couldn’t add resources and found that all his projects have the Responsible Manager’s Code set to the Contractor’s OBS code. She figured that Marco might have used the contractor’s original schedule as a starting project file in developing his project schedule.
Back in June 2010, Primavera User John and Mark had put together a schedule that sat on the back burner while the Project team worked on other priorities. When it came time to set the baseline, John and Mark decided to do a quick check to make sure nothing had changed. Mark hit the F9 button and about 80% of the activities moved to the right. The dates moved by 4 to 20 days.
The two of them checked the calendar they were using but they were fine. The Primavera database Administrator checked who else was using the calendar and the schedule and found that only John and Mark were given direct access to this schedule.
John now went back to the schedule, changed some lags and logics trying to correct the schedule discrepancies. The effort took more than a day to complete, time which the project really do not have. What has gone wrong?
Find out what happened. Read the full article by clicking the hyperlinked button below.
