1. COLLABORATE 12
Copyright ©2012 by Sarah Benjamin
Page 1 of 16
Project Portfolio Management
Oracle P6v7 vs. Microsoft Enterprise Project Management
Author: Sarah Benjamin
Company: Taurus Project Controls
Introduction
The audience will learn how the leading two project management software products compare in similar
environments at pharmaceutical manufacturing plants. The presenter spent three years managing
projects with P6v7 until taking a similar role at a different company using Microsoft Project Enterprise
(EPM). Web Applications for both tools were in use. Schedules, cost tracking, and prioritization for
approximately 400 projects are reviewed. This presentation is an honest look at the ups and downs of
project tracking.
Objective 1: Compare features of Primavera P6v7 and Microsoft EPM for project portfolio management
Objective 2: Compare various project prioritization methods: theoretical > practical
Objective 3: Resource management techniques applied to pharmaceutical manufacturing
The applications being compared are Primavera P6 v7 (P6) and Microsoft Enterprise Project
Management (EPM) version 2010. Both software packages have a web-based access application as well
as a desktop client application. The paper will refer to the package as a whole in most cases. If there
needs to be a distinction between the web access application and the client, that will be specified in the
context. Otherwise the abbreviations P6 and EPM refer to the suite of tools by the respective
manufacturer.
Two companies are the basis of this paper. In order to prevent any inadvertent non-disclosure agreement
breeches or other potentially problematic situations, the companies will be referred to as “Company A”
and “Company B”. Company A has revenues in the billions each year. Company B has revenues closer
to $500 million per year and is significantly smaller than Company A. They are both in the
pharmaceutical industry producing specialized biotechnology products such as vaccines, genetic
therapies, and medications for chronic conditions. The author served as a Project Portfolio Manager for
both companies.
The Primavera system available to purchase has been upgraded since the author’s experience, so this
paper may not take into account all of the upgrades to the application since version 7. Company A used
P6 v7 and has not yet upgraded its instance of the software due to overwhelmed IT support staff.
Company B implemented EPM after using P6 for managing the building of their manufacturing facilities.
They felt like EPM would be easier for the non-project-management-personnel to pick up and use without
much training.

