1. AD646 Program Management - Program Development

2. Program, Not Project (redux) Many organizations say ‘ project management ’ when they mean ‘ program management ’ and vice-versa Really they are two separate disciplines A Project Management Office (PMO) might or might not be responsible for programs

3. The Four Key Components Decision Management Governance Stakeholder Management Benefit Management

4. Decision Management Different from decision making Decision making: Tends to focus on the process of making a decision Measures the efficiency and acceptance of decisions Assumes that decisions are relatively static Decision management: Allows for ambiguity and uncertainty Focuses more on meeting strategic goals Features continuous assessment and adjustment

5. A Question Does it follow that the more data you have in hand about a particular problem, the better the decision that can be made?

6. Simple Decisions In low-ambiguity situations (the lower-right quadrant), the outcome of a decision can be fairly certain Same with low-uncertainty (upper-left quadrant); the path is fairly clear In both cases, decisions can be made simply with tools such as SWOT Not much intuition needed Decisions do tend to be static

7. More Difficult Decisions When ambiguity or uncertainty or high, data often isn ’ t enough In some cases it makes things worse! (Why?) Project-level decisions are often simple, but program-level decisions are typically not

8. Mintzberg ’ s Radical Model The model is fluid ‣ When things are going well (low uncertainty), use traditional tools to make decisions ‣ When things get tough, abandon rationality and do what it takes to get things calmed down again Do you think this model works well for program decision-making?

9. Mintzberg and Projects On a project basis, the do-what-it-takes approach isn ’ t all that bad Project plans tend to put bounds on the actions that can be taken Getting a project back on track through ‘ heroic ’ means isn ’ t all that unusual (After all, if project decisions were perfect, we wouldn ’ t need project managers)

10. A Decision Management Framework Thiery breaks the DM process into two broad pieces ‣ Learning ‣ Implementation Managers move from one stage to another in a continuous pattern

11. Learning Stages Within the learning part of DM, there are four steps ‣ Sense-making: What is really happening and what does this data mean ‣ Ideation: What are the various ways we can approach this problem? ‣ Elaboration: Combine ideas, develop alternatives, evaluate options ‣ Choice: Pick one and move on

12. Implementation The second portion of DM is implementation... doing what we decided to do From a project perspective, we are creating projects that will fulfill strategic decisions There might be several projects needed for implementation Many organizations stop at project delivery and measure success based on the project PMs are measured this way, too

13. Program Evaluation The missing step in many organizations is to relate projects back to strategic goals It ’ s the role of the program manager to constantly evaluate the constituent projects in terms of benefit delivery Project managers need to be aware of strategic goals but don ’ t often have visibility into the entire program

14. Who Cares? Strategy and programs and projects are all very nice, but who is it we are trying to satisfy? In the broadest term: stakeholders ‣ Partners ‣ Human Resources ‣ Program and project managers ‣ Customers ‣ Management ‣ Clients

15. Stakeholder Management Clearly there are many differing opinions on what success means, depending on who the stakeholder is Ignoring stakeholder expectations is a quick ticket to the unemployment office A significant part of program management involves stakeholder expectation management We ’ ll dig into this more in a future lecture For now we ’ ll outline the process

16. SM Process Identify who the stakeholders are Classify stakeholders by power level Identify key stakeholders Discover expectations of key stakeholders Do a feasibility analysis of top expectations Negotiate and inform Continuously assess program progress against expectations

17. Benefits While stakeholder expectations are typically ‘ soft ’ or unstated requirements, benefits are the tangible outcome of a program; it ’ s why we do programs A benefit can be ‣ Enhanced or new capabilities ‣ Contribution to a strategic objective ‣ Financial (cost reduction, avoidance, revenue)

18. How-Why Here ’ s a quick way to figure out if you are working on a project or a program by thinking about benefits ‣ In a project, the focus is usually on HOW to do something...that ’ s the purpose of the project plan ‣ In a program we think about WHY we are doing something...that ’ s the program Clearly the measurement and management are different for the how versus the why

