For more slides and tutorials visit www.p6academy.com Source: Collaborate 14

1. COLLABORATE 14 Copyright ©2014 by Ivan Rincon Page 1
IMPLEMENTING PRIMAVERA P6 8.2 - THE JOURNEY
Ivan Rincon, B.Eng., MBA, PMP
PMO and Change Manager
BC Ferries
Abstract
When facing the challenge to implement a brand new EPPM solution from scratch, the journey seems long and
challenging. It is! After two years of this long process, many lessons learned have shown what needs to be done
and what should be avoided. From technical to functional to organizational aspects, the implementation of an
Enterprise Tool like Primavera P6 creates a series of new questions and creative solutions. One of the most
challenging aspects is to move form a desktop-based UI to a web-based application. Some of the typical aspects to
be considered are:
1- Technical (Desktop Configuration, Server Architecture)
2- User Training
3- Procedures and processes
4- Organizational Change Management
It does not matter if your organization is just considering to use the tool or has already adopt it, this paper will
highlight the most critical aspects to make your implementation and adoption successful.
Starting point
Every journey starts with the first step. When deciding the approach to implement your EPPM tool, you need to
assess the following elements:
Objective: is P6 going to be a scheduling tool, a project tracking and status reporting tool, and/or a portfolio
management tool? Each one of these objectives will drive a complete different path to implementation. More
often than not, organizational objectives will drive the implementation objective. For example, if strategic planning
has shown that portfolio management is a key strategy, the implementation needs to focus on the “portfolio” side
of P6.
Project and Portfolio Management Maturity: Primavera P6 will NOT resolve an organization’s project and portfolio
management woes. Quite the opposite; adding an EPPM tool to the mix can add complexity to project and
portfolio management practices and create more confusion than bring up solutions. The organization must be
aware of their strengths and weaknesses, and focus on opportunities from improvement over an existing baseline.
Technical maturity and capability: Primavera P6 is not an easy tool to deploy. Resources need to be available in the
following areas: Server deployment, Database implementation, desktop management, functional Oracle SME (if
integration is required), and Solution Architect. It is highly recommended that these resources know the tool and
have some basic understanding of its architecture before the actual implementation starts.

2. COLLABORATE 14 Copyright ©2014 by Ivan Rincon Page 2
First Steps
Once the basic elements outlined above have been considered, the actual project can start. As with any other
project, a charter needs to be in place to document the pre-existence of the conditions to successfully engage all
stakeholders.
The first critical stage of the implementation project is the functional requirements gathering. The implementation
of an EPPM tool like Primavera requires input from several stakeholders. Especially important are: project
managers, PMO, portfolio managers, functional managers, reporting structures (CxO or VP), project analysts, and
schedulers.
Implementers need to be aware that Primavera P6 out-of-the-box does not contain any standard elements and
everything needs to be configured from scratch. As a result, configuration requirements need to go down to a very
detailed level (no assumptions can be made). This is particularly true for roles, security, enterprise structure and
their corresponding rules.
Another important element is the definition of processes to be supported by the tool. It is important that those
processes be analyzed for any gaps and remediation can start as soon as practicable possible. It may also drive
some of the functional requirements, in case existing processes require customization of the base product.
Lastly, the technical aspects of the deployment need to be carefully considered. At this point, the engagement of a
knowledgeable architect (or an Oracle Partner) is a desirable aspect. If the organization does not possess strong
practices around environment and configuration management and deployment, this may be a difficult obstacle to
overcome down the road. Primavera P6 8.x is architected as a web-based application and, therefore, each one of
the tiers deployed requires special consideration. Some of the parameters include geographical distribution, type
of clients to be used, migration and back up, and type of integration strategy (batch vs. online). If the organization
currently stores and uses project data, special consideration needs to be taken as to what will happen with this
data and which one will be the system of record after the P6 implementation. Reporting and BI are two other
components to consider, especially if the organization uses other tools.
Implementation underway
Once the implementation is underway, many activities will steer the project towards the end success. Using the
“people, process and technology” approach, some of those key activities will be highlighted.
Organizational Change Management: The success of the implementation of Primavera P6 is as much about
technology as it is about the acceptance and usage of the tool. Unless the organization comes from a background
of usage of Primavera, it is very likely that some actions need to be taken to bring users to be comfortable with the
tool. Aspects like communication, training and impact assessments need to be considered as key aspects of the
implementation project.
If future schedule users are used to have a tool on the desktop, it will be a great change to deal with a web-based
application. If they are used to just share information when they forward or submit a file, they have to be used to
work in a more transparent environment where it is expected than collaboration is the norm. In order to do that,
the implementation team needs to ensure that users understand the differences between the existing platform
and the new deployment.