2. COLLABORATE 12
Copyright ©2012 by Sarah Benjamin
Page 2 of 16
Software Performance
This paper is written from the perspective of the business process administrator of the software tools.
The IT administration was handled by other individuals who occasionally required technical issue
resolution support by the author to ensure that solutions worked for the business. Overall, the
perspective of the author is that Primavera P6v7 (P6) System Architecture is more robust than Microsoft
Enterprise Project Management (EPM). The P6 platform is a native database platform. This means that
it was developed from its inception as a database application. The EPM platform does not share this trait.
Microsoft Project was originally a file-based system. Because of this inherent difference in the systems’
architectures there is an obvious winner for system performance: P6.
The role of a Project Portfolio Manager is to analyze project schedules, cost forecasts and actual
expenditures, and other notes about the projects. This is the full time job of the author of this paper. The
responsibilities basically include meeting with project managers, schedulers, cost analysts, senior level
management and other project personnel to ensure that the data in the project management system is
accurate. In this capacity, the project management software is open all day long. The way the tool is
used by a Project Portfolio Manager is to be in one project for a few minutes, then switch to another
project to make a few notes, and then open up a different one. Opening and closing projects needs to be
fast and simple because it happens literally hundreds of times each day.
P6 has the architecture to enable a speedy opening of a project as long as the project schedule is below
10,000 activities. In the experience of the author, the projects within her portfolios were always below this
threshold at both Company A and Company B. For P6 the typical time that elapsed between clicking
“Project > Open” and the time that one could then access any given data was approximately 5 seconds.
The EPM system did not have the same speed associated with this operation. From the time that the
command was given to open a project, the elapsed time would average at least thirty seconds. These
numbers were basically the same to close out of the project as well. So P6 would take a total of 10
seconds to open and close a project. EPM requires one minute. Multiply that difference by 100 times per
day and the result is a total of 1,000 seconds for P6 and 6,000 seconds for EPM. 5,000 seconds = 1 hour
and 23 minutes. So the people who need to open and close 100 projects every day are losing 1 hour and
23 minutes per day if the system is Microsoft EPM. That is almost 7 hours per week of lost productivity!
Project schedulers are typically not opening and closing this many projects every day. They might work
on anywhere between five and ten schedules in an average day, so admittedly, the number of people
who are affected by this system performance issue is not extremely high. However, when the company is
committed to expanding the use of the tool and you extrapolate the wait time that is experienced by the
many users that accidently open the wrong project and need to reopen something else, the wait time
adds up to significant work time lost.
Microsoft EPM architecture is built on Microsoft SQL Server for the database, Office Communication
Server and .NET Framework. The key architectural issue is that EPM runs as part of the SharePoint
Server. This means that if an organization already has an instance of SharePoint running and would like
to incorporate EPM, they will need to integrate it to realize the benefits of the tools. This is also a factor if
collaboration tools like SharePoint are already in use at a company that wishes to implement P6. There
are features of each application that have similar purposes and some business analysis would need to be
run to determine the best use for each application as it relates to projects.
Here is an example of the potential headache that this can cause: Company B is running a corporate
instance of Microsoft SharePoint Services 2007. The Capital Projects group would like to implement EPM
to manage projects. The easiest solution is to use a hosting company to get up and running quickly since
the corporate IT group is too busy to support a complicated installation, much less integrate an
application with SharePoint, so the Capital Projects group sets it up on a remotely hosted machine. This
works well to initially speed the build up of the system and the troubleshooting of issues. However, when
it is time to utilize the SharePoint elements of the tool like project document storage and workflows, there

3. COLLABORATE 12
Copyright ©2012 by Sarah Benjamin
Page 3 of 16
is a disconnect between the Capital Projects SharePoint instance and the corporate SharePoint.
Documents on the hosted site cannot be posted to the corporate SharePoint without downloading them to
a local machine and then manually uploading them. This requires more steps than most technically-
savvy project managers would like to click through in order to share a document. So documents
generated by the EPM system on the hosted machine would typically reside on that machine instead of
being shared out to the project team via the corporate SharePoint.
The P6 architecture installs its own web-based collaboration portal where project documents would be
stored. This would still be redundant to a corporation’s document management system – SharePoint or
other – so there needed to be business process guidance surrounding which documents were best
posted on P6 or on SharePoint. These tools could be integrated in the future, but both Company A and B
were not at a maturity point with the tools to justify investing in that integration. This is something that is
likely five or more years in the future.
In conclusion, both P6 and EPM have complex underlying architectures that support many advanced
features of project management other than scheduling. The personnel who will be required to switch
between projects many times per day would find P6 the tool of choice as EPM is slow to respond.

4. COLLABORATE 12
Copyright ©2012 by Sarah Benjamin
Page 4 of 16
Software Productivity
The features that were the most commonly used in each software application typically worked better in
P6. What does better mean? It doesn’t mean faster, it means that the feature is more robust, less buggy,
and overall easier to use. So which features were most commonly used?
Project Codes
In P6 project codes are used for all dimensions of project attributes. In EPM these attributes were
referred to as Enterprise Custom Fields. In both cases the attributes being tracked are:
• Status
• Sponsor
• Location
• Department
• Funding Source
• Project Manager
• Change Control Number
• Governance Team
• Portfolio
The project codes are easy to track in both P6 and EPM. The challenge is typically in the business
process that guides the codes. Businesses beginning their use of either system should try to minimize
codes and possible code values.
Examples of the Status code are:
Active = Project is in progress
In Closeout = Project has all physical work complete, waiting on invoices
Future = Project has been approved but deferred to future date
Complete = Project is 100% done and all invoices are processed
Canceled = Project was started, but stopped and will not restart
Not Approved = Project has not been given approval by Steering Committee
Schedule Indicators
The schedule indicators are red, yellow or green lights that are either manually entered by the project
scheduler or mathematically based on the comparison of the overall finish date to the baseline. If the
finish date was within two weeks of the baseline finish date, the light would turn yellow. If the finish date
was late by more than four weeks, the light would turn red. Both EPM and P6 were capable of this
functionality and there was really no advantage to either application. Both Company A and B ended up
using this indicator as a manual entry by the scheduler since the schedule could have issues that are not
yet affecting the overall finish date.
Company A also showed the Schedule Variance. This is the difference (in working days) between the
Scheduled Finish Date and the Baseline Finish Date.

