Gartner Consulting Critical Program Management GITA Project Management Symposium October 24th 2006

2. The Frightening Statistics Ensure Success �66% of large scale programs fail to achieve their stated business objectives, are delivered late, or are substantially over budget� � Standish Group. Manage Risk �Through 2008, IS organizations without stringent risk-assessment procedures and mitigation plans will cancel at least 10 percent of programs initially budgeted at more than $200,000 and at least 20 percent of all projects� (0.7 probability)

3. Let�s Talk About Defining Failure Reason (in rank order) Technology did not work Did not meet the requirements It was late Requirements had changed The users would not use it Did not produce the expected benefits No longer mattered to the business Failure in business change management Other reason(s) Forbes and Gartner jointly conducted an online survey of subscribers to the forbes.com Web site. More than 2,300 surveys were completed, 462 of them were from companies with 1,000 or more employees. In all, 264 people from firms with over 1,000 staff provided information on 520 projects. Failure to deliver the specified system by the due date was cited in 62 percent of projects. A problem with organizational change management was cited in 45 percent of cases. Problems in coping with scope changes affected 35 percent of projects. In 31 percent of cases, respondents stated that the IT system was delivered and used, but that the  benefits were not obtained. Forbes and Gartner jointly conducted an online survey of subscribers to the forbes.com Web site. More than 2,300 surveys were completed, 462 of them were from companies with 1,000 or more employees. In all, 264 people from firms with over 1,000 staff provided information on 520 projects. Failure to deliver the specified system by the due date was cited in 62 percent of projects. A problem with organizational change management was cited in 45 percent of cases. Problems in coping with scope changes affected 35 percent of projects. In 31 percent of cases, respondents stated that the IT system was delivered and used, but that the benefits were not obtained.

4. OK�. So There is a Problem�. Most IT organizations have formalized a budget threshold above which proposed IT projects come under increased scrutiny. Despite this, risks of project �crashes� remain high, with many IT executives and business managers now cynically accustomed to breakdowns, project stoppages or major business disruptions from late system delivery or accumulated budget excesses. Causes of these project crashes are many and varied. We refer to one as �fog,� meaning a lack of visibility into risks, delays, the cumulative effect of scope creep and more. Another can be characterized as �quicksand,� in which a lack of consistent, efficient analysis and definition causes projects to bog down in early phases, stuck in disagreements over and changes to vague requirements. By contrast, premature haste forges ahead with construction without sufficient definition or agreement, often requiring backtracking and rework. This is often characteristic of a �cowboy culture,� in which IT staff have a maverick image and approach with an aversion to defined policies and procedures. Other causes include the �novice in the cockpit� phenomenon, whereby project management is not seen as a distinct skill set, so that unqualified staff are made managers of projects with too much complexity and risk for them. �Homeless� project managers fill an ad hoc role and lack an organizational context � lessons learned are not shared, no project portfolio view is maintained, training in the organization�s methodologies and tools does not occur, and project managers wander from project to project; and when they succeed, they often seek advancement elsewhere. Most IT organizations have formalized a budget threshold above which proposed IT projects come under increased scrutiny. Despite this, risks of project �crashes� remain high, with many IT executives and business managers now cynically accustomed to breakdowns, project stoppages or major business disruptions from late system delivery or accumulated budget excesses. Causes of these project crashes are many and varied. We refer to one as �fog,� meaning a lack of visibility into risks, delays, the cumulative effect of scope creep and more. Another can be characterized as �quicksand,� in which a lack of consistent, efficient analysis and definition causes projects to bog down in early phases, stuck in disagreements over and changes to vague requirements. By contrast, premature haste forges ahead with construction without sufficient definition or agreement, often requiring backtracking and rework. This is often characteristic of a �cowboy culture,� in which IT staff have a maverick image and approach with an aversion to defined policies and procedures. Other causes include the �novice in the cockpit� phenomenon, whereby project management is not seen as a distinct skill set, so that unqualified staff are made managers of projects with too much complexity and risk for them. �Homeless� project managers fill an ad hoc role and lack an organizational context � lessons learned are not shared, no project portfolio view is maintained, training in the organization�s methodologies and tools does not occur, and project managers wander from project to project; and when they succeed, they often seek advancement elsewhere.

