I’ve led or supported P6 EPPM implementations for defense contractors, energy companies, infrastructure programs, and mining operations. Every one of them had surprises. But the pattern of what goes wrong is remarkably consistent.
This is the checklist I use now. It’s not theoretical — it’s built from scar tissue.
Why Implementations Fail
Three root causes account for roughly 80% of the P6 implementations I’ve seen struggle:
1. Underestimating organizational change. P6 EPPM isn’t just software. It changes how people report progress, how managers get visibility, and who can see what. A scheduler who’s been using standalone P6 Professional for a decade doesn’t want to hear that their schedule is now visible to the PMO in real time. That resistance is real, and ignoring it is fatal.
2. Treating it as an IT project. I watched a $400K implementation get handed to an IT project manager who knew servers and databases but had never opened P6. The infrastructure was flawless. The configuration was a disaster. P6 EPPM is a business process project that happens to require servers.
3. Going live without adequate testing. “We tested it — the login page works.” That’s not testing. Testing means a real scheduler loads a real schedule, assigns real resources, runs a schedule calculation, exports an XER, and generates a report. If you haven’t done that with real users, you haven’t tested.
Phase 1: Discovery & Requirements (Weeks 1-3)
- Identify all stakeholder groups (schedulers, PMs, PMO, executives, IT)
- Conduct stakeholder interviews — who consumes scheduling data and how?
- Document current tools and processes (Standalone P6? Excel? MS Project? Napkins?)
- Assess current scheduling maturity (DCMA 14-point? Do they even baseline?)
- Define functional requirements (scheduling, resource management, reporting, portfolios)
- Define technical requirements (users, concurrent sessions, data volume, uptime)
- Define integration requirements (ERP, cost, document management)
- Establish success criteria — specific and measurable
- Get executive sponsorship confirmed in writing
Common trap: Gathering requirements from management only. I did this on my second implementation and built a system that directors loved and schedulers refused to use. Talk to the people who will use P6 eight hours a day. Their requirements matter most.
Phase 2: Architecture & Design (Weeks 3-6)
- Size the server environment (P6 is hungrier than people expect — budget 16GB RAM minimum for the app tier)
- Database platform selection (Oracle DB is required for EPPM — this is not optional, and no, PostgreSQL won’t work)
- Design the WebLogic deployment (clustered for HA, load balancer, session persistence)
- Plan the application tier (P6 Web, P6 Professional gateway, API services)
- Design the security model (OBS-based access control, role definitions, LDAP/AD integration)
- Map the integration architecture (which systems talk to P6, in which direction, how often)
- Define environments (dev, test, production — minimum. I prefer to add a training environment)
- Disaster recovery plan (backup frequency, retention, RTO/RPO)
- Network architecture (firewall rules, VPN for remote users, DMZ for external access)
- Document the architecture for handoff to IT operations
Common trap: Undersizing the WebLogic layer. One application server is not high availability, no matter what the vendor says. I had a client go live on a single app server. It crashed during the first monthly reporting cycle when 40 users hit it simultaneously. Budget for at least two clustered instances.
Phase 3: Configuration (Weeks 6-10)
This is where the business decisions happen. Every setting here reflects a process choice.
- Define the OBS structure (mirrors your organization’s reporting lines, not necessarily your org chart)
- Build the EPS hierarchy (Enterprise Project Structure — how projects are grouped)
- Create project templates with standard WBS structures
- Configure global calendars (company holidays, standard work weeks)
- Create project-specific calendar templates (shift patterns, regional holidays)
- Define resource calendars for non-standard schedules
- Build the activity code dictionary (phase codes, area codes, discipline codes)
- Define UDF library (User Defined Fields — plan for growth, but don’t create 200 UDFs on day one)
- Configure user roles and permission profiles (I typically define 5-7 roles: Viewer, Scheduler, Senior Scheduler, Project Manager, PMO, Admin, Executive)
- Set global admin preferences (default duration type, percent complete type, scheduling options)
- Configure Unifier integration settings (if applicable)
- Set up report templates in BI Publisher or P6 Web
Common trap: Letting each project manager define their own code structure. Six months in, you have 14 different coding conventions and no way to report across projects. Standardize your activity codes, WBS structure, and naming conventions before anyone creates a project. Publish a scheduling procedures manual and enforce it.
Phase 4: Data Migration (Weeks 8-12)
This phase overlaps with configuration because you need a configured system to migrate into.
- Inventory all source data (XER files, XML, MPP files, Excel schedules, standalone databases)
- Assess data quality for each source (are baselines intact? are actuals recorded? is the logic clean?)
- Create field mapping documents (source field → P6 target field, for every field)
- Build migration scripts or use Oracle’s migration utilities
- Run a pilot migration — one representative project, end to end
- Validate the pilot (dates match? resources transferred? relationships intact? baselines correct?)
- Fix issues found in pilot and re-run
- Execute bulk migration in batches (don’t try to migrate 500 projects at once)
- Validate every migrated project — spot checks aren’t enough
- Document what didn’t migrate and why (some data loss is acceptable if it’s documented)
Common trap: Migrating garbage data. If a schedule has 3,000 activities with no logic and no baseline, migrating it into EPPM doesn’t make it better. It makes your new system look bad on day one. I tell clients: clean it first, or don’t migrate it. Archive it as-is and start fresh in EPPM.
On a recent energy sector implementation, we assessed 120 standalone schedules for migration. Only 45 met the minimum quality threshold. The other 75 were archived, and the project teams rebuilt them properly in EPPM. Painful, but the right call.
Phase 5: Integration (Weeks 10-16)
Skip this section if you’re running P6 standalone. But if you need integrations, plan for them early.
- ERP integration (SAP, Oracle EBS, JD Edwards — typically cost and WBS sync)
- Document management integration (Aconex, SharePoint, Unifier)
- Cost management integration (EcoSys, Cleopatra, HCSS)
- Risk management integration (ARM, Safran)
- Configure P6 Integration API (REST or XML-based, depending on version)
- Build and test each integration point individually
- Test integrations together (conflicts between simultaneous syncs are common)
- Establish error handling and alerting (if the SAP sync fails at 2 AM, who gets notified?)
- Document integration schedules (what runs when, in what order)
- Performance test under load (integration jobs competing with 30 concurrent users)
Common trap: Treating integration as “Phase 2” that will happen after go-live. I’ve seen this on at least five implementations. Phase 2 never happens. If integration is a requirement, build it now. If it truly can wait, get that agreement in writing with a funded timeline.
Phase 6: Testing & Training (Weeks 14-18)
- Write UAT test scripts based on real workflows (create a project, schedule it, assign resources, update progress, run reports)
- Execute UAT with actual end users, not just the implementation team
- Performance test with realistic data volumes (load 50,000+ activities and see what happens)
- Performance test with realistic concurrent users (your 30-user license means 30 people at once)
- Security test (can a scheduler see projects they shouldn’t? can a viewer edit?)
- Develop role-based training materials (a scheduler’s training is different from a PM’s)
- Deliver scheduler training (hands-on, 2-3 days, with exercises using the actual configured system)
- Deliver PM training (focused on reporting, dashboards, progress updates — 1 day)
- Deliver admin training (separate track: user management, security, global changes, troubleshooting)
- Deliver executive training (30-minute overview of dashboards and KPIs)
- Create quick-reference guides for common tasks
- Fix all critical and high-severity issues found during UAT before go-live
Common trap: Training people six weeks before go-live. By the time they log in for real, they’ve forgotten 70% of what they learned. Train as close to go-live as possible — ideally the week before. And schedule refresher sessions for week 3.
Phase 7: Go-Live & Hypercare (Weeks 18-22)
- Finalize the cutover plan (sequence of events, responsible parties, rollback criteria)
- Communicate go-live date and expectations to all users (at least 2 weeks in advance)
- Execute cutover (deploy production config, migrate final data, enable user access)
- Lock down the old system (prevent people from updating both systems)
- Staff a hypercare support desk (dedicated P6 support for the first 4 weeks)
- Daily triage of reported issues (categorize: bug, training gap, or change request)
- Weekly status reports to steering committee during hypercare
- Knowledge transfer sessions with the internal admin team
- Update documentation based on issues found during hypercare
- Formal hypercare exit — confirm the system is stable, support is transitioned
Common trap: The consultant leaves after go-live. The internal team isn’t ready. Issues pile up, users lose confidence, and six months later nobody’s using EPPM. Build a proper transition plan. Overlap the consultant with the internal team for at least 4 weeks post-go-live.
Timeline Reality Check
Here’s what I’ve actually seen:
| Scope | Realistic Timeline |
|---|---|
| Single business unit, no integrations | 12-16 weeks |
| Single business unit, 1-2 integrations | 16-22 weeks |
| Enterprise-wide, multiple business units | 20-30 weeks |
| Enterprise-wide with complex integrations | 30-40 weeks |
Anyone telling you they can do a full EPPM implementation in 6 weeks is either cutting corners or redefining “implementation” to mean “we installed the software.” Installation is week 2. Everything after that is the actual work.
The One Thing That Matters Most
Executive sponsorship. Not the kind where a VP signs the project charter and disappears. The kind where someone with authority shows up to steering committee meetings, removes blockers, and makes it clear to the organization that this is happening.
Every successful P6 EPPM implementation I’ve been part of had a strong sponsor. Every failed one either had no sponsor or had one in name only. If you don’t have real sponsorship, fix that before you fix anything else.