5. COLLABORATE 12
Copyright ©2012 by Sarah Benjamin
Page 5 of 16
Cost Indicators
Formulas are equally complex to write in P6 and EPM. They both need to be written in the Web
Applications instead of the desktop clients.
Company A had a cost indicator that was manually determined by the cost analyst.
For Company B, the cost indicator was mathematically calculated. It would be a clear circle if there was
no budget established yet. The cost indicator formula in EPM:
IIf([Total Project Budget] = 0, 99, IIf([Cost] = 0, 99, ([Cost] - [Total Project Budget]) / [Total Project
Budget]))
The cost indicator would be green if there is less than a 10% overrun in the forecast as compared to the
total project budget. The cost indicator turns yellow if there is a 10% - 15% overrun. The indicator turns
red if the overrun is more than 15%.

6. COLLABORATE 12
Copyright ©2012 by Sarah Benjamin
Page 6 of 16
Scheduling
The comparison of the scheduling aspects of P6 and EPM is a paper all on its own. For the purposes of
this review, the high level points will be presented and not the details about each feature. Overall EPM
and P6 are both capable of being used as project schedule management applications. They require
slightly different business processes to have an enterprise level report produced consistently on a regular
basis. The rigor around the process is easier to control in P6. EPM provides the person managing the
schedule with flexibility that for some feels comfortable, but when analyzed often ends up providing
misinformation about the schedule. P6 is the strongest tool in the industry for schedule management and
reporting.
For the smaller types of schedules used in Companies A and B, the main differentiators were the inter-
project linking between activities, and the general bugginess of EPM when working with imported files.
These two features are very successful in P6. The system is excellent at linking activities between
projects. P6 is also very robust at importing files with several dimensions of data. EPM however is buggy
when doing both of these tasks.
The inter-project activity links in EPM work about 60% of the time without an issue, however the other
40% of the time they cause system errors or other strange behaviour. This was a constant source of
headaches for the schedulers at Company B. The other source of headaches was the importing of
schedules. This was also not clear as to exactly what element of the import would cause corruption in the
schedule that was to hold the imported data. Something just didn’t work quite right when a schedule had
been imported and then logic began to be revised. System errors popped up and there were more than a
handful of times that the schedulers decided to try rebuilding the schedules from scratch. So without
defining exactly what is wrong with doing these common scheduling functions, it’s just safe to say that P6
is much more stable than EPM.
Customer support is also a differentiator. P6 customer support for technical issues like errors and strange
behaviour is reliably responsive. On the flip side, EPM customer support from Microsoft can feel like a
black hole.
The other clear differentiator in regards to scheduling functionality is the baseline features in P6. The
system is capable of saving an unlimited number of baselines (depending on system administrator
imposed limits to keep the database size manageable). P6 provides features to show when the baseline
was saved or last updated. It allows for a clear title to be applied to each baseline. This is very helpful
when the schedule needs to be compared to multiple baselines simultaneously.
EPM is not as sophisticated. The baselines cannot be renamed, and the scheduler must maintain a
separate file to track what schedule is assigned as “Baseline 1”, “Baseline 2” and so on. This can be
confusing for the scheduler, but would be even more confusing should a different scheduler need to do
the baseline comparison. There is likely a workaround out there but at Company B this was still a
problem.
Most schedulers who have used both applications would also be able to compare the activity coding
capabilities along with the regrouping and filtering the schedules to tailor the output for different
audiences. P6 has many features that allow the layouts to be saved and easily applied to other projects
without the same set up as EPM requires each time.
While the status collection features of P6 were not in use at Company A, it is a feature set that has very
robust capabilities to ease the status collection responsibilities of schedulers. The P6 web application
can allow anyone the access rights to provide very discrete status information about activities. The tool
can be set up such that only remaining durations could be entered, or actual finish dates. The end
contributor would not be able to adjust the schedule logic, start dates or logic if that is what the
organization determined should be the method of gathering status. This capability has huge potential to

