Implementation demystification 10 keys to a successful p6 implementation white paper

COLLABORATE12 OAUG FORUM © Microdesk, Inc 2012 1 | P a g e
#10580 - IMPLEMENTATION DEMYSTIFICATION: 10 KEYS TO A SUCCESSFUL P6
IMPLEMENTATION
Date:
Sunday, April 22
4:30 pm - 5:30 pm
Location:
Banyan E
Product Line:
Primavera
Description:
You’ve identified a need to improve project management processes in your organization, and
you’ve invested in Oracle’s Primavera P6 software. Now what? Surveys have shown that 50-70%
of projects don’t deliver the expected results due to unsuccessful implementations. In this
session, we’ll address the top 10 ways to ensure your implementation is a success. Learn to
effectively resolve pain points, master best practices, and conquer common traps of unsuccessful
projects.
 Objective 1: Uncover your organization’s project management pain points and solutions
to address them
 Objective 2: Learn how to master project management best practices using Oracle’s
Primavera P6
 Objective 3: Discover the top 10 implementation risks of unsuccessful projects and how
to avoid them
A White Paper by Elaine Krazer, PMP
Oracle Certified Implementation Specialist
Implementation Demystification:
& 10 Keys to a Successful P6 Implementation

By Elaine Krazer, PMP
Senior Primavera Consultant, Microdesk
P6 Product Lead for the Board of Directors, OAUG OPSIG

CONTENTS
Introduction......................................... 4
Problem Statement............................. 4
Previous Options................................. 4
The Solution ......................................... 4
Summary ............................................. 4
What Causes Project Failure? ........... 5
The Top Ten!....................................... 19
BENEFIT 1
Gain benefits of an enterprise system, and
minimize the risks.
BENEFIT 2
Enhance your Project Management system:
processes, tools, communication and
resources.
BENEFIT 3
Ensure successful implementation and
adoption for competitive efficiency and
quality compliance.

INTRODUCTION
Oracle Primavera is not your
parents’ scheduling tool—it is an
Enterprise system for identifying,
prioritizing, creating, managing
and controlling the quality of the
key element of today’s
businesses: Projects.
Implementing a system is not for
the faint of heart, but done well it
can serve as the bloodline of
your organization.
PROBLEM STATEMENT
You purchased Oracle Primavera
P6, now you must ensure it is
implemented well, used
appropriately and delivers trusted
decision-support data that is key
to your strategic plan.
PREVIOUS OPTIONS
Install ―P‖ version ―x‖ (or those other
guys you can buy at a local Office
Supply R Us) onto everyone’s carry-all
laptop and schedule any way you like.
Then when it comes to reporting, spend
long hours recreating the truth in
multiple excel spreadsheets only to find
out, it isn’t apples to apples at all—it’s
just fruit salad!
THE SOLUTION
Don’t go alone, and if you must at least
know what to do and what to avoid. A
must read!
SUMMARY
For references on previous implementations,
call today.
1-800-336-3375

PRIMAVERA EPPM IS JUST A SCHEDULING TOOL, RIGHT?
Not really but that is its roots. This is a misunderstanding of Oracle Primavera P6. To be clear, we must first
understand the different versions and the history of the tool. (The following is a personal interpretation of the
formal history of the product with personal perspective and in no way represents the view or opinions of
Oracle or Primavera regarding their product).
P3 (1994)—A stand-alone (installed on personal computer with no additional users having access) solution
managing the schedule, some tracking data, and FYI communications about the project. Resources were
available for assignment in a CPM schedule and could be ―leveled off‖ to create a realistically achievable
schedule. Costs could be allocated through expenses and resources. To share information, owner would
export the file in Primavera format (.xer) to another person who also had P3 on their PC or could export into
a more share-able format such as MS Excel and send the file.
P3 v4—A shared version of P3 with multiple users accessing the same database for all purposes above in a
client-database (server) model.
P5—A shared version of v4, but added a web component called ―myPrimavera‖ offering Resource
Planning, allocation histograms for capacity analysis, and rates on roles. Many features added hinted at a
definite ―enterprise-wide‖ road map for the product. But the thick-client is still present and preferred in this
client-database model.
P6—More focus on ―myPrimavera‖ –the web-based access point with robust resource management,
integrated risk qualification, portfolio management basics and other enhanced features. Still a client-
database with optional web-accessible approach model. The P6 mantra and naming convention sticks for
the next few versions.
P7—The first web-focused offering with P6 Web Access as a fully functioning Project Management
addressing most of the PMBOK® Knowledge Areas that is user-friendly. Still not as suited to the heavy
scheduler who spends entire day in front of the schedule, but a viable choice for most everyone else on a
project team.

