AD643

1. AD643 • Stakeholders

2. Program, or Project? • 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 • A program is typically a portfolio of related projects that deliver one or more benefits

3. The Four Key Components of a Project • 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. Why benefits analysis is needed… • Benefits analysis identifies what positive value is expected to be obtained from a project. • Helps in the assessment of whether the project is worth doing. • Provides a basis for future assessment of whether the benefits were realised.

19. Identifying the benefits There are two types of benefits: • Tangible benefits: where the dollar value of the benefit can be easily assigned because values are readily measurable. • Intangible benefits: where the dollar value of the benefit is not able to be assigned.

20. How are benefits identified… • The sponsor of the project is the best person to identify the benefits. The sponsor owns the benefits. • Consult with a number of different areas that are going to be impacted by the solution to identify additional benefits • Brainstorming is a useful technique for identifying possible benefits.

21. Examples of tangible benefits • Reduce clerical labour costs • Reduce clerical equipment expense • Reduce space & overhead costs • Reduce inventory carrying expense • Reduce accounts receivable & bad debts • Increase sales by 10%

22. Examples of intangible benefits • Improve customer service • Make better business decisions • Increase market share • Better manage financial resources • Improve company image

23. 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

24. 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

25. 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

26. 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

27. 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

28. 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

29. 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

30. 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

31. 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

32. 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?

33. 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

34. 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

35. 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

36. Gap analysis • Many projects are an iteration on something that exists, whether that be a product, a service, process, and so on • In a gap analysis, we • Examine the current state thoroughly • Use stakeholder analysis to determine what the end state should look like • Create a plan for getting from the initial state to the end state

37. A gap analysis is often one of the initial communications documents created • The analysis might stand alone and be used as a way to solicit internal or external bids, or it might include a proposal to complete the work • If a proposal is included, most time and budget values are very high level • The proposal is often for a feasibility study • In RUP terms the gap analysis is in the Inception phase

38. If the feasibility portion of the proposal is accepted, a statement of work would be created • The SOW includes finer-grained detail of budget and schedule • In most organizations it is the signed-off SOW that initiates a project

39. Conclusions • As a project manager one of your most important jobs is to manage stakeholder expectations • The mechanical part of running a project usually takes care of itself • Figuring out who the real stakeholders are is a key to becoming a successful manager

40. Additional Sources • Charles Sturt University: Benefits Analysis • Project Management Institute • Thiry, Program Management