3. COLLABORATE 14 Copyright ©2014 by Ivan Rincon Page 3
On the portfolio side, if processes are not migrating from an existing tool, people need to be aware of the
capabilities of Primavera and embrace the concept of the use of a tool designed to share information. Even where
there is a tool in place, the same concerns about “losing control of the information” need to be eased as early as
possible.
This is also the time to address the gaps found in the early stages of the project. If process re-engineering is
required, make sure the new processes are documented and properly communicated to all stakeholders. A typical
example is the reporting process. Primavera P6 is an excellent tool for reporting, but if stakeholders are used to
see a PowerPoint slide in their inbox every two weeks, they will need to be made aware of the expectation of
accessing the tool to get the most up-to-date information about the project portfolio.
Another key aspect of the implementation is to be able to start training the technical support resources at the
same time that the implementation progresses.
On the technical side, one of the key elements of the deployment at this stage is to test the proper desktop side
configuration. Primavera P6 is very demanding on the Java version(s) able to properly support the tool on the
client side. This is particularly important for environments where other Java-based applications have different
requirements. Alternate desktop delivery models (like Virtual desks) can be explored and tested while deploying
the application.
Close to the end
As the cutover date approaches, a readiness assessment is a must. This is the proper point to ensure all
organizational aspects have been considered and the tool will be accepted. This is the also the moment where user
training needs to happen. Do not train end users well in advance or they may be unable to use the tool once it is
deployed just because they have forgotten the basics.
Processes should be validated with the business owners and, if a test or training environment is available, there
should be mock up runs for the processes. Stakeholders must feel comfortable about the use of the tool to support
the processes.
This is also a key point to test all integration points. As with any other deployment of integrated systems, thorough
testing cycles with multiple validation points should occur before the tool is considered ready for production. The
same principle applies to data migration, if required.
A good approach could be to pick a few key stakeholders and let them run their processes (create a schedule,
baseline, update, report, create a portfolio, etc.) in a near-production environment for a couple of cycles and
analyze the results. This can serve as a QA point for the project and find obvious issues with the deployment.
Incidentally, the same approach can be used for the super-users in those processes that will be performed in an
ad-hoc basis (create users, alter OBS, etc.).
Finally, this is the point to test your deployment strategy. Due to the disruptive nature of an EPPM tool, a gradual
approach must be considered as the best option over a “big-bang.” Think about moving functional areas into P6,
starting with the less critical or demanding and move into more complex areas once the first few wrinkles have
been resolved.

4. COLLABORATE 14 Copyright ©2014 by Ivan Rincon Page 4
The finish line
Hopefully at the end of the journey, following best practices as outlined above, there will be just a few things to
adjust to make the rollout successful.
The first area to review is user adoption. The implementing team has to make sure users feel comfortable with the
tool. Training refreshers are a good method of ensuring that any “user” gap is addressed. Also, the organization
may consider to phase-out the retirement of old tools. This way, users can feel the support of their habits while
they transition to the new environment.
The second area to focus is functional fit. It is not uncommon to find processes or procedures that need to be
adjusted OR adjust P6 to specific situation not considered in the original design. If the organization is not very
mature in Project and Portfolio Management practice, this should be the exception and not the rule.
The third area of focus is technical. As the different areas get into production, non-functional issues may arise.
Special consideration should be taken to performance as users and projects are on boarded. Also, if integration has
taken place, interfaces and jobs must be carefully monitored and results validated to ensure they are running
properly. Finally, user experience on the client side needs to be tracked and incidents logged for proper analysis.
The last area of focus is data quality. At the end of the day, the tool is useless if the data stored and presented in
the tool does not possess the quality expected by the organization. For projects, it important that project
managers properly enter and progress schedules, and assign resources. For portfolios, it is important that portfolio
managers validate dates, budget, risk profile, capacity plans, and any other variable that may impact the results of
the portfolio analysis. Consider the use of functional consultants to ensure you are truly following best practices.
Above all, make sure you have a patient, well-trained and customer-centric support team. They are the first and
last line of defense between a troubled user and an unnecessary escalation.
Conclusion
Implementing Primavera P6 8.x is not a trivial project. P6 is not an out-of-the-box tool that can be configured on
the fly and expected to provide support for all project and portfolio management related processes. As with any
other enterprise tool, it is expected that many aspects are properly managed as part of the implementation project
and all people involved understand the scope and far-reaching implications of deploying the tool.
If all these other aspects of the implementation project are top of mind for team members, stakeholders, partners
and any other resource involved in the project, the long journey will end with great joy.