7. COLLABORATE 12
Copyright ©2012 by Sarah Benjamin
Page 7 of 16
assist the schedulers at Company A with involving more project team members in the schedule. The
likely result would be better schedule adherence and more involvement in building the schedule
accurately. This feature set is one that significantly sets P6 apart from EPM.
So in regards to the scheduling functionality of the tools and minimizing lost productivity, P6 is the clear
winner. EPM can do the job for schedules that are not excessively complex, but when it comes to inter-
project activity linking, P6 is the tool of choice.

8. COLLABORATE 12
Copyright ©2012 by Sarah Benjamin
Page 8 of 16
Cost Tracking
The advantage to tracking costs inside the Project Management software is that the applications will time-
phase the cost forecasts. This provides detailed cash flow information that is typically cumbersome to
track in Excel. The Companies A and B aimed to integrate all cost tracking data into the PM software,
however financial policies prevented the full integration at both organizations. Company A decided to
stick with the comfortable Excel-based spreadsheets that had been the standard for decades. Company
B is closer to attaining financial data integration with the schedules in EPM, however there are still some
open issues that are preventing this from moving forward.
There is a strange phenomenon in EPM in which the software will recalculate the cost forecast when
someone simply opens the project. If the schedule changes, the forecast may change and would then
need to be manually reset to the previous value. This problem frustrated the cost analysts at Company B
and as of this publication date has not been solved. Various workarounds were tried but nothing seemed
to completely prevent the phenomenon.
In conclusion, this is another instance in which EPM has some strange behaviour that is not predictable
across the enterprise. It is exactly this type of issue that leads the author towards her conclusion that P6
is the more robust and stable platform.

