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

Documents

Transcript of Implementation demystification 10 keys to a successful p6 implementation white paper