P8.0— EPPM (Enterprise Project Portfolio Management) Oracle’s first version since acquiring Primavera—
boasted ―100% web-based‖ and feature-wise this was true. All features were now in the web-access model
and removed from the still available thick client—including all Administration and setup. The additional bells
& whistles and more user-friendly interface helps adoption. The technical backend is now a part of the
Oracle stack of Enterprise offerings including UCM (content management) BI Publisher (now the only way to
report and only using canned reports) and BPM (workflows). So the old, stand-alone way of doing business is
waning and harder to do because of the presentation layer and technical requirements.
P8.1—besides continued enhancements and improvements (YAY!) a ―new‖ version is also now available
and P3 is no longer sold nor supported. New version is called PROFESSIONAL and is very similar to the old
thick-client which works best with a stand-alone or a few multiple users accessing same database in a
client-database model with no web component. Easy install makes it attractive, but all the benefits of an
enterprise system are not realized without the web’s features.
P8.2—―Optional client‖ is a more old-school version of the thick client (those who grew up with a previous
version are still feeling most at home using this model) now has admin features returned. Web server and
technology must still be loaded, but it can now be treated as a stand-alone if you have a big enough PC.
The web interface though offers tempting new features and gets easier to use with each version. The
interaction with BI, Sharepoint, ERP systems, financial systems and other integrations further the possibilities
for one-source data and cumulative decision-support data from a 360 degree perspective.
So to answer the question, in summary: No, P6 is not just scheduling—it is project and portfolio
management. An enterprise system is complex, but the simplicity of P6 is that all benefit is rooted in two
things: 1. A well-planned setup; and 2. Good, clean scheduling. The benefits are derived from the schedule
which is the attraction for all users who have ―grown up‖ using Primavera. With the schedule as the
foundation, all other benefits are derived from there with little or no further action. Put in a good schedule
with clean data, and then keep it clean with good inputs and updates.

THE IMPLEMENTATION PROJECT
Delivery of a good PM system is a project itself and must be well planned and executed as a project.
Since surveys have proven 50-70% (1) of projects don’t deliver expectations, then either the expectations
or the delivery are to blame. Plan the implementation, and then deliver the PM system keeping in the
mind the information contained in this paper.
THE MIST OF MYTHS SURROUNDING IMPLEMENTATIONS (INDUSTRY AGNOSTIC)
1. P6 is a complex system; therefore the implementation is also complex (not true!)
2. P6 is just like installing any other software (not true!)
3. My two key users are the only ones to involve in the implementation (not true!)
4. Small amount of licenses means less planning and implementation effort (not true!)
5. The new system does not change the way I manage projects (not true!)
6. P6 is just a scheduling tool (not true!)
7. The vendor should not lead the implementation effort (not true!)
8. P6 should be integrated with lots of other systems (not true!)
9. P6 is useable the day it is installed (not true!)
10. Because P6 contains so many features, we should use every one of them (not true!)
While each of these can be argued in some specific instances, they are treated as black-and-white truths
rather than risky considerations. With appropriate attention to these foibles, a good plan may be created
and executed to avoid cost overruns and frustrations. The goal of any implementation project is to meet
objectives and obtain return-on-investment.