5. So what did the successful ones do? They found ways to manage the non-technical issues! They had strong program management offices that were organized for success They conducted program assessments of the status of the programs They hired third parties to provide program oversight on their critical programs They were brutally honest about the root causes of their particular programs, and were willing to make changes Fighting the �Fog� Standard program management methodology Project scorecard Fact-based measurement of progress, schedule, costs, and risks: collected by PMO, required for all projects Sponsor has direct visibility into project, not only through project/program manager Regularly scheduled status reviews and assessments No �Novices in the Cockpit� Understand breadth of skills required: Leader of a large program (>$10 million) is in effect the CEO of a mid-size company Project/program manager certification Compensate �master� program managers Ongoing project/program manager coaching and assessment Avoiding �Quicksand� and Preventing �Premature Haste� End-user accountability for project/program success Focus on the benefits Require formal sign-offs on definitions of scope and functionality; PMO and/or program outsider �audits� signoffs System development methodology: sample analysis and definition deliverables Counteracting the �Cowboy Culture� IT Governance Board: primarily end-user stakeholders PMO Accountable to Governance Board, not just to CIO (Same relationship a CFO has to the CEO and the Board of Directors) Avoiding �Homelessness� �If a project is worth doing, it is worth sponsoring� Sponsor�s span of control vs. project/program budget: at least 5x PMO Reports status of sponsorship to IT Governance Board Fighting the �Fog� Standard program management methodology Project scorecard Fact-based measurement of progress, schedule, costs, and risks: collected by PMO, required for all projects Sponsor has direct visibility into project, not only through project/program manager Regularly scheduled status reviews and assessments No �Novices in the Cockpit� Understand breadth of skills required: Leader of a large program (>$10 million) is in effect the CEO of a mid-size company Project/program manager certification Compensate �master� program managers Ongoing project/program manager coaching and assessment Avoiding �Quicksand� and Preventing �Premature Haste� End-user accountability for project/program success Focus on the benefits Require formal sign-offs on definitions of scope and functionality; PMO and/or program outsider �audits� signoffs System development methodology: sample analysis and definition deliverables Counteracting the �Cowboy Culture� IT Governance Board: primarily end-user stakeholders PMO Accountable to Governance Board, not just to CIO (Same relationship a CFO has to the CEO and the Board of Directors) Avoiding �Homelessness� �If a project is worth doing, it is worth sponsoring� Sponsor�s span of control vs. project/program budget: at least 5x PMO Reports status of sponsorship to IT Governance Board

6. Critical Program Management

7. The Level of Support Needed

8. Program Management Office (PMO) Gartner has identified three PMO models. The PMO model typically evolves from the repository model through to the Enterprise PMO model as the value of the PMO is recognized within the organization.

9. Scope of a PMO

10. Program Management Office Best Practices and Metrics

11. Program Assessment Preventative Medicine IV&V (requirements through deployment) will increase development costs 10% to 18% percent �. but� 20% - 28% of IV&V costs can be recovered if IV&V starts with coding 92% - 180% if IV&V costs can be recovered if IV&V starts with requirements. Costs of IV&V are offset by fewer problems and errors, and higher customer satisfaction.

12. Program Assessment Four main steps: Program planning Data gathering Analysis Recommendations Can enter a project at any phase Value: It�s a look at what you did or are doing Offers recommendations for immediate and/or future improvements Analysis can be customized to match your culture

13. Program Assessment ToolsDetailed Questions Drive Summary Results

14. Program Assessment Multiple Ways to Assess and Program

15. Program Assessment Multiple Ways to Assess a Program (continued)

16. Program Assessment Continuous Progarm Reviews of Risks

17. Program Assessment Continuous Program Reviews of Risks

18. Program Assessment Continuous Program Reviews of Risks

19. Program AssuranceCritical Program Management Framework

20. Critical Framework 1: Project/Program Management

21. Critical Framework 2: Financial Management

22. Critical Framework 3: Performance Management

23. Critical Framework 4: Organizational Management

24. Critical Framework 5: Change Management

25. Critical Framework 6: Contract Management

26. Critical Framework 7: Supplier Management

27. Critical Framework 8: Customer Management

28. Critical Framework 9: Solution Management

29. Foundational Element 1: Risk Management

30. Foundational Element 2: Portfolio Management

31. Foundational Element 3: Enterprise Architecture

32. Foundation Element 4: Governance

33. Each critical framework has a tailored but flexible approach to support the critical success factors of each phase

34. Mitigating the Root Cause of Program Failures Three Examples

35. Root Cause: Governance

