How to Clean up Your Oracle Primavera P6 Database

Over time, your Primavera P6 database will grow and become tough to manage at times. This is not necessarily a bad thing, as some functions and global changes may actually be used in future projects.

However, a project management database within the Primavera P6 database can grow so large that it causes the computers to run slow, perform basic functions at a slower rate, and is incapable of being useful due to repetitive, confusing terminology and abbreviations and names. Follow these four steps to clean up your Oracle Primavera P6 database and improve your production through Primavera P6 schedules.

1. Rename Tasks, Activities, and Milestones With Appropriate Comment

Project managers have a tendency to abbreviate titles within the names of activities, rules, schedules, and tasks. For example, completing the slab of cement concrete for the first floor maybe abbreviated with one SLB.

However, multiple projects with the same abbreviation may actually cause a project manager to accidentally use the constraint and resources for one project in another project schedule mistakenly. The best way to avoid this problem is to rename the abbreviation of each aspect of the project with a month and the year, in addition to the existing abbreviations identification.

2. Remove Extra Copies of Schedules If Previously Saved

Whenever a project manager’s tasks are delayed or incomplete, the schedule cannot be returned to the previous state. However, project managers can avoid the potential loss of data by creating a backup copy of the schedule each time, when making a global change. If a project manager makes a total of 100 global changes per month, at an average of three global changes per day, this could account to more than 24,000 pages over the course of 2 years, which results in 24,000 extensive copies of the project schedule in the Primavera P6 database.

As a result, project managers need to delete the extra copies of each schedule upon the successful completion and delivery of each project. One copy of the final schedule may be kept for a period of six months to one year after delivery, but that is one copy per project.

3. Eliminate Time Blocks According to Weather Forecast

Depending on the progress into your project, you may have allocated extra time in your project schedule and within the database to account for potential risks, such as inclement weather. Unfortunately, each aspect of the schedule that is blocked out for one of these issues results in blockages within the primavera P6 database.

Furthermore, these blockages can be confusing when accessing the schedule at a later date, especially if accessing the schedule after the successful completion and delivery of the given project. Therefore, the project manager should have returned to the enterprise Primavera P6 database and remove any inaccurate copies of the schedule as soon as possible. This goes back to updating the schedule on a frequent, recurring basis.

4. Remove Global Change Roles That Are More Than One-Year-Old

As mentioned earlier, global changes are one of the only ways to change the appearance of variations when changing a schedules work week. Unfortunately, creating dozens of global rules to account for each change in the project work week will lead to the creation of many different rules set forth in the Primarvera P6 database. Although keeping a general rule sets in place is a good idea for a future access and use, project manager should try to limit the number of rule sets in existence to less than 10. This will keep the most active role sets available and eliminate the waste from unused, rare sets.

No one wants to think about the need to clean the Primavera P6 database. However, Oracle Primavera P6 cannot function at its full capacity when clogged with extensive lists, roll sets, and the factors that are not being used. At the end of each project, or at least once per year, the project manager should clean up the Primavera P6 database with these four actions.

Key Takeaway

• Rename tasks, activities, and milestones according to month, year, and logical abbreviations for each action.
• Remove extra copies of the schedule if previously saved. Block time that has been put away for potential project delays as the project approaches completion.
• Remove global change rules that are more than one-year-old or rarely used.