MYTH ONE: P6 is a complex system; therefore the implementation is also complex (not true!)
Likely if you were to map your current project management process, it would be more complex than P6 will
be. P6 is indeed a robust, feature-rich enterprise tool capable of managing all levels of complexity within a
portfolio of projects. A simple, straight-forward plan can ensure the implementation is not a complicated
and overwhelming effort. By using a stable methodology, paying attention to process and keeping the end
game clearly in mind—implementations are simplified.
A good implementer will use a tried and true methodology as rigidly as possible so past failures are avoided
and past successes are repeated. Review the methodology and have good reasons documented for why
each step is taken and REALLY good reasons why a step is not taken in your implementation. Be open and
discuss your current PM environment (non-technical) with your consultant and let them guide you through
your PM environment from a fresh perspective while you jointly discover tunnels and speedways. Then make
sure the people are ready for the trip--because the path is paved.
The process path has already been paved, too. Even though each organization will have preferences,
standard Project Management practices are documented and appreciated. Both the PMI (Project
Management Institute ®) and the AACE® (American Association for Cost Engineering) both have the most
widely respected practices documented and have been improved upon continuously since the 1950’s. Pay
heed to the PM processes in place at your organization and compare them to internal actual practices
and to the standards for the appropriate industry. If not documented; the first step with the vendor should
be to document that process. (Even if it is a bad one or not followed). This is the hardest part—the rest is
easy.
DEMYSTIFICATION: Keep the implementation focused and simple using a tried methodology then
progressively elaborate.
―Enterprise software has evolved too far from the commercial-off-the-shelf solution where each person
interpreted the procedures for themselves and where each person could add or delete information
according to their preferences. Enterprise project management systems are on a larger scale and have
organization-wide touch-points. Which means the implementation is far-reaching, complex, and must
be well-planned. If you add strategic planning to the mix, it’s icing on the cake.‖—Elaine Krazer, PMI
Amarillo presentation

CASE STUDY PROOF: A multi-industry worldwide engineering firm implemented P6v8 in multiple divisions
with an edict to then bring all divisions into a single system for reporting and data management. Each
division represented a different industry with industry-specific information, processes, goals and roles. To add
complexity the projects to be imported were often only managed by the division and the actual work was
being done by multiple subcontractors. The implementation was to use most of the features in the tool for
at least one group or another without a phased approach.
The vendor chosen for the implementation implemented each division with a repeated process and
progressively elaborated the configuration and documentation with each new additional group of users.
The same vendor was used for all groups with co-PMs--a client PM and the vendor PM to ensure
consistency. Knowledge transfer was a key focus. Initially, the client PM was a strong factor and insistent to
keep each effort short in duration and long in documentation with little understanding of the tool and many
assumptions about the methodology which were naïve. Requirements were not clearly communicated and
so measurement of success was (of course) fuzzy.
At a turning point, the vendor was seen as a trusted knowledgeable partner and the methodology was
honored and followed. The results were shorter durations for each additional group and an overall
knowledge transfer through repetition and documentation. Industry differences were the only anomalies to
address as the effort progressed. The P6 tool is easily configured, but knowing when and why to use each
feature is something best left to the experts who coach you through to an appropriately structured system.

