Title Guaranty of Hawaii’s Road to Enterprise Project Management (EPM) – A Case Study

1. Title Guaranty of Hawaii’s Road to Enterprise Project Management (EPM) – A Case Study Deb Pyrek

2. Introduction • Title Guaranty (TG) is Hawaii’s largest Title and Escrow company. • TG provides real estate settlement services and title insurance to the local community and international customers.

3. Introduction • Business requires innovation to stay ahead of the competition, and innovation requires new projects and initiatives. • With many ideas and limited resources, Title Guaranty needed to improve their project management processes. • Title Guaranty decided to adopt a more formal project management process and implement Enterprise Project Management (EPM).

4. Outline • TG’s project management history • Need for change • Is Enterprise Project Management the solution? • EPM Proof of Concept, Pilot, Implementation • Challenges and Opportunities • TG’s EPM Timeline • Project Management at TG today • Plans for the future

5. Project Statistics The following statistics from Gartner Group and other analysts highlight the importance of managing projects effectively. • 70% of all technology-related projects are likely to be challenged or impaired • 20%-30% of these will fail outright

6. Project Statistics • Non-canceled project will experience: • Cost overruns in excess of 150% (on average) • Schedule overruns of 175% (on average) • Deviation from original specifications of at least 30%

7. Project Statistics • The larger the project, the more likely it is to slip schedule or fail outright • Large software projects have a 65% cancellation rate • Similar statistics are provided by Meta Group. On average, projects at completion: • Are 189% over budget • Are 222% late • Contain only 60% of their original features.

8. TG Project Management History • “Old” project management methods • Challenges we faced • Limited success

9. “Old” Project Management • Documentation • Standard format existed but not always used • Specifications at a very high level, much room for interpretation • Often completed after-the-fact • Not always updated to reflect changes • Process • Loosely followed Microsoft Solutions Framework (MSF) process

10. “Old” Project Management • Project Team • No trained Project Managers • The Project Manager is the person who had the idea • Or the IT person who talked with the person who had the idea • Teams followed MSF roles, but most roles were filled by IT staff • Not all team members understood their roles

11. “Old” Project Management • Resources and Schedule • Lacked structured resource planning • Resource planning meant asking the question “when can you get that done” • Low commitment from some staff to participate on project • No easy way to know about delays, changes in priority, etc. • Projects were just late.

12. “Old” Project Management • Scope Creep • Weak specifications led to many changes in scope. • Many last minute “can you just add this feature?” requests • Rework • More often than not, new requirements were discovered at rollout. • Required reprogramming, retesting, redocumenting, etc.

13. “Old” Project Management • Limited Success • Some projects were successful, but typically delivered late • Some projects required several unplanned iterations before meeting requirements • Some projects rolled out but were never used • Some projects rolled out and were used, but with low user satisfaction • Some projects rolled out but resulted in operational chaos or had a huge support impact

14. Confirmed Challenges with Management • Lack of visible leadership behind new ideas/projects • Do we need more clarity about who is supporting this effort? • Do we need better support from managers, executives, owners?

15. Confirmed Challenges with Management • Sometimes the idea is not well thought out, specifications are not clear • Do we need to do a better job validating the ideas and confirming we have all the necessary information? • How do we minimize surprises after we are far into the project? • How can we better measure where we are on a project? • How should we revisit the plan throughout the life of the project to make sure we are on track?

16. Confirmed Challenges with Management • The plan is not always communicated effectively • How should we share information about project status, priorities?

17. Confirmed Challenges with Management • Often, there is no timeline or we exceed the planned schedule • Why do we see this happen so often?

18. Confirmed Challenges with Management • We struggle to get people working on our project teams • Perhaps we are not sure who is on the team or how to get resources allocated to the team • Do we have the right people in the right role on the right team?

19. Confirmed Challenges with Management • Often the same people are on many projects – over-allocated resources! • Do we need to do a better job managing resources? • How do we find out who is doing what so that we don’t assign too many things to the same person? • How does a project manager get things done when the people on his/her team report to a different manager?

20. Confirmed Challenges with Management • Often difficult to get accurate status information about the project • Are there too many concurrent projects?

21. Confirmed Challenges with Management • Implementing a new idea, process, system, etc. is difficult • Why are our rollouts so challenging? • How can we do a better job rolling things out?

22. Confirmed Challenges with Management • Conflicting priorities, resources • Do we have different opinions about priorities?

23. What do we need? • We needed to prioritize and report on all the projects across the organization • We needed to manage resources across the organization • We needed more diverse and committed project teams • We needed better methods to manage projects • We needed tools to make all of this easier

24. Solution – EPM • Researched Enterprise Project Management (EPM) • “Sold” EPM to Senior Management • EPM Proof of Concept • EPM Pilot

25. ResearchFeedback from those who have gone before us… • Approximately 20 companies were contacted about their EPM implementations. All have successfully implemented an EPM solution. • Not one company was able to do this without dedicated staff.

