How To Pick The Right Projects For Data Science Teams To Work On

Many Data Science team struggle with prioritization. What should the team spend its limited time working on? Businesses expect teams to produce and project selection is the most important step in meeting those expectations.

Vin Vashishta | Originally Published: July 4th, 2021

Book time with me for Career Coaching or sign up for my Business Strategy for Data Scientists class.

The best Data Science teams say No to a lot of projects. High performing teams could be working on anything but have the discipline to focus on the highest value generating projects. I drive this point home in my Business Strategy class.

Why? Limited resources and high expectations. It is easy to lose sight of the fact, there are a limited number of projects the team can execute on every year. Projects should be selected intentionally to create the highest possible returns.

Senior leadership is watching the team more closely now than ever. Revenue and cost savings expectations are high, driven by the hype around AI and the cost of the team. The expectations for productivity are tied to tangible returns not models built or problems solved. Businesses expect revenue.

What kinds of projects should the team say Yes to? Here are my criteria.

Business Critical and Significant Value

Business critical projects either support a strategic goal or a key product line. The team must focus on projects the business actually cares about. This is an important mindset for the team to adopt.

Too many teams get disconnected from the business, not because their projects return 0 value, but because their projects do not align with business goals. This is an easy trap to fall into. The Data Science team finds business problems as part of data exploration, internal stakeholder discussions, and customer interviews or frontline feedback.

There are a lot of distractions. The business has outlined core, strategic goals through the planning process. A well aligned team takes on projects which will impact those goals. A rogue team solves the problems they see as most important.

Essentially, they shortcut strategy and replace senior leadership’s direction with their own. It creates a silo around the team and their work. The question of, “Why is the team working on that?” comes up frequently and creates confusion for the rest of the business. It becomes a barrier to adoption and buy in.

I look at project discovery as a conversation between the Data Science team and other business units. They should be able to express their most pressing business problems and the team should be able to align project work to meet their needs. Everything should form a straight line back to core strategy.

The second part of business relevant projects is the Machine Learning solution must provide significant value. For a business making over $1B a year, a 3 month project leading to $1M in revenue or cost savings is not worth the time. This circles back to a core driver of project discipline, high expectations.

Data Science teams can look at a dollar amount and believe it is impactful. $1M sounds like a lot of money in personal terms. In relationship to the overall business, it can be inconsequential relative to other opportunities.

Again, projects need a connection to core strategy and business goals. If investors expect a 9% increase in annual revenue, a product that takes 25% of a resource’s time and returns .1% increase in revenue is not making the expected impact. These back of napkin calculations are important to do before starting the project.

I look to generate and/or save at least 5%-10% of the business's revenue per year (total) with new projects. I prioritize revenue generating projects over cost savings as a rule of thumb. I really want to be driving the majority of investor expectations with the projects I select. If the expectation is a 9% increase in revenue, I want the team building projects that produce at least 5% of that. If the expectation is improved margins of around 10%, I want the team delivering projects that produce at least 5% of that.

Making those types of impacts keeps the team relevant in the eyes of senior leadership.

Alternative Approaches Have Failed

You’ll hear this said a lot. Just because Machine Learning can solve a problem, do not mean it should solve the problem. Machine Learning is frequently the most expensive solution to build, implement, and support. All three costs need to factor into the decision to move forward.

Rather than perform the cost analysis on every project, it is easier to ask, is there a simpler way to solve this problem? I avoid projects where I can see a clear path to use a different approach like buying software, building with a traditional software engineering approach, or building with an advanced analytics approach.

If another approach is possible, it is likely more cost effective in both the short and long run. I often ask, “What else have we tried?” If no one else has tried to solve this problem, I start to wonder how serious of a problem is it? Obviously, if this is a new business need, different story.

I work with other teams to revue alternative solutions and approaches. Has the business explored the costs and feasibility completely? Have other teams been given the opportunity to put forward solutions? I want to build a consensus around the Data Science team being the right one to take on the project.

Team And Business Are Capable Of Executing

Some solutions that can be created cannot be created by the current team or cannot be supported by the business. Just because it is possible does not always mean it is practical. Projects need a feasibility assessment.

I start with the team. They need:

  • Individual capabilities to find and implement a reliable solution.
  • Infrastructure and resources to support building the solution.
  • Datasets or the ability to gather new data to support model development.
  • Realistic timelines for development and implementation.
  • Support from external groups.

  • I must set the team up for success so we don’t spend weeks or months just to abandon a project. We need to sign up for complex projects but equally important is to consistently deliver solutions.

    Next, I look at the supporting teams. Once the Data Science team builds a solution, where does it go next? I have to work with downstream teams to make sure they are ready, but more importantly, capable of doing their job. One of the worst possible project outcomes is to drop a solution on an unprepared team and have it die on a shelf.

    This is especially important when I develop a new feature for an existing product line. It must integrate and other teams will play a significant role in that process. Those teams need to be bought in on the project from the beginning or it does not really matter what the Data Science team builds.

    Their leaders need to have the project as one of their goals for the year. Their team is dealing with limited resources and likely getting pulled in multiple directions. This ties back to taking on projects that align with core strategy and produce significant results.

    Clear Path To Adoption

    I learned early on in my career; I cannot force anyone to use a product. It does not matter how cool or functional, users consciously decide what they will use and what gathers dust. Usability and perception of value are key components of project success.

    Customers, both internal and external, need to be ready to adopt a machine learning solution. Understanding what customers are ready to use is an important project assessment step. Revenue generated and costs saved are 0 if no one ever uses it or if they quickly abandon it.

    There is a level of support necessary in the user and customer base. Usability is an important and often overlooked part of project success. Especially for customer facing products, there is no way to force adoption. There is no shortcut around customer needs and expectations.

    The Data Science team needs these requirements to build a complete solution. Customer facing and user groups need to be part of the process. This process is often assumed to happen on its own, but it will not. Again, this comes back to business wide support and alignment with core strategy.

     

    Part of leading a Data Science team is identifying the right opportunities. I am not only setting the team up for success, but also the larger business. Machine Learning projects do not happen in a silo. They stretch beyond the boundaries of the team.

    We can learn a lot from the failures of previous technology adoption cycles. We cannot bully our way forward or build it just because we can. Strategy and value are the core drivers. Alignment isn’t just a buzzword.

    Most projects the Data Science team could be working on, are not feasible or not the best use of the team’s time. They fail to meet the high expectations of senior leadership. That means we need to say No a lot.