MYTH TWO: P6 is just like installing any other PM software (not true!)
Depending on the product, modules and version the technical environment required to support Primavera
ranges from fairly easy wizard-driven effort to a three-tiered server with optional clustering, load balancing
and failover. However, even the simplest arrangement requires a basic understanding of a client-server
database model and the key technical statements involved. Further each installation would need to
consider security access and appropriate choices in the wizard. Some models have a choice of databases
(SQL or Oracle) which install like most databases; similarly, the operating system, components are also
typical of other web-based enterprise systems. Later versions are modular with P6 as the foundation and
ancillary components are separate installations such as reporting is now done through the BI Publisher
component, and UCM manages documents. These components makes P6 v8x a more challenging install
than previous versions.
Additionally, Primavera is based on true CPM scheduling which means dates are calculated by the tool by
combining a chain of settings including calendars, relationships, durations, progress, activity type, duration
type, and other settings. The pivot point for all calculations and reporting is the Data Date which represents
the date up-to-which data has been given status. The tool works best when constraints are used rarely and
other best practices are prevalent. This means training and PM knowledge should be big players in the
implementation. Again a PM trained Business Analyst is a prized possession.
If the implementation is treated solely as a software install from an IT perspective, a high risk exists that it will
not be adopted and used by the organization.
DEMYSTIFICATION: Installation is according to best practices from technology and implementation is from
best practices in project management.
“A contract that constrains or does not give enough time for the vendor to complete this analysis and
then completely act upon the findings will surely end in rework, cost overruns and missed deadlines for
the Primavera Implementation Project. If you hire expertise, then the suggestions from the experts should
be followed. Many times a vendors‟ initial bid is undercut to match a poorly estimated budget, but the
expectations and value to the organization are not cut—ensuring a more costly and likely failed
implementation. A good vendor wants a happy client and will offer a plan to meet goals discussed and
discovered during an analysis of current state. That plan should be given full consideration and any cuts
should be accompanied by lowered expectations and higher risks for the organization.”—Elaine Krazer,
Pentri Training, LLC, P6 training manual

MYTH THREE: My two key users are the only ones to involve in the implementation (not true!)
History proves that a small ―core‖ team representing those primarily involved in projects should participate
in the planning and execution phases of an implementation. Successful implementations have had 5-7
members of the core team with 5-7 more as part of an ―extended‖ team participating in review or
validation activities. A limited team would deliver a limited perspective of the tool and would not likely get
widespread acceptance. Further, a team without ample project management background risks delivering
an incapable system. Senior management should be very visible to the implementation team and
considered a part of the extended team when possible. Lack of support at a senior level is a red flag for
possible threats such as an abandoned implementation, adoption failure, unrealized value, and a system
detached from the strategic goals of the organization.
DEMYSTIFICATION: Enterprise software implementations should be informed by the entire enterprise.
_______________________________________________________________________________________
A “likely error is that the purchaser truly believes that a capable software package makes all users more
capable, too. Research proves that 85% of organizational challenges are from managerial decisions
rather than any other source (2). So the pain the organization is suffering, the same pain that is leading
them toward a software purchase; is rooted in the organization rather than the tools currently in
place.”—Elaine Krazer, PMI Amarillo presentation
_______________________________________________________________________________________

MYTH FOUR: Small amount of licenses means less planning and implementation effort (not true!)
All implementations have three components; 1—technical installation, 2—configuration of database and
interface, 3—training. No matter how many users there are the configuration requires the same effort. That
step is where requirements of future use of the tool are met. The technical install can be scaled down
according to technical environment tolerances and can be affected by number of users. The training is
also a scalable step where training fewer people is a more streamlined operation. Assuming that the
installation can happen within 24 hours of an operation-ready system is naively dangerous. Trust a partner to
consult you regarding the configuration settings before using the system unless you have a PM trained
business analyst with Primavera experience (a rare and expensive asset).
If implementation budget is a concern, install the system yourself and then share the budget you are willing
to spend with your consultant and they will design a successful plan to get you as far along a path of
quality as they can, given the time frame, and they can inform you what you can expect at the end of that
limited time. Ignorance of key settings can affect outputs and those outputs are relied upon by
management for decision-making. Imagine if we can improve managerial decision-making!
DEMYSTIFICATION: Configuration must happen before effective use of P6 by anyone.
“Just as a good chef knows there are many recipes for a good dish, a good chef also knows that
ingredients and the ordered process of cooking make all the difference—no matter which recipe is
chosen. Correlatively, there are many Primavera solution modules, a good implementer knows the key
success factors and planned approach that will make all the difference—no matter the organizations‟
Primavera purchase.”—Elaine Krazer, PMI Amarillo presentation
_____________________________________________________________________________________