9. COLLABORATE 12
Copyright ©2012 by Sarah Benjamin
Page 9 of 16
Project Selection and Prioritization
The main differentiator between P6 and EPM is the portfolio analysis feature. P6 would allow a user to
create a User Defined Field in the Web Access application that could be calculated based on a simple
math formula. The project request workflow could gather the project business drivers, and based on a
weighting scheme the UDF would end up calculating a project score from the drivers. The EPM portfolio
analysis was also based on weighted business drivers but used a “pair-wise comparison” such that every
project in a given portfolio was simply compared one by one with the other projects in that portfolio. After
all projects have been compared the result is a prioritized list.
There were some advantages and disadvantages to each system, and in the end P6 proved more user-
friendly due to the structure of the UDF integration into views and reports. The EPM system kept the
portfolio data in a separate portion of the architecture and it could not be extracted to reports or Excel
files. Therefore the EPM system was harder to manage in terms of the updating the business drivers and
the resulting prioritization lists.
Both companies had weekly meetings in which they would review the project requests that came in from
across the organization and determine which projects should be the ones to move forward. The goals of
both organizations were consistent: keep manufacturing operations running, make the plant safer for
operators, and avoid any compliance risks to the products. In addition to these both companies wanted
to keep costs down and produce larger quantities of the products. Since project requests come in all
shapes, sizes, and for a variety of reasons, the organizations applied common business drivers to all
projects to try to level the playing field. The projects with compliance risk mitigation or safety
improvements were typically moved to the top of the lists.
For Company A, the calculation was simply easier to track and manage in Excel rather than P6. The
project requests were submitted on a standard Excel template and the scoring was done on a tab in that
request file that worked in the background. The scoring was a weighted formula with three criteria and
one main business driver. As the scoring formula became more and more familiar to the project
requestors, there were some trends in projects becoming categorized in a ways that would increase the
project scores. The safety improvements may have been overstated, or perhaps compliance risk
mitigation was added to the scope when it didn’t need to be. These issues were discussed during the
prioritization meetings and the scores adjusted accordingly. All final scores were recorded in the UDF in
P6. The final score field was easily included on the standard reports and views that were commonly seen
throughout the application.
For Company B, the project requests were submitted with a PDF file. This file showed the four business
drivers that would result in the project’s priority but there was no calculation built into the PDF file. The
drivers would be manually entered into the Portfolio Analysis feature in EPM. This feature was somewhat
of a standalone module in that the business drivers assigned to a project were not standard across all
portfolios. The project could have one set of drivers in one portfolio and could have a different set of
values for those same drivers in a different portfolio. Therefore the business drivers are quite different
from an Enterprise Custom Field and were not able to be shown the same way in views and reports. This
proved quite cumbersome because as the prioritization lists were generated each week, the data that was
at the project level needed to be combined with the portfolio analysis data. This was a manual copy and
paste exercise that took place after exporting both sets to separate Excel files. The potential for error in
reshuffling this data was enough to be occasionally embarrassing.
The other problem with the standalone nature of the portfolio analysis feature was that the ease of
applying a change to a business driver and communicating the outcome to an audience was less than
slick. The changes were typically a bit too cumbersome to be able to accomplish live in a meeting, so the
new prioritization of projects would need to be exported out to Excel for distribution and analysis after the
meeting. This whole system of prioritization was harder for the project constituency to understand and

10. COLLABORATE 12
Copyright ©2012 by Sarah Benjamin
Page 10 of 16
follow. It seems as though the pair-wise comparison concept has a lot of merit conceptually but when
applied in real life falls short of its intended goal of fair prioritization.
In conclusion, while the EPM portfolio analysis feature is a fancy tool to have in a Project Portfolio
Manager’s arsenal, the actual steps that need to be followed to publicize this data makes it cumbersome.
The P6 method of calculating a numerical value and holding it in a UDF is just simpler and easier to
implement. P6 also has built in fields for Strategic Value which could be used in a slightly different
business process depending on the numerical calculation strategy.

