Stakeholder Management AD642 Stakeholder Management

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

The Four Key Components of a Project Decision Management Governance Stakeholder Management Benefit Management

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

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?

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

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

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?

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)

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

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

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

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

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

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

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

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)

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. Notes: 18

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. Notes: 19

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. Notes: 20

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% Notes: 21

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

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

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

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

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

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

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

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

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

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

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?

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

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

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

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

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

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

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

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