MYTH FIVE: The new system does not change the way I manage projects (not true!)
Primavera touches the core of most organizations and its touch points are throughout the organization
beyond projects. Finance, procurement, human resources, senior management, strategic planning,
production and other systems are all affected. Attention should be paid to the impact the Primavera
system will have internally at both an organizational level and an individual level.
With more and more businesses becoming projectized—the business makes money by doing projects—the
more important a project management system becomes. At that level of importance and the fact that
Oracle Primavera is best used across the entire enterprise; the implementation should be given ample
attention to do it right. It is a myth that your vendor would say that statement to elongate their
engagement and billing—only the bad ones say that to themselves. What the good vendors really want is
to do is quality work so you will recommend them and trust them with your upgrade and continued needs
after the system is in use and proves it’s worth the initial investment. Worst event a vendor can experience is
bad press. Good vendors understand their continued business (and money making) can only happen if
they deliver the agreed upon planned value during their initial contract.
Additionally, the internal impact this system has should not be minimized. They way business (projects) get
done does change when the principle tool used to conduct project processes changes. Likely business as
usually is redefined—whether intentional or not. The very presence of a new software tool ensures change
does occur. Seems evident, but surprisingly many organizations expect their current system to be
unchanged and the new software to simply fix broken pieces of that system. Truthfully, Primavera should not
only add efficiency to the current system but should add value in weak areas while enhancing successful
ones. Truly, if the system simply automated what is already in place then the organization continues to
experience the pains of the past with no added value (and a lot of money on licensing wasted). Good
implementations capitalize on the strengths of the organization, mitigate risks of the current process and
add best practices to increase quality output of the organization.
DEMYSTIFICATION: Enterprise software touches the entire enterprise. Pay appropriate attention and time to
implement Primavera so its impact is positive.
“The authority of senior leadership … lends the project the power to succeed. That power will
undermine the inevitable outcry that new users will have against doing business in a new way, using
new software. Although unavoidable, organizational change management at least becomes simplified
when leadership loudly calls for adoption. Here is what that support looks like: time and money spent on
training both new process and new software.”—Elaine Krazer, PM Network interview

MYTH SIX: P6 is just a scheduling tool (not true!)
P6 is a comprehensive tool serving as the hub for all Project Management Knowledge Areas as defined in
the PMBOK ® standard. Communications, documentation, risks, issues, changes, portfolios, scope, costs,
quality, human resources, procurement and contracting serve as data points in P6. A phased approach to
your implementation will allow users to step into the tool one step at a time. The danger is that it is treated
simply as a schedule tool –because it will not allow the organization to realize the benefits of having all
project data in one place. With too many sources for project information, there are higher risks for poor
data management and duplication of effort by users. Data that exists in two places will only cause
questions such as ―which is the correct number or the latest number?‖ and ―how do the two
relate/synch/get updated?‖ or ―what do we do when they do not match?‖ Often reports that contain
data from multiple sources are challenged to mesh the contents so one-to-one comparisons can be done.
The good news is that most of the enterprise benefits in P6 are immediate and automatically derived from
clean schedules that have followed the same set of procedures. So the benefits go beyond scheduling, but
the users don’t have to go much further than that to reap big benefits.
DEMYSTIFICATION: The schedule is the core of P6 but it is only a part of an enterprise PPM.
__________________________________________________________________________
―The contract is not the only constraint that road blocks a good implementation. Fear of change, lack
of adoption by users, turf and territory protection tactics, failure to see the effect the system has on how
business gets done—all these constrain the team to produce less-than expected output. It is not just a
project—it is the process that achieves your company’s financial goals. Why would you hinder that? Put
your best people on it, communicate constantly, be willing to change, hire a good vendor, be
transparent to the vendor and accelerate into your best future possible.‖ Elaine Krazer, PMP Prep, Pentri
Training, LLC