11. COLLABORATE 12
Copyright ©2012 by Sarah Benjamin
Page 11 of 16
Project Status
This section refers to the project status that a project manager would give if he or she was in an elevator
with someone from their company who was familiar with the project but wants the most current
information. The PM would say something like:
“The project is going along according to our original plan however we recently found out that the hoist we
anticipated using in the ceiling is no longer safe so we are currently determining an alternative rigging
solution. This will likely add additional cost that was not projected in the original estimate.”
This type of current status is something that should be tracked in the project management software;
however it may not be at a state that is easily translatable into the schedule and/or forecast. Having a
place to store this type of “plain English” status is very important. Over time, with weekly or bi-weekly
status updates, this becomes a project “storyline”.
Tracking the storylines for each project is typically done in notebooks or multi-line text fields. In P6, the
users could create a new User Defined Field (UDF) at the project to store this information. After trying
this method, it was apparent that the UDF cannot format the text as well as the Notebook area of the tool
(which uses a rich text editor). Therefore, the Notebook feature became a very widely used area of the
tool at Company A. Over a dozen different notebooks were defined and standards were developed as to
what type of information would end up in each notebook.
In retrospect, the phrase “keep it simple stupid” would apply and the amount of notebooks could be
reduced to only three. The personnel who entered notes into these notebooks would keep them
reasonably brief and there was actually more work involved if having to switch between many different
notebook topics. In the end, there was one main notebook where most all notes would go, and there
were two additional notebooks occasionally used for major project scope changes and rebaselining
explanations.
In Microsoft EPM, the Notebook function does not exist. The same type of storyline management was
entered into a multi-line text field. Company B utilized three multi-line text fields: one for general status,
one for an explanation on the schedule indicator, and one for an explanation on the cost indicator. This
provided an appropriate amount of “plain English” to satisfy inquires from the management.
There was also a useful convention applied when inserting a new status update that neither software
package did automatically, which was to type the current date and initials of the person writing the
update. Here is an example of the notebook status field for one project.
Project Notebook Example:
13Apr11 (AVS/Project Team): There will be a meeting to discuss BCRB status on 15Apr11.
30Mar11 (DJW): BCRB pending
02Mar11 (AVS/Project Team): Waiting for BCRB
16Feb11 (AVS/Project Team): Waiting for APO to Implement SOP.
0814Feb11 (DJW): Per CC meeting on 07Feb11 : · Change was discussed to whether proceed with the change or cancel. It was
decided by the subcommittee to proceed with the change since it captures the rational to remove the need to complete a CIP
between two consecutive make-ups of the same buffer in Suite Support. Change endorsed by all stakeholders; however, still
pending the BCRB endorsement form
24Jan11 (AVS): Per email from DJW: 'Waiting on a memo. There will be no PQs required. Following that, the change cannot be
made until Demo period is over and another regulatory round is complete. Expect Jun 2011 at this point.

12. COLLABORATE 12
Copyright ©2012 by Sarah Benjamin
Page 12 of 16
Based on that example, one can see that the status updates are useful to track over the course of the
project. Without the date stamp on each one, they would not have quite so much relevance.
The complication of the project notebooks is in the creation of a report. The project status report that can
be handed to an upper level manager to provide the full picture of that project typically would not include
the full project storyline. If it was included on this report it would have a much more formal language.
The experiences at both companies provided the understanding that the status field was best left off of
any reports so that it wouldn’t be too difficult for anyone to think of what to say. The report narratives
were typically generated at the time that the report would be submitted and were kept in the Project
Manager’s personal drives as Word documents. Trying to merge the formal narrative with the project
status storyline proved to be unproductive.
Project schedulers and cost analysts have a more detailed understanding of the plans and forecasts than
the Project Manager, and these roles need a place to write their narratives so that they can analyze the
data and look for potential mismatches between cost and schedule. This is a different type of narrative
than the one the PM provides to the management. At Company B, all types of narratives were included
on the project status report given to management, but this is still being adjusted since the rigor related to
the updating of these fields is still in flux.
The notebook topics and multi-line text narrative fields are critical to the success of the project
management tool’s use. Without these “plain English” fields, a lot of knowledge about the projects
remains in individual’s heads and not in the tool. When it’s not simply stated in the tool phone calls need
to be made, appointments set up and/or emails exchanged. These all take significantly more time than a
simple note made at the time the last status was given.

13. COLLABORATE 12
Copyright ©2012 by Sarah Benjamin
Page 13 of 16

