The 4 Phases of Data Science Consulting Projects
By: Ray Heberer
Tags: Consulting, Software Development, Personal Development, Data Science, Communication

The 4 Phases of Data Science Consulting Projects

A retrospective

Photo by Austin Distel on Unsplash

In some work categorization frameworks, jobs are placed into quadrants depending on whether they are routine or nonroutine, and cognitive or manual. Data science can be a rewarding and stimulating career path due to its nature as a nonroutine cognitive discipline. However, the way that demands and problems change throughout the course of projects can lead to some uncertainty.

As I approach the two year anniversary of my first non-internship position as a data scientist, I think it would be interesting to record and share my experience so far.

In particular, I’ve identified four typical “phases” of projects I’ve worked on, where the nature of problems I’m faced with feel qualitatively different from each other. For each, I describe the nature of tasks and identify the challenges unique to the phase. By doing so, I hope to shed some light on some periodic and predictable elements of an otherwise nonroutine job.

Of course, the experience you have will depend on your team and your clients. I’ll be very interested to hear about the ways in which your experience has been similar to or different than my own, as well as any strategies you might have for handling a particular type of problem. This article is also more personal and less technical than has been my norm, so I apologize if it doesn’t contain anything immediately applicable to your own situations.

Phase 1: Demoing

Near the beginning of a project, when scopes and statements of work are still being fleshed out, I’m often working on quick proof-of-concepts. These most often take the form of visualizations that can be shown in slide decks, or simple Shiny apps (we work with R a lot).

These early phases of projects can often be the most exciting. That feeling of moving fast, going with first assumptions, and coming up with something that feels like an 80% complete version of what will take the next few months to flesh out is rather exhilarating.

Because of this, I find the main challenge during the demoing phase to be tempering the excitement that comes with novelty. Overreaching with demos isn’t advisable in a consulting setting because it may set unhealthy expectations. Sometimes an idea first presented in a demo turns out to be founded on invalid assumptions when examined more closely.

Demoing and expectation management are tightly coupled, so it takes some soft skills and strategy to execute this phase well.

Phase 2: Implementing

Once the client has settled on a scope they are excited about, it’s time to implement it. The most common units of software that I find myself implementing are ETL scripts, lightweight R packages, and Shiny apps.

This is also the time to decide on the data storage and access architecture, and gather the raw data. My recent projects have stored structured data in PostGIS databases (basically SQL with some geospatial support), and structured data in AWS S3. Because there is a small amount of people accessing the data, we feel comfortable retrieving it directly, rather than making some sort of API for it.

On the problem solving side of things, I’ll be dealing with the typical data munging issues (handling missingness, reshaping data), and with some machine learning decisions (how to partition the data, what model to use).

During this phase, the assumptions made while implementing demos must be interrogated. Sometimes it can be a challenge to communicate to clients why the software development is surfacing fewer interactive toys and fancy visualizations, or why it seems slower in general. If we fail to fully convince them of what is necessary and responsible at this stage, then some crunch will be felt and technical debt will accumulate.

Getting better at implementing “production” ready software has been the main thing I’ve learned in the workplace that was hard to get experience with as a student or intern. I’ve found that even teams from large Fortune 500 companies have less of an understanding of software and data best practices than I would have expected. As a result, communicating the need for them is important for success.

Phase 3: Iterating

Many projects have a question they seek to answer, or a hypothesis to test (e.g. what factors lead to outperforming rents per square meter?). The demoing phase presents possible paths to the answer, while the implementing phase provides the actual, initial answers.

Usually the first pass won’t provide exactly what we’re looking for. However, if the implementation of the software and pipelines has been done in a flexible and extensible fashion, it is a simple matter to take a few more stabs at the problem.

This is the phase where I find myself doing tasks like feature selection and hyperparameter tuning.

Also, I find that communication with clients and stakeholders starts ramping up a little here. More people might start attending progress meetings. More applications and visualizations are produced — similar to in the demoing phase, but this time using more mature software and assumptions.

There is a danger during this phase of being sucked into an endless cycle of requests and refinements. Assuming the “definition of done” and project timeline was properly fleshed out during the first phase, eventually it’s time to put your foot down, declare the problem solved, and relegate the remaining follow-up questions to a new contract. Otherwise you’ll end up doing a lot of free work.

Phase 4: Supporting

Even as the current project is winding down, while other new ones are spinning up, my team will offer support in using the software we’ve built, fixing anything broken, or fulfilling other small requests.

If for some reason, a lot of technical debt built up during the project, this phase can be rather painful. I’ve definitely had a couple projects that were just hacks built on top of hacks, and whatever time they might have saved during some crunch period, they sucked up again with interest in all the bug hunting and fixing that went on for months afterwards.

If the first 3 phases were executed really well, then I sometimes face another, more psychological challenge. Sometimes the timing works out so that there’s a bit of downtime between projects.

A completely well-adjusted person with no imposter syndrome whatsoever might welcome the opportunity for a breather, but I can’t help but feel like I’m not doing enough during these times. I worry that people on my team will resent me for being lazy, among a bunch of other irrational fears.

But as I experience more cycles with more clients and projects, I’m learning how to cope with the fluctuations in business. The supporting phase is a good opportunity to brush up on old skills, learn some new ones, and reflect on the past few months. In fact, that’s exactly what I’m doing now.