MYTH SEVEN: The vendor should not lead the implementation effort (not true!)
Often an organization hires a consultant (P6 expert) then slowly takes control of their actions hoping they
are guiding the consultant to a well-informed end state. Caution: if you do not free the expert to do what
they do best; you may not get the best result. ―You pay money to an expert to tell you what you don’t
know how to do yourself, all in hopes of eventually being able to do it yourself. Why then won’t you let them
do it?‖—Elaine Krazer, 2005. Surveys of implementation specialists show 35% of the revenue stream for an
implementation consultant is from clients who have tried to configure a system for themselves or rework on
an implementation that had been done under ―unreasonable‖ constraints.
Best case scenario is a client PM and core team in an open dialogue about each option in the tool that will
meet requirements and a P6 expert explaining the pro and con of each decision. If a poor decision is made
or does not match with other related requirements, it is the consultant’s job to warn the team of the impact
their collective decisions will produce and suggest a better option. Listen to the expert. A trusted consultant
will not steer you wrong—they desire a good reference from you at the end of the project which only
comes from a good system that meets requirements.
DEMYSTIFICATION: If you have spent money to hear an expert, then hear and heed or waste your money.

MYTH EIGHT: P6 should be immediately integrated with lots of other systems (not true!)
Often an implementation consultant is asked to consider connecting to a financial system, a legacy
tracking system created in house or some other software in use. Many of these are an eventual good
idea or requirement, but typically they are best solved in other ways. Physical integrations require
planning and maintenance. Planning needs to identify exactly which data points will travel between
the systems to meet requirements and then decide if it is a push, pull or synchronize action. Further a
decision needs to be made how often the passing of data takes place and what to do when there is a
discrepancy (which source is authoritative or source of the truth?). Once one end of that integration
gets an upgrade, planning and testing should happen to ensure it won’t break the link or diminish the
quality of the data passing through the integration link. When a requirement is identified and a first
question should be ―is the requirement to bring in data from another system solely for reporting
purposes?‖ If the answer is ―yes,‖ then the two systems could both send data to a reporting mechanism
such as BI Publisher or MS Excel. If a calculation happens after the data transfer—consider using P6
calculated User Defined Fields (now available in 8.2) via manual entry or using web services.
By choosing a third location a physical integration can be simplified or avoided altogether while still
meeting reporting requirements.
An additional note, it is a best practice that any integration is a subsequent phase and not a part of
initial rollout—biting off too much will confuse adoption and elongate implementation. The organization
will learn a lot after living in the tool for a while and be more ready for future requirements.
DEMYSTIFICATION: Keep initial implementation simple for best adoption and take the time to properly
plan and validate any integration requirements.
“There had to have been a reason you purchased Primavera or created an implementation team,
right? It was done to solve a business problem. To avoid failure, clearly define that problem. Baseline the
measurements and data that indicates that problem exists. Detail and document the pains it was
causing and what a future state would look like. Now, a good implementation team will use that
information to build the system to deliver that future state. Not current state, but the desired future state.
No baseline? No measurements? No envisioning? That combination ensures failure. Once the system is
in use, watch trending and variance using the same measurements. Then create new measures based
on the efficiencies of the new system. Now you see the benefits of implementing Primavera—and there
are always benefits!” Elaine Krazer, Pentri Training, LLC
________________________________________________________________________________