14. COLLABORATE 12
Copyright ©2012 by Sarah Benjamin
Page 14 of 16
Resource Management
The resource management techniques applied at Companies A and B were not particularly tight. Both
companies flirted with the concept of integrating the resource management into the PM tool however
neither company proceeded with this implementation at an enterprise level. There were projects and
programs that required intensive resource management and so it was in place for those particular efforts.
The rollout of resource management at the enterprise level requires a very driven upper management.
Company A did a long pilot program to examine the realistic effort required for a full scale resource
management implementation using P6 v7. The outcome of a twenty-person steering committee’s
analysis of the tool and the other options available resulted in their choice of using an alternative software
program called Unanet. The reason they chose this tool was primarily for the skills tracking and goal
setting for individuals’ career growth. The downside to making this choice was that the Unanet
application would not integrate with P6 directly. It could import project schedules, however the business
process for this was never established and projects were re-defined in the Unanet tool and manually
extended based on the P6 forecast.
Obviously this presented a timing issue and that affected the situation at Company A with the Unanet
application typically showing projects finishing much sooner than their more up-to-date P6 schedule
forecasted. The Unanet software was primarily used for six-month headcount forecasts at a high level,
and not a detailed weekly resource management tool. The weekly resource reshuffling was still done
manually by people managers without any data driven reports to use for their decision making. This
continues to be a source of pain at that organization. P6 could not match the skills tracking functionality,
but it would’ve provided a significant advantage in that all project schedules would be up to date and
resource over-allocation could have been forecasted at a detailed level to provide data driven reports to
the people managers.
The problem apparent from the above discussion of Company A’s choice in resource management
software speaks to the issue inherent in all enterprise resource management implementations: there is a
huge difference in the level of detail at which the initiative is undertaken. If the resources are tracked by
named individual versus a type of role, there will need to be a proportionally larger effort employed by the
organization to track the hours both on the forecast side, as well as on the actual side. This something
that the upper level management tends to gloss over until it becomes clear with a requirement of hiring a
number of resource managers that will do that work. The people managers that are in place doing this
task today are often doing it on the fly with no data to support their resource levelling – they just place
people in the areas where someone is yelling the loudest. Once an organization decides to based this
reshuffling on data, they need people in the middle who will manage that data, in addition to the existing
people managers that are probably responding to the loudest requestors.
The tool is not the issue here. The issue with the resource management is the amount of data that it
requires to be successful. The pharmaceutical companies have been accustomed to hiring large
percentages of their staff as contract workers, and then letting them go when the business needs to cut
costs. The pharmaceutical companies have not been under enough cost pressure for a long time as to
encourage their business managers to implement detailed resource management within their project
management tools. The day will inevitably come when the business needs require this integration, but for
now there is still enough money to do things the old way.

15. COLLABORATE 12
Copyright ©2012 by Sarah Benjamin
Page 15 of 16
Portfolio Management Role
The Project Portfolio Manager is the person who looks after the entire project portfolio from a high level.
Essentially they look for data inconsistencies, out of date information, and other problems which may
show up on the management reports. They also track the general status of every project so that they can
answer questions from the entire project constituency.
Every project goes through the standard lifecycle and “stage gates” of approval. The real value of the
role of a Project Portfolio Manager is the ability to make sure that every project is accurately represented
in the PM software and decisions made by the leadership team are also appropriately represented and
communicated.
The Project Portfolio Manager distils the storylines of projects into the structure of information needed by
the software to be able to provide concise reports to upper management. In doing this translation, the
Project Portfolio Manager also reviews the overall summary information to look for data that may be
outdated or incorrectly translated from the actual project’s status.

16. COLLABORATE 12
Copyright ©2012 by Sarah Benjamin
Page 16 of 16
Conclusion
Based on the robust capabilities of the Oracle Primavera P6 solution compared to the relatively less
mature Microsoft Enterprise Project Management, the preference for a company with no other influences
should be to use Oracle Primavera. Certain company cultures may already be entrenched in Microsoft
technologies and may shy away from supporting a major Oracle-based solution due to corporate
standards. This would need to be weighed with the long term commitment that will be made to the project
management solution and the various headaches that will need to be overcome by the project
management departmental software users and administrators.
Overall the scheduling capabilities of Oracle Primavera P6 are unmatched by Microsoft EPM. The ease
of collecting status from a wide variety of project participants and controlling what updates get applied to
the schedule are elements in P6 that are not even close to being features of Microsoft EPM. The
corporate users for each application may start out thinking that they like Microsoft Project so they should
foster the use of EPM in their enterprise, but once they implement it, they will likely experience
headaches due to strange behaviour, error messages, and lost productivity. Then they will wonder why
they didn’t go with P6.