19. Formulation Primary goal: define the business case This first step can be triggered by external or internal pressure to change Consists of evaluating the change from several angles ‣ SWOT ‣ Mapping This phase will be revisited several times during the life of a program

20. Formulation: Vision and Mission The stakeholders agree on a common view of the end state At this point we are not looking at the how but rather the what, with a little why thrown in for good measure An aside: The higher up in an organization you are, the less how you worry about The mission statement that results might be only one sentence

21. Formulation: Define benefits Once the mission statement is complete, we come up with the enabling benefits that will help us reach the end state These benefits will end up being the programs that support the vision It can be surprisingly difficult to get people to agree on these...it is tempting to remain short- sighted, especially at a public company Stakeholder analysis can be used to create a prioritized list of benefits

22. Stakeholder analysis Everyone has slightly different needs, expectations, agendas, opinions, and so on As a program manager, if you ignore or don ’ t understand a group of stakeholders, you won ’ t be able to effectively manage Step 1 is to organize and classify the stakeholders ‣ Group into broad areas (C-level, vendor, etc) ‣ Figure out what influence each has on the program Use this information to understand who the key stakeholders are

23. Needs and expectations Each group of stakeholders might have differing needs A need is ‣ Something necessary for or desired by a stakeholder ‣ Either declared or undeclared ‣ Potential or existing It ’ s critical for the program manager to gather as many needs and expectations as possible in the formulation phase ‣ If you miss significant ones, you ’ ll have to rework the program to meet them Note that the program definition of a need is different than that at the project level, where it is a requirement; in the program it is more ambiguous

24. Use active verbs and measurable nouns to pull needs out of stakeholders (when hot pincers don ’ t work) ‣ In order to increase growth by 20% next quarter, we NEED to ✴ Reduce cost (by how much?) ✴ Improve productivity (by what percent?) ✴ Develop one new market (of what size?) These statements get distilled down to a handful of critical success factors, which must be agreed on by all of the stakeholders

25. A blueprint for success These high-level objectives are the input to the benefits realization plan, or program blueprint They are the starting point to begin discussion of the how While the realization plan can focus entirely on the transition (and this is how PMI does it), it often is more useful to do a complete gap analysis that shows the starting state, transition phases, and end state

26. Critical Success Factors Generally speaking these are the one or two key things at each level of a plan that have to go right for the program to succeed For example ‣ Productivity remain high ‣ Market share should grow Q2Q CSFs can be either generic or specific

27. Generic: High-level, usually tied to broad organizational goals, but not necessarily to programs; these are the why of the company Specific: More closely related to specific strategic goals and thus tied to programs as benefits CSFs are usually qualitative (increase revenue) but must be quantified in order to measure them within the program (by 15%)...else how would you know that you ’ ve succeeded?

28. How do you pick CSFs? Not by hunch Not be political expediency (though you might have a few of these) You must figure out which are most important...the benefit breakdown structure is useful for this You can also use quadrant or other method with the stakeholders...the key is to make the decision objective Once picked, these are the metrics that the program manager must pay close attention to throughout the program lifecycle Prioritizing the CSFs with the stakeholders will make it crystal clear what the expectations are

29. KPIs: Measuring CSFs KPIs are the dimension of a CSF If the CSF, for example, is ‘ increase ebook sales ’, one KPI might be ‘ by 15% by the end of Q2 ’ ‣ The CSF would have been tied back to a strategic benefit of the program... ‘ become the market leader in YA ebooks ’ The KPI must be ‣ Measurable ‣ Feasible ‣ Relevant ‣ Sensitive enough to show change ‣ Timely Just remember: MFRST

30. From CSFs come actions Once the CSFs have been identified, you can start to determine the how at a high level...these are the actions to take to effect the goal The actions tend to spin off into individual projects Generally you want one or more actions (projects) per CSF Techniques for generating actions include ‣ Historical analysis ‣ Brainstorming ‣ Proposal-rebuttal The CSFs and associated KPIs and actions will form the initial business case