MYTH NINE: P6 is useable the day it is installed (not true!)
Buying enterprise-class software such as P6 means that a configuration effort is required to ensure settings
and options in the tool are supportive of desired end state system and its outputs. Since P6 is not only an
enterprise class tool, it is also scalable and feature rich. Enterprise class means gathering requirements at an
enterprise level as well as from user groups. Scalable means there are features available to all projects, but
based on project size and PM maturity of the organization not all are applicable. Feature rich means an
organization should define which features will be implemented first and which ones should be added in
subsequent phases of the system deployment so users are not overwhelmed and training is focused and
applicable (practical). P6 global system settings are easy to use and change; but they not intuitive to
understand the impact of using one or another. This is where an implementation specialist will be of value
during configuration. Additionally, there are no views/layouts, portfolios or dashboards when the tool is
turned on. Structures and the dictionaries will determine categorization and data security. Drop down lists
must be defined and created, portfolios must be determined and dashboards created before a user
interface view is determined and groups of users are granted access. Even if your budget allows for only a
few days of consulting time, get help setting up the system.
DEMYSTIFICATION: Even experienced Primavera users may need system setup assistance to ensure features
are aligned with desired state of the P6 system.
“Hosting provides an excellent way to ensure a system is capable, ever-ready and updated with clean
maintenance. A good provider should negotiate a Service Level Agreement that includes upgrades,
up-time measures and a sound technical maintenance/change management policy that won‟t
interfere with your business hours. Check out their credentials and hire one that is responsive, has fast
processing, 99%+ availability ratings for less than $1500 a month—cheaper than hiring IT personnel.”—
Elaine Krazer, Nextel Communications
_____________________________________________________________________________________

MYTH TEN: Because P6 contains so many features, we should use every one of them (not true!)
The best implementations are focused on producing a system that not only matches current PM process
for an organization but addresses the primary concern for which the Primavera system was purchased.
A subsequent phase could add additional components or deeper use of major features. For example a
company whose background has been to create schedules without resource loading or without cost
loading should have phase one of an implementation focus on schedule creation. Then add resources
and costs. If the pain-point was a need to comply with a mandate for schedule submission or to solve
resource management issues; then that should be added in an early phase. But every caution should
be taken to keep an implementation timely, efficient, result-oriented, focused, and deliverable within
the timeframe allotted. This keeps training at its best, too--adult-centered training should be focused,
and immediately applicable to the student. Throw too much change at an organization all at once,
and the organization will defend itself with reasons not to accept all the changes. Human change
management can be a tricky effort.
DEMYSTIFICATION: Move into the Primavera tool in focused phases to ensure adoption and then mature
the system as your organization matures in its use.
________________________________________________________________________________
“„Begin with the End in Mind (3)”. Period. If your organization has a strategic plan, then projects should be
the tactical plan to reach strategic goals. If you cannot start a project kickoff meeting with the words,
“we are here today to take one more step toward strategic goal number “x” for our company,” then
you are doing the wrong project. Now, a vague strategic plan can also be the problem; but there are
few problems bigger than spending money on a project when the main focus of your company is in
another direction. The project will be deemed a failure even if it succeeds.”—Elaine Krazer, Pentri
Associates, LLC newspaper interview

THE TOP TEN!
If you dig into Primavera Implementation projects, poor results are rooted in these 10 implementation mistakes: (Ranked
in order of impact with number 1 having highest impact)
1. Project is Handled as an IT (software Install) Project Rather than a Business Transformation Project,
2. Lack of a Dedicated Team Including Senior Management Support,
3. Mismatched Implementation Partner (Vendor) and/or Faulty Contract,
4. Inadequate Experience or Training in PM Best Practices and/or an Unwillingness to Adopt Them
5. Disconnect Between Strategic Plan and the Project Office or Project Selection Process,
6. A Constrained Implementation team ,
7. An Unclear End-Game and Forgetting the Pain the Implementation Strives to Ease,
8. An Unprepared IT Department and/or Technical Environment,
9. Undocumented, Unpracticed or Absent Project Management Processes,
10. Big bang Change Management
When the above 10 risks are fully mitigated, or are eliminated altogether; Primavera implementations are given the best
possible environment in which to thrive. Each listed problem is easily found in organizations regardless of industry. Each
one presents opportunity for expensive rework, non-value added bureaucracy, poor decision making data, and lack of
adoption.
In other words, you will waste time and money--quickly. Needlessly.
Any of the above can be easily eliminated as a factor with proper planning and knowledge. It is that combination that
prevents organizations from purchasing Primavera software and installing it for good use without a good partner.
Enterprise software has evolved too far from the commercial-off-the-shelf solution where each person interpreted the
procedures for themselves and where each person could add or delete information according to their preferences.
Enterprise project management systems are on a larger scale and have organization-wide touch-points. Which means the
implementation is far-reaching, complex, and must be well-planned. If you add strategic planning to the mix, it’s icing on
the cake. –Krazer 2004, PMI Amarillo

