notebook

Viewing project portfolios against constraints....to determine what can be accomplished with available resources

Traditional "project scoring" systems we see are a list of projects in a spreadsheet scored against some sort of measurement criteria. 

Most project ranking schemes stop at the ranked list of projects, at best. The problem is that you never know if the prioritized list can be completed without knowing what resources it takes to get all the project done, satisfactorily. 

These "constraints" must be applied to the project portfolio to determine "what can actually be done." A ranked list of projects is just the first step. This tells you what could be done, but not what can be done given available (and now "diminishing" in some organizations) resources. In addition to cost, material/equipment, and people constraints there are RISKS that need to be considered when selecting the optimal portfolio mix. Further, there are also the MUST HAVES that tend to override the basic logic of constraints. Without factoring in the constraints--just prioritizing projects in a portfolio is only 50% of the solution.

In the example above you can see a simple illustration of a budget constraint being applied to my little project portfolio. I need $10,150,000, but I only have $9.5M. The model applied the constraints and dropped the lowest ranking project. Simple to illustrate the point, but this gets more interesting when more projects are added into the mix and other factors such as RISK and MUST HAVES are factored into the model.

Use real values for ranking alternatives

Traditional "project scoring" systems we see look like this... a list of projects in a spreadsheet scored against some sort of measurement criteria. Sometimes the criteria is weighted by importance.

Further, the scoring of alternatives (or development projects) tends to be against simple numeric scales, such as 1-5 (i.e. 1 being low and 5 is high). Although this does provide a scoring system of sort, it falls short in really explaining the measurement criteria each project should be ranked against. It also requires a "look-up table" to cross reference what "5-high" really means.

Rather, we add the specific values to the model, such as the actual $ estimates for each objective/criteria. This improves the accuracy of the ranking model and its value as a communication tool.

Pairwise ranking of objectives versus simple weighting

Traditional "project scoring" systems we see look like this... a list of projects in a spreadsheet scored against some sort of measurement criteria. Sometimes the criteria is weighted by importance.

The "weighting of criteria" approach does provide some degree of influence over the project scoring results, but it fails to capture the proportional relationships between criteria or what we like to call "Objectives."

Rather, we use a "pairwise" technique to compare the relative importance of one Objective over another. Further, this method of generating weighted values for each Objective provides dynamic group discussions between team members when facilitated correctly.

Horizontal project scoring versus vertical prioritization (the zero-sum game)

Traditional "project scoring" systems we see look like this... a list of projects in a spreadsheet scored against some sort of measurement criteria. Sometimes the criteria is weighted by importance. Each row (project) is scored against the weighted criteria. The rows are totaled and each project gets a score. Some have called this "horizontal scoring."

When one changes, the rest stay the same.

The problem with this type of simple scoring system is that, a) you don't see the relative impact new projects have on the current portfolio, b) you don't see the impact (on other projects) when one project receives a higher score, and c) you tend to get very close project scores to the point that there is very little differentiation in scoring values, rendering the scoring system of little value.

Who "owns" the strategy?

 Define ownership after first defining what needs to get done...

"Organize around the work, rather than force the work to conform to the organizational structure..." said GE's Jack Welch. We've applied this concept to strategy mapping.

The strategy map (right) illustrates a 3-year Vision, its supporting Initiatives, and driving Strategies. Our focus was on defining the Strategies that would drive achievement of the Vision, rather than from an organizational perspective. Our view was from the Vision - out (i.e. where the business needed to go in three years), not from the Business Unit - in.

After defining the work flow, we then assigned ownership of each cross-functional initiative. This caused the senior management team to work together and cooperate on the common goal, rather than focus inwardly within the Business Unit "silos." Note that names and details have been modified so we can present the example.

Operationalizing business strategy in your project portfolio (an example)

More on this subject here.

This example illustrates the process of mapping strategy and then setting program priorities. The key is to link strategy formulation with the means to realize the results (i.e. execute). It illustrates the linkage between vision-strategy-program. 

 

In this example we; a) mapped the current strategy (we organized and normalized an existing strategy around a common structure), b) prioritized the strategic initiatives based on four "success criteria," and c) prioritized about 100 programs/projects spread across four business units. The following example has been modified to protect client confidentiality.

Planning template for fastStrategy portfolio deployment

This planning map broadly outlines a planning template we developed through a series of deployment projects with clients.

First we set the goals that are expected from the deployment and define and prioritize the objectives or outcomes.

We then refine the stage metric to reflect the specific client environment. This is followed by an analysis of driving and restraining forces. We know if we remove the restraining forces we will not have to "push" as hard to cause change.

The Potential Problem Analysis (PPA) helps us explore the potential problems we may encounter during implementation and to put in place contingent actions to mitigate these problems. Then we develop a deployment schedule based on the stage level target and the varous functional groups that need to be engaged. Finally we refresh the schedule weekly with the deployment team to track progress and trends towards our targets.

Deploying portfolio management using a 4-stage maturity metric

We've developed a deployment process flow for engaging management teams in effective new product portfolio prioritization using a 4-stage metric.

Each stage increases in degrees of sophistication. These levels permit groups to deploy the process at their level of readiness. Typical implementations see different groups in the organization at different stages. Our clients set a target date for all groups to reach Stage 4, they progress at their own speed gaining value at each stage. The framework provides a metric to measure progress.

Zero-Based Budgeting

 "Zero-Based Budgeting (ZBB) allows top-level strategic goals to be implemented into the budgeting process by tying them to specific functional areas of the organization..."  (source)

It is a technique of planning and decision making where every department function within an organization is analyzed for its needs and costs for the coming period (starting from a zero base). 

Budgets are then built around what is needed regardless of previous budgets. The advantages claimed are that it drives functions to be more cost-efficient (by avoiding blanket increases of decreases based on the previous period's budget) and can eliminate waste, but it can also very time consuming.

The question is - how can one implement this?

Implementing ZBB

fastStrategy allows top-level strategic goals to be prioritized. Projects are then aligned (prioritized) to those strategic goals. Functional groups are defined and resources from each function are allocated on a project by project basis. This results in a "what is needed" by function to execute all projects as well as providing an overall budget for the organization.

 

Budgets can be optimized by applying budget and resource constraints (by function) to the model in order to meet an overall budget requirement. If within budget, then all projects get funded. If there are constraints (budget or resource), the model will eliminate projects in such a way that the remaining projects maximizes the overall benefit.

 

A cost-benefit chart can be generated that provides a starts control such that those projects with the highest cost-benefit ratio get started first.

 

By refreshing the model every period (monthly, quarterly, annual), the pain over implementing ZBB can be diminished. fastStrategy provides a means to implement to link top-level strategic goals to individual functions, and because it can support multiple models within a single file, each budget cycle can be kept for historical purposes.

Increasing new product success rates using better front end selection models

"My division has a product success rate of 9%, how can I improve our performance?" said one general manager recently.

Increase your new product success rate by finding the root causes of poor performance and translating these into selection criteria to pick better products (to develop). This process also uncovers issues that are causing the wrong products to be defined in the first place. Better failure analysis, i.e. why do some new products miss their targets?, can be translated into better new product selection criteria so that more good ideas get into the development pipeline than bad ones.