P6-QA in the Real World

Before becoming an implementation specialist at Emerald Associates, I was a project manager and P6 administrator in a state government transportation agency for several years. I was responsible for managing 50-60 Primavera P6-EPPM (Web) project schedules and monitoring them to schedule completion. These projects were for the engineering and design of highway projects including tasks such as road maintenance, new road construction, bridge maintenance, and signals upgrades.

Plan Development - Kick-off meeting

To put together the project's plans, we started with a kick-off meeting to verify the full scope. These projects typically ranged from 500-1500 tasks and ran for 24 to 60 months depending on funding each year and priority. At the kick-off meetings, with a hard copy template schedule in hand, each department head would discuss their role in the project and request adjustments to the schedule accordingly. As the project manager during these meetings, I took note of any deletions, additions, relationship changes, duration changes, etc. required to the schedule and with some project teams we made the changes directly in P6-EPPM in a Reflection Project. The schedule changes from the kick-off meetings ranged from minor to significant. Once I made the changes to the project schedule, a 'final' draft was sent to all the team members who participated in the kick-off meeting so we could get comments and approvals in time for our submission deadlines. If no comments or changes were made, the 'final' draft schedule was accepted and the project moved ahead.

Monthly Updating

Progress on the projects was done on an ongoing basis, with scheduling being done nightly. Project updates including scope changes, adding new tasks, removing unnecessary tasks, and rearranging tasks that needed logic changes were done when needed, via email from the initiating department. I would make changes on a Reflection Project and send the new schedule out for approval, if the float remained positive. If the changes caused the project to fall behind or if a large setback was identified, a schedule review meeting would be held with all the main players in the project. At the meeting, the key players in the schedule's creation and project manager would all gather and review the schedule for the project. Changes would be done on the fly in a Reflection Project and re-scheduled during the meeting, when possible. If many significant schedule changes needed to be made I would note these changes and complete them after the meeting so we didn't waste time during the meeting itself and I'd send out the new schedule for the project team to review and approve again.

Now theoretically the project schedule should have been fully reviewed by everyone involved. Unfortunately, this was not always the case and errors were commonly found within the updated schedule as the project progressed. There were a few reasons for this: Sometimes as a result of the dissolution of various activities, one activity would be 'overloaded' with unnecessary relationships and odd relationship types, often to the same activities, which would impact the schedule calculations. Also, periodically, there were problems with added activities that may have had relationships that were not added or added incorrectly or perhaps a duration was added incorrectly. Sometimes, a new activity ID would be entered incorrectly without notice. In essence, there were any number of things that could have negatively impacted our schedule quality. If only I had a tool available to check the nuances of the schedule for me and flag them, so I would know where to look. Little did I know there was a tool out there that would have saved me countless hours reviewing and analyzing this schedule.

If I had had the P6-QA tool to help in analyzing my schedule after changes were made and before the schedule was sent out, I could have sent out a schedule that would have automatically been checked for logic, logic types, missing codes on the activities, activity ID format and other business process checks that we could have created specifically for our needs. The use of P6-QA would have cut down the time it took me to send out revised schedules from several days to less than one.

Having P6-QA there to act as my safety net on the project changes as they were made would have been extremely helpful to ensure the changes made sense and did not negatively impact other parts of the schedule. I could have run the P6-QA check while everyone was in the meeting, let it pinpoint possible problems, and then discuss those issues with the team immediately. This alone would have saved me multiple e-mails back and forth after I analyzed the schedule after the team meeting.

I am positive buying P6-QA would not only save any company time and money, it would help them produce quality P6 schedules.