WORKS CITED
Covey, S. R. (1989, 2004). 7 Habits of Highly Effective People. New York, New York: Free Press/Simon Schuster.
Krazer, E. (2008). PMP Prep: Don't Just Pass, Get Results!
Project Management Institute. (2008). Project Management Body of Knowledge (PMBOK) .
EXCERPTS FROM SURVEYS CITED:
THE ROBBINS-GIOIA SURVEY (2001)
Robbins-Gioia, LLC, a provider of management consulting services located in Alexandria -
Virginia, made a study over the perception by enterprises of their implementation of an E.R.P.
(Enterprise Resource Planning) package.
Survey Scope
232 survey respondents spanning multiple industries including government, Information
Technology, communications, financial, utilities, and healthcare.
A total of 36 % of the companies surveyed had, or were in the process of, implementing an ERP
system.
KEY FINDINGS
51 % viewed their ERP implementation as unsuccessful
46 % of the participants noted that while their organization had an ERP system in place, or was
implementing a system, they did not feel their organization understood how to use the system to
improve the way they conduct business.
56 % of survey respondents noted their organization has a program management office (PMO) in place,
and of these respondents, only 36 % felt their ERP implementation was unsuccessful

THE CONFERENCE BOARD SURVEY (2001)
SURVEY SCOPE
That survey interviewed executives at 117 companies that attempted ERP implementations
KEY FINDINGS
34 % were very ―satisfied.‖
58 % were ―somewhat satisfied,‖
8 % were unhappy with what they got.
40 % of the projects failed to achieve their business case within one year of going live
The companies that did achieve benefits said that achievement took six months longer than expected.
Implementation costs were found to average 25 % over budget,
Supports costs were underestimated for the year following implementation by an average of 20 %.
THE OASIG STUDY (1995)
This study has been undertaken under the auspices of OASIG, a Special Interest Group in the UK concerned
with the Organizational Aspects of Information Technology.
SCOPE OF THE STUDY
Information was collected in 1995 in the United Kingdom from a sample of 45 experts employed primarily by
Universities or Consultancies. On average they have each over 20 years personal experience representing a
cumulative knowledge base of over 900 years. Their drew their opinion from a sample of approximately
14,000 user organizations. 31 of these interviewees (69%) include consultancy work as a major component
of their work, and 27 (60%) include research; many do both. Their professional areas of expertise cover the
domains of management, business, and social science. A small number of those interviewed have a
background in engineering. Data was collected by interviewing researchers and consultants using a semi-
structured interview schedule. Some preparation was required by them. Each interview lasted, on average,
around 1.5 to 2 hours, though some lasted considerably longer.

KEY FINDINGS
The IT project success rate quoted revolves around 20-30% based on its most optimistic interviews. Bottom
line, at best, 7 out of 10 IT projects ―fail‖ in some respect.
The main reasons why systems fail to meet their objectives were identified as:
Lack of attention to the human and organizational aspects of IT.
Poor project management.
Poor articulation of user requirements.
Inadequate attention to business needs and goals.
Failure to involve users appropriately.
KPMG 2005

Implementation demystification 10 keys to a successful p6 implementation white paper

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie Implementation demystification 10 keys to a successful p6 implementation white paper

Ähnlich wie Implementation demystification 10 keys to a successful p6 implementation white paper (20)

Mehr von p6academy

Mehr von p6academy (20)

Implementation demystification 10 keys to a successful p6 implementation white paper