36. Root Cause: People and Change Pitfall #4: People Issues are Minimized When comparing the people, process and technical challenges encountered during a deployment project, it is often the people issues that represent the most significant challenge to project success. There are many factors, from organizational alignment to communication to leadership to culture but it enabling the change in the people that can have the most dramatic impact. To properly devise a change management plan, you must recognize three distinct camps of individuals and create change management strategies appropriate to each camp. First, those employees that are resistant to change. These experienced resources are likely to feel threatened by the initiative and have close ties to the legacy state. These people will be the biggest critics of the initiative, but, once converted, they will become the biggest advocate, or an �evangelist�. Effective strategies here include active engagement, making them responsible for delivering change, providing incentives, and guiding them with very decisive leadership. Some employees are simply not prepared for change and need education and training. In some cases, career counseling may be required. The remainder of employees are really not aware of the impact of change on their day to day activities. These people need clear communication and broad exposure to the initiative but they will typically follow an �evangelist�. It is important to note that not all change is negative, or viewed as negative. There are cases where change is embraced. In these more positive cases, the �Won�t Change� characters may be drastically reduced but you must still pay attention to those who can�t change and those that lack awareness of change. Action Item: Create change management approaches for specific audience. Focus on those most resistant to change.Pitfall #4: People Issues are Minimized When comparing the people, process and technical challenges encountered during a deployment project, it is often the people issues that represent the most significant challenge to project success. There are many factors, from organizational alignment to communication to leadership to culture but it enabling the change in the people that can have the most dramatic impact. To properly devise a change management plan, you must recognize three distinct camps of individuals and create change management strategies appropriate to each camp. First, those employees that are resistant to change. These experienced resources are likely to feel threatened by the initiative and have close ties to the legacy state. These people will be the biggest critics of the initiative, but, once converted, they will become the biggest advocate, or an �evangelist�. Effective strategies here include active engagement, making them responsible for delivering change, providing incentives, and guiding them with very decisive leadership. Some employees are simply not prepared for change and need education and training. In some cases, career counseling may be required. The remainder of employees are really not aware of the impact of change on their day to day activities. These people need clear communication and broad exposure to the initiative but they will typically follow an �evangelist�. It is important to note that not all change is negative, or viewed as negative. There are cases where change is embraced. In these more positive cases, the �Won�t Change� characters may be drastically reduced but you must still pay attention to those who can�t change and those that lack awareness of change. Action Item: Create change management approaches for specific audience. Focus on those most resistant to change.

37. Root Cause: Managing Expectations Emphasizing Value During Implementation Too often, implementation initiatives have been undertaken with little or no business case. If asked, many project team members, let alone users or executives, would be unable to identify the purpose of their project (other than implementing the application). Even where business cases were developed, there was no explicit connection between the project and the intended business results. Additionally, users often failed to document pre-ERP performance indicators as a baseline for improvement measurement. With continued emphasis on value, enterprises must change their approach to justifying, planning and executing business application implementations. First, users must develop a believable and defendable business case. Second, users must document the current state so improvement can be measured. Third, project managers should link planned benefits to specific project activities. Fourth, and most important, project managers must keep improvement targets visible to the project team. Too often, a project team�s only focus is to deliver on time and on budget and it loses sight of what it is delivering. Fifth, after processes are designed and conference room pilots are progressing, project teams should validate that planned improvements are part of the configured solution. Lastly, continuous improvement initiatives should be launched. An enterprise is never �done� implementing a business application and improvements, driven to enhance business value, need to be part of any ongoing enhancement effort. Action Item: During the implementation process, keep a focus on planned improvements to validate that intended results will be delivered.Too often, implementation initiatives have been undertaken with little or no business case. If asked, many project team members, let alone users or executives, would be unable to identify the purpose of their project (other than implementing the application). Even where business cases were developed, there was no explicit connection between the project and the intended business results. Additionally, users often failed to document pre-ERP performance indicators as a baseline for improvement measurement. With continued emphasis on value, enterprises must change their approach to justifying, planning and executing business application implementations. First, users must develop a believable and defendable business case. Second, users must document the current state so improvement can be measured. Third, project managers should link planned benefits to specific project activities. Fourth, and most important, project managers must keep improvement targets visible to the project team. Too often, a project team�s only focus is to deliver on time and on budget and it loses sight of what it is delivering. Fifth, after processes are designed and conference room pilots are progressing, project teams should validate that planned improvements are part of the configured solution. Lastly, continuous improvement initiatives should be launched. An enterprise is never �done� implementing a business application and improvements, driven to enhance business value, need to be part of any ongoing enhancement effort. Action Item: During the implementation process, keep a focus on planned improvements to validate that intended results will be delivered.

38. Conclusions A significant amount of money is spent on programs and projects that never achieve the value that was intended The biggest reason for their failure are cultural or political in nature There are things that organizations can do to prevent these failures Implement an effective program management office Conduct periodic program assessments to ensure they are on track Bring in the needed expertise to do program oversight and ensure the success of your program Take a brutal look at the root causes of past project failures (requires processes to capture past practices)