Solving a Problem That is Not a Business Priority

“Ruthlessly rigorous prioritization of (technology, data science) projects based on potential business value and economic impact is the best way to ensure meaningful, successful outcomes.” – Fortune 5 EVP|CTO

Every company has limited capital and human resources in IT and data science. There are never sufficient budget dollars and people to go around to fund all projects. In cases I’ve observed in Fortune 50 companies, new project demand exceeds the available budget by a factor of 2-4 times. Projects must compete for resources during each budget cycle based on their respective relative potential to generate incremental business value.

Data science projects are no exception and are ultimately judged on their ability to “move the needle” on economic performance. That said, in many companies, a lot of political wrangling and “pet project” machinations go into the decisions as to which projects get worked on, i.e., the HiPPO projects – Highest Paid Person’s Opinion.

Fortunately, there are multiple rational, fact-based, data-driven frameworks that help estimate, gauge and compare value and inform data science project decision-making.

In a Harvard Business Review (HBR) article by Kevin Troyanos, “Use Data To Answer Your Key Business Questions,” a heuristic rubric is offered to help prioritize business questions using a two-dimensional grid.

• x-axis (horizontal) – Ability to activate or ability to execute, implement and deploy the solution.
• y-axis (vertical) – Potential to impact business or economic value potential.

High-value key business question (KBQ) projects in the upper right-hand quadrant of the HBR figure, with high ability to activate and high potential to impact, are what you and your business partners want to be working on most of the time. Selecting projects that can be implemented and also deliver significant, tangible, measurable business value and economic impact (e.g., cost reduction, operational efficiency or performance improvement, revenue increase, or customer satisfaction and experience enhancement) can be challenging but is absolutely necessary for long-term success.

Curiosities should be completely avoided, as they consume resources on projects that offer low ability to activate and low potential to impact.

Pipe dreams, sometimes referred to as “moon shots,” offer high potential to impact but a low ability activate. Sometimes companies embark on such projects, despite a low likelihood of success, on the fervent hope that they will succeed and deliver tremendous market leverage or competitive advantage. If the project fails, then they try to extract key learnings to feed into other less ambitious projects.

Incremental improvements offer low potential to impact and a high ability to activate. These types of projects can be effective when an organization is just getting started with data science and is looking for some “quick wins” while they are building momentum and growing the capability to handle larger, more complex and higher-value initiatives. The payoffs are not as great, but if they add some measurable value, and the team sharpens their skills, then that is a win.

Because there will always be many views, perspectives and opinions on how best to prioritize and select among competing projects, a more uniformly applied, objective approach can help level the playing field. For those who prefer a more quantitative approach to scoring and ranking analytics, data science and artificial intelligence (ADSAI) projects, I have successfully utilized the following process in a variety of software and analytics product/solution development settings. (You can easily do this in Excel – one of the only times I will recommend a data scientist use Excel!)

1. Start with a list of your projects by name in Column A, one project per row.
2. Estimate the business value potential in dollars that each project will generate in Column B.
   • For each project, on a scale of 1-10, where 10 is highest business value potential, put a business value potential score in Column C.
3. Assess each project’s complexity as VERY HIGH, HIGH, MEDIUM, LOW or VERY LOW in Column D (if it helps, think as if you were doing Planning Poker estimating Story Difficulty Level with Fibonacci numbers in Agile Scrum).
   • For each project, on a scale of 1-10, where 10 is lowest complexity, put a complexity score in Column E.
4. Estimate each project’s total resources – i.e., labor time, materials, computing – in dollars in Column F.
   • For each project, on a scale of 1-10, where 10 is lowest cost, put a total resources score in Column G.
5. Multiply the scores for each project in Columns C, E and G and put the resulting product in Column H.
   • The maximum score is 10*10*10 = 1,000 (which would indicate a project with highest relative business value potential, lowest relative complexity and lowest relative cost).
   • The minimum score is 1*1*1 = 1 (which would indicate a project with lowest relative business value potential, highest relative complexity and highest relative cost).
   • Each project now has a score from 1 to 1,000.
   • You can think of these scores as a surrogate quantification of the KBQ grid (from the HBR article) for each project’s potential to impact (value and cost) and ability to execute (complexity).
6. Sort the project rows from highest to lowest (score) on Column H.
7. The result is a prioritized list of data science projects, using an objective, quantitative scoring mechanism.

The primary takeaway from this exercise is that the multiplicative scoring approach ensures that not just high business value projects bubble to the top of the list, rather, the magnitude of business value is tempered by a combined effect of complexity and cost. Complexity, in effect, is an important surrogate measure for risk, i.e., the more complex a project is, the more likely you are to run into difficulties that end up manifesting themselves in timeline delays and budget overruns that jeopardize the whole project. In the chart, we see the highest scoring projects are those that have low-to-medium relative business value moderated by (very) low complexity and low-to-moderate costs. The highest value projects, in this example, happen to have the highest risks and costs, which result in a lower score. This is actually a fairly commonly encountered set of circumstances, i.e., high risk/cost, high reward.

Now is when the “fun” begins and people start debating and haggling (i.e., arguing) over the individual and aggregate score for their respective project(s). (This process should be accompanied by a more rigorous financial analysis using NPV, ROI and internal rate of return metrics.)

This is not just a theoretical exercise. When I was a VP of Engineering & Product Management for a division of a $1.3 billion software product company, we had a list of 2,000 feature modification requests (FMRs). We estimated that we had capacity to do about 500 FMRs in a new major product release. We used the above process to rationally, objectively, and as economically and efficiently as possible narrow down the list of projects our engineering team could realistically do in one release cycle. It really does work in practice!