Oracle@Oracle : Implementing Primavera in an IT Services Environment – Does it work?

2. Oracle@Oracle: Implementing Primavera in an IT Services Environment – Does it work? Chris Lynham Senior Principal Project Manager

3. Case Study Agenda • Background • Phase I – The Journey Starts…. • Phase II – After a short break the journey continued…. • What did we Implement • What really Worked

4. Case Study Agenda - continued • What went Awry • Lessons Learnt • The Journey Ends? • Summary and Questions

5. Background

6. Implementation Timeline • GO LIVE • 1st November • 2010 • Sept-Oct 2010 • PMO Leadership meeting • Too many obstacles • Define Implementation Plan • March 2010 • Started partnership with PDIT PMO • Started on a script for data transfer from PRP • Producing standard templates • October 2009 • Engaged a Primavera Consultant • Spent 2 weeks working on initial solution • Started in an OnDemand environment • Autumn 2008 • Oracle announced Primavera acquisition • Hence our assessment turned to Primavera • Summer 2008 • Identified the need for a PPM tool

7. In the Beginning….. • Global Projects Database • The screen shot above is the project listing that each PM would have as a standard page after login • Then by selecting the update/edit button for a project the PM would see the complete project data • Shortly we will see how we maintained some consistency for the PMs; this aided acceptance (familiarity)

8. Phase IKeep it Simple!

9. The Journey Starts….

10. Phase IIMore Complexity!

11. After a short break the journey continued…. • One clear view that had changed during that year was the attitude towards Primavera and how it could benefit the organization, hence 2 new phases were confirmed as part the program • Phase II to deploy resource management for our Service Design group • Phase III to deploy Workforce Management across all Global IT • January 2011 Phase II kicked off; this was our first attempt at scheduling with active engineering resources logging time • Service Design used another legacy ‘Home Grown’ solution they called PIRT in which they controlled engineering effort that was not under a project and this effort we called ‘Work’ • Resource Managers received resource requests in their dashboards from the PMs that equated to an estimate of the effort required over a duration for a specific Role

12. And continues…. • The PM and RM would negotiate to ensure availability and capacity before the RM assigned a Resource from his team to the Role • Each Resource had a primary Role and might have a number of secondary Roles • It was the responsibility of the PM to ensure engineers were fully informed on the activity required and given the chance to revise the estimate if necessary • This would require re-negotiation with the RM if the agreed effort or duration changed • Resources were responsible for logging their time (on or before CoB on Friday) in Progress Reporter • Project Schedule Services were set up to Capture Actuals, Schedule and Summarize the projects just after Midnight on Friday Pacific Time • At this time the PMs were only responsible for monitoring the data collected and not the validity of the effort captured; RMs were specifically interested in the resource utilization • The PMs only got involved if their completion dates were affected

13. What did we Implement – for the RM

14. What did we Implement – for the PM

15. What really worked – Phase I • The announcement to go created an excitement / expectation • PMs were looking forward to getting a professional PM tool • The Templates worked • Also gave the PMs the opportunity to contribute • The Enterprise Project Structure (EPS) was a good solution • It allowed the Portfolio Managers to filter projects • PM sessions set out help topics for daily improvements • For example how to set up their Dashboards, Portfolio Views and filter only their projects • The retained consistency between the old GPD data and the new environment – keep it simple policy • PMs immediately recognized the data fields and understood their purpose • The BI reporting approach provided a ‘self-service’ solution for stakeholders to check project status

16. What really worked – Phase II • The benefits for the PMs were less than those for the RMs • The ability to see what key design resources were working on was a revelation • The ability to see what time engineers were logging to a project was key for the RMs utilization and capacity decisions • Interesting for the PMs as this had not been formally attempted before • PM training went well, but ideally could have been later • The Service Design self service training provided the basics, but really worked well in conjunction with working ‘brown bag’ sessions • The CBTs also allowed repetitive viewing – if at first you don’t succeed • The Service Design project team were really committed to getting the solution working and became highly skilled by the time we went live • The support teams were keen to learn and understand the new environment – this helped mitigate migration issues

17. What went Awry • Misconceptions on ease of deployment • Avoid the politics • Early access to the team meant they started to Prototype/RAD • They failed to focus on the requirements and design activities • Maintaining a Sandbox • Supports understanding of the tool • Keep the organization informed • Due to delays the organization got mixed messages • Take your champions on the journey with you • Encourage users to engage and do their homework • Keep the training going • Keep the help sessions going

18. What went Awry • If you are partnering with another group make sure they understand your objectives • Our partner couldn’t support the level of users we were intending • There is a fine balance between flexibility and anarchy • If you have Templates keep them simple • If something is mandated, make sure there is a clear message • Feign ignorance as an excuse for non-compliance • Reduce Project workload; too many active projects to work the process effectively • RMs did not have the utilization data they needed; result was availability unknowns – work in progress • Integration with other systems might be more important than initially thought?

19. Lessons LearntWhat would we do differently? • Ensure we maintained a Sandbox • Keep your partner informed; ensure they can support you • We ‘assumed’ they would have the capacity to support our needs • Identify all systems requiring integration • Thoroughly assess all potential pros and cons and consult the organization • Do not allow the team to get carried away with the new tool • Limit access until key requirements/design activities complete • Try to limit the number of managers in working sessions • Use the managers for validation and not for definition • Try to control personal agendas and dominant individuals

20. Lessons Learnt What should we do differently? • Always carry your champions with you every step of the way • Using UPK would provide valuable help at the touch of a button • Schedule refresher working sessions periodically • Targeted Brown Bag sessions • Training re-runs • Keep the Templates to an ‘absolute’ minimum; especially for Phase II • Keep sight of that primary principle, to keep it simple • There will always be enough time to add complexity later.....

21. Lessons LearntSummary • Whatever you do it is never enough….. natural resistance! • The training will never be enough • The help sessions will never be enough • However many times you repeat something will never be enough • However many times you show them something will never be enough • In other words, stating the obvious here….. TRAINING and HELP is Key to Success! • There will always be exceptions • You can’t teach old dogs new tricks • Keep the communications flowing – take the organization with you on the journey • Don’t let personalities dominate the project or working sessions • Ensure the requirements capture and use cases are fully documented • Limit system access until this is completed • Don’t assume providing a useful tool that had been discussed for many years will be welcomed with open arms..... • The key concern was how long will this data capture take each week? • Keep your expert close • We lost close contact with our Primavera Consultant during Phase II • Keep your supporters even closer • Don’t lose the internal help and support

22. The Journey Ends?Summary and Questions • As we all know the journey never ends…. • We continue to improve and learn • Was the journey worthwhile? • It wasn’t perfect, but I would definitely say yes; there are others who might disagree, but then again nothing is perfect? • Did we achieve what we set out to achieve? • For Phase I definitely • For Phase II partly • and for Phase III we will have to wait and see..... • So for the $64000 question, does it work in an IT Service Environment? • Most definitely, but you have to pay extra attention - what exactly are you trying to achieve from the deployment • It is not a ‘one size fits all’ environment Any Questions?

23. If you have any further questions or need any information, please contact either:Chris Lynhamchristopher.lynham@oracle.comDave Graham david.graham@oracle.com