AD646Program Management - Program Development

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

The Four Key Components

• 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)

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