26. ResearchFeedback from those who have gone before us… • All companies had some form of a PMO (Project Management Organization) with multiple dedicated staff members. • Most companies of our size (500 – 600 employees with less than our number of projects) had 5 or more dedicated project management staff working in their PMO department.

27. ResearchFeedback from those who have gone before us… • Some companies had a mix of dedicated PMO staff and department heads/managers serving as project managers.

28. ResearchFeedback from those who have gone before us… • Some companies did not dedicate staff to the project initially, or did not clearly define their procedures up front during the planning stage. • These companies had to run a second pilot or suffered long delays in implementation due to significant amount of rework, redesign, additional consulting hours, etc. • Only after they assigned dedicated staff and spent the time to clearly define procedures were they able to move ahead.

29. ResearchFeedback from those who have gone before us… • Users, management, and project managers are often reluctant to try EPM and require help to understand the benefits of EPM. • Training is absolutely critical for all project managers who will be involved in an EPM implementation. • Strong executive sponsorship is critical for the success of an EPM implementation.

30. Find Key Opinion Leaders

31. Involve Key Opinion Leaders • Get them using solution quickly • Solicit and incorporate their feedback • Ask for their guidance • Focus on PMO and governance groups

32. Make it easy for your opinion leaders to talk about the solution Give them quick facts to use Provide a Web site with links to more information Manage the Solution Story

33. Eliminate Adoption Barriers • Don’t create reasons to say no • Restrictions on Functions • Any item they didn’t help create can be viewed as a barrier

34. “Sell” the Problem • Clearly define the problem to be addressed by the solution • The solution becomes apparent once everyone agrees on the problem • Communicate the problem statement repeatedly and consistently • Use problem statement to control scope

35. Build a Community of Advocates • Has to become "our" solution, not your solution • Disbelievers need to hear the message from multiple sources • People distrust the unfamiliar. Give them what they need to understand. • Involve users in the solution governance

36. You Are Your Best Case Study • If you don't use it, why should anyone else? • Builds credibility • Provides opportunity for staff to grow skills ahead of demand for those advanced skills • Use Project Server to manage deployments

37. TG’s EPM Pilot • Establishing success criteria • Technology selection • Consultant selection

38. TG’s EPM Pilot - Scope • Portfolio Management • Doing the right work • Project Management • Doing the work right • Resource Management • Getting the work done

39. TG’s EPM Pilot - Schedule Proof of Concept January 2006 – March 2006 Pilot May 2006 – November 2006

40. TG’s EPM Pilot - Resources • Staff • Volunteer EPM Pilot team • Volunteer PMO • Costs • Consultants • Hardware/Software

41. TG’s EPM Pilot - Validation • Checkpoints • Go/No Go Gates • Mini-decisions • Approval to Proceed to next Checkpoint

42. TG’s EPM Pilot – Test Project • Vacation Ownership System • Tested many aspects of EPM processes • Project Management • Resource Management • Team Roles • Documentation Standards • Software Tools

43. TG’s EPM Implementation • Transition from Pilot to Production • Establishing a PMO • Establishing a Priority Board

44. TG’s EPM Implementation • Committing Dedicated Resources • PMO Manager • Project Managers • Systems Analysts • Operational Resources

45. Challenges & Opportunities • Culture Change (Culture Shock) • PMO “overhead” and ROI • Why do we need consultants? • How hard can it be? • You can get all of this done over the weekend, right?

46. Lessons Learned • Persistence is key, don’t give up! • Just because you said it doesn’t mean they heard it. • What’s obvious to you is not always obvious to others. • If you ignore it, it won’t just go away. • Don’t expect others to join you just because you say so – you must sell this!

47. TG’s EPM Timeline 09/2004: IT team starts to investigate EPM, takes PMI Training 05/2005: IT Team (w/Consultant) Performs Readiness Assessment 09/2005: IT proposed EPM concept to senior management 12/2005: Approval to hire consultants & start EPM Proof of Concept 01/2006: Kickoff – Proof of Concept 03/2006: Proof of Concept complete 05/2006: Approval to proceed with EPM Pilot 06/2006: EPM Pilot 1st checkpoint & go/no go decision 07/2006: 2nd checkpoint & go/no go decision 08/2006: 3rd checkpoint & go/no go decision 09/2006: Priority Board established, PMO established (volunteers) 10/2006: 4th checkpoint & go/no go decision 11/2006: EPM Approved for Implementation 11/2006: Software tools purchased 01/2007: Priority Board selects priorities, official PMO members confirmed 03/2007: First post-pilot project complete

48. Project Management at TG today • Successful projects • Successful teams • Increased productivity • Effective communication • Clarity of goals • Still more work to be done

49. Plans for the future • Improving tracking • Improving forecasting • Improving Resource Management • Improving Portfolio Management • Increasing output

50. Contact Information: Deb Pyrek VP Information Systems Title Guaranty of Hawaii, Inc. dpyrek@tghawaii.com Jerry Opedal PMO Manager Title Guaranty of Hawaii, Inc. jopedal@tghawaii.com Questions? Thank you to our LMR consulting team from San Diego for their support of our EPM efforts and for slide contributions.