Why Prioritize?
/
A senior executive asked us, when presenting our portfolio modeling system, “What business problem does this solve?”That was a good question that required a thoughtful response. I stumbled with my answer, so thought I would try to explain it in this post. Perhaps others have the same question/problem.
Most technology development organizations we see lack the necessary resources to concurrently complete the projects in their pipeline. They tend to be resource starved, in terms of financial, human, and equipment/facilities resources. Many lack a few of the right skills at the right time, since the key people are normally over-allocated and spread between too many concurrent projects. The result is that all projects slow down. The only way to speed one project up is to sacrifice others. Further, we see many projects starting late, because resources failed to roll-off of other earlier projects that were also late in starting due to the same resourcing problem. These are all symptoms of a failure to balance resources with committed projects in the development pipeline.
The problem seems obvious and the solution equally simple. Just reduce the number of concurrent projects such that resources are not over allocated, or increase the number of resources assigned to complete the committed projects in the pipeline — i.e. either reduce the flow in the pipeline or increase the size of the pipe!
So why don’t organizations do it? We have seen, for a number of reasons, senior engineering and marketing executives reluctant to make the difficult decisions necessary to balance projects with the available resources. It is easier for them to say “yes” to everything and let line managers “figure it out” through daily resource management. This just kicks the can down the road in our opinion.
Further, since most organizations have constrained R&D budgets (as a percentage of sales), they are reluctant to increase R&D spending even though this spending has virtually no impact on profitability in most technology companies, while in fact time-to-market has an order of magnitude more of an impact on business performance (see our posts of the economics-of-delay). Cost of being late far exceeds the cost of over spending the R&D budget.
Some additional reasons that resource capacity is not always aligned with project requirements include:
Lots of projects “in play” increases the chances of one being successful.
No reliable system to predict which will be winners and which will be losers — so they all get started.
Inability to say “no.” Easier to say “yes.” “No” requires justification, while a “yes” response usually requires no back-up other than inflated business cases, but then again in Silicon Valley we see very few real business cases. We’ve seen billions spent with little more than a “hunch” and a good Powerpoint presentation.
“Can-do” culture ostracizes executives that speak up against overloading finite resources. “We need team players that can get the job done, so go back and get the job done and stop complaining.”
Inability to kill projects that have slipped past their target completion date; projects who’s ROI is now low, because it is late. Inability to see diminishing returns or admit failure (cut losses before losing more).
The number of projects in a development organization is typically based on the business case for each project, and the revenue/profit they are “expected” to contribute to the business. Loading up the pipeline makes for a good looking business plan. Yet when they are not balanced… and the demand out weights the supply, then all the projects are late, since none of them have the resources they need to be successful. This is usually blamed on poor project team execution and results in a reorganization of people into those line positions that “can get the job done.” Since the root cause of the failure is not fixed, the problem repeats in the future and the blame-game starts again.
Resource anorexic organizations use a lack of resources as the perfect excuse for poor performance. At the end of the day, failure can be blamed on the lack of the right resources at the right time. It is a bulletproof excuse for failure.
Why are projects slow?
They start late, due to a lack of resources rolling over from prior projects (that where also late, causing an endless degrading cycle).
Too many concurrent equal/high priority projects.
Constantly changing project priorities. Project X is high priority today, tomorrow it isn’t.
Lack alignment between the number of people (and their skills) with projects in pipeline.
Target completion dates that are either unrealistic or inaccurately set, due to a lack of good market/competitive information.
Poor project execution.
Poorly defined requirements.
Products that are not aligned with customer needs, as a result requirements are constantly adjusted to meet what people think customers want.
Constantly changing or unstable business strategy.
Missing an opportunity
Executives are missing a big opportunity to lock down commitments from development teams when they fail to balance the portfolio of projects with available resources.
For example, Ed McCracken (former CEO of Silicon Graphics) once told me a great story about his “Cigar Box” method of provisioning new product development projects.
His Cigar Box, he told his development teams, was full of extra money. All they had to do was to tell him what they needed to be successful and he would go to his Cigar Box and get them the money. I observed once when he challenged a team to bring him more requisitions than he could sign. Over about a week’s time the team thought of everything they needed, from people to equipment and materials. Their demands also included dedicated and co-located resources. By the end of the week they exhausted their list of wants and he signed all reqs.
He then announced that they would get everything they wanted, which turned out to be an increase in the project budget of less than 15%, but now they also had to deliver on time. They had no excuses. The 15% increase in OPEX was a fraction compared to what they would gain in being to market on time. He made a good business decision to spend to save time, since his return on that investment was over 100x if they were on time. By properly provision the project, he was hedging his bet that they would be successful and was trying to improve their chances.
He removed the reasons for past failure and then demanded excellent performance. He once said his teams get everything they want, but there was blood on the front steps of the building (I guess this was from the people that spent all his money and didn’t deliver on time). SGI had a very successful run from the late 1980’s to mid 1990’s in the graphics workstation segment. SGI participated in our first best practice study and at that time were very fast compared to IBM, DEC, SUN, and HP. One reason was that they balanced resources with what was in their development pipeline.
Properly provisioning teams takes away their excuses for poor performance and enables executives to demand performance/exceptional results.
Resource starving projects leads to line managers that know they can’t achieve the stretch goals, due to a lack of skills or resources… executives know this also, so they are not hard on them when they fail to deliver on time… this game creates a devolving spiral of failure. The impact to morale in many organizations we have studied is rather significant. Good engineers hate working in a place where they can’t do exceptional work, because they are trying to solve too many simultaneous problems. We have found the optimal ratio is 2.5:1, with each of the 2.5 projects at different life cycle stages, i.e. one starting, one ending, and part of one in the middle.
So you can’t do this on every project…
The Cigar Box is also a finite resource, so all projects can’t get McCracken’s provisioning, since there is a limit to funding development projects. The only solution is to decide which projects get provisioned and which don’t. Kind of like having to select which of your children to feed more or less if you don’t have enough food to feed them all. Every day, they look at you and you empathize with their hunger pains. So they all get a little, but never enough to get healthy. I won’t continue this analogy, since it sounds rather harsh, but you get my point even if it is an extreme example.
The solution is to have a rational fact-based system to prioritize projects, that is based on the objectives of the business. A system that is living and can respond to the dynamics of changing markets, competitive landscapes, and realities of technology/innovation roadmaps. A system that normalizes the heavy weighting of position and expert power in decision-making, so that real group consensus can be reached and so that people feel like they truly participated. A system that gets the best minds to reach consensus about what is more and less important in the context of some overarching goal.
Working with clients to build these portfolio decision models, we find that the problem is getting a group of executives to agree on the business objectives and the relative weight of each objective with respect to the business goal. Most often, the goal statement is somewhat clear and aligned in terms of the strategic direction of a business, but the objectives that must be realized to achieve the goal is not clear or there is not a general understanding of which drivers are most or least important to goal attainment.
For example, using a typical set of business objectives; What is more important, Growing Share in X Segment or Maintaining Flat OPEX? This pairwise judgement forces discussion about what is important relative to the goal of increasing value at X% margin. Of course this begs the question about the goal, which should be a strategic business direction, not simple a restatement of financial targets.
Here is another example of business objectives:
Strong strategic fit
Engage with market maker
Strong value proposition
Low execution risk
It took this group of people about six weeks to reach general agreement between engineering, marketing, operations, and the business line heads on the definition of each Objective and the relative weight of each. Defining what the objectives mean is critical to being able to assess their relative importance.
The first step in the decision-making process is to define the Objectives and prioritize them using pairwise comparisons of importance. This is typically done in multiple workshops with all stakeholders participating in focused discussion.
The priority of each objective will influence the next step; scoring each project as to how well it fulfills each Objective. For example; Project X may be a Strong Strategic Fit, but it also might have High Execution Risk. If the execution risk Objective (low risk projects) was more important than strategic fit, then a Project X would get a low score.
The process of scoring is a somewhat easy thing to do, since most people agree on how projects are scored. But what they tend not to be aligned with are the business objectives that these projects are designed to achieve. So gaining consensus about the Objectives is the first step in a project prioritization business process.
Constraints
Project priorities are not sufficient alone to solve the resource problem in the pipeline. Once projects have been prioritized, with respect to how well they achieve each business objective, the resource constraints must be applied. Applying constraints can change the priority of projects. These constraints include budget (money) in the form of development expense (OPEX and CAPEX) to fund each project, skill sets needed to do the work, and risks associated with each project.
For example, if a complete project portfolio requires $50M to fund and you only have $35M, which projects would get funded and which projects would get killed or delayed? This must be done in such a way as to maximize benefit, which circles back to the weighted business objectives. These business objectives drive project prioritization and also drive the cost-benefit calculation when applying real world constraints.
The top rated projects where funded, then the “must” constraint was applied to fund the lowest ranked project, which caused the top rated project to be excluded (due to its high cost). This combination of projects reduced the overall cost-benefit to 80% with only 74% of the main objective being realized (engaging tier 1 customers).
This analysis can also be done with specific resource skill sets (i.e. subsets of engineering, marketing, and operations functions). This method is used to align projects and their priorities with available resources. This is how the zero-sum games plays out when modeling how new projects will impact an existing portfolio of projects already in the development pipeline. It is a continuously moving target.
Pick-n-Stick
Another common problem we see are project priorities that are always changing, They are never stable for very long. So Project X is top priority this quarter, but in 2 quarters it drops to low priority and its resources are stollen for a new top priority project. The system only works if you can maintain some stability around which projects are at the top and which are at the bottom of the list. One client called it “pick-n-stick” and said they were good at picking, but not good at sticking.
Having said this, the system has to have some flexibility to adjust to change. If a new project ranks high, then in this zero-sum model, others have to drop down in priority. This forces a decision-making process that is usually uncomfortable for those that want all to be equal priority or don’t want to make decisions about which projects are more important than others. It also forces projects that fall below a threshold to be killed/delayed, so their resources can be redeployed on projects that have a greater cost-benefit contribution. In either case, resources are finite in most places, so either the projects get killed or delayed or you add resources to meet the needs of the new projects in order to solve the problem.
Business rationale to prioritize:
When resources are finite (people, equipment, facilities, materials, and money) then projects that consume them must be prioritized. In order to make projects go faster, one needs to balance the available resources in order to properly dedicate the resources necessary to achieve the desired project cycle time, for those high ranking projects.
It is a zero-sum game, when one project is accelerated it stands to reason that other projects have to give. If resources where in fact unlimited, then prioritization would not be needed.
Project success in technology development is based on learning cycles. The faster you learn, the faster you solve problems. Faster learning cycles usually mean more resources. More concurrent learning cycles also means more resources are needed. Doing more and faster concurrent cycles means that problems get solved faster because root causes of failure are discovered sooner. For example, one learning cycle could be 6 months to design, fab, and evaluate a new IC design. Sometime around month 5 you start to identify the root cause of a design failure. You then start a new learning cycle. It takes 11 months to complete 2 cycles. What if the cycle-time was reduced to 4 months through better design techniques, faster fab time, and more efficient metrology analysis. And you are able to start the second cycle on month 2 and and another on month 3. In 6 months you would have the results of three concurrent development efforts. This is not possible if all three steps are constrained by limited skills, facilities, materials, and sufficient numbers of people to do the work. If the cost-of-delay was known, this could be used to justify the resources needed to do three concurrent learning cycles.
Some projects contribute more to your business objectives than others, yet consume the same or more resources. When projects are prioritized based on how they contribute to business objectives, then finite resources can be shifted from low priority projects to high priority projects.
Acceleration usually means dedicated resources. Not necessarily more resources, fewer resources that are fully dedicated to a single task. Prioritization permits managers to make resourcing decisions quickly.
Objectives are usually unclear and misaligned. When objectives are not clear then it is impossible to determine which projects most contribute to achieving those objectives.
New ideas must be considered in the context of the current committed project pipeline. They just can’t be added without considering their impact to the current in-progress projects.