Interview guides · Business Integration Partners (BIP)

Business Integration Partners (BIP) Data Scientist Interview Questions & Guide 2026

Practice explaining analysis before a Business Integration Partners (BIP) data scientist interview: the recommendation, the uncertainty, the follow-ups.

The 60-second brief

As a Data Scientist at Business Integration Partners (BIP), you operate at the intersection of advanced analytics and strategic consulting. Your primary mandate is to translate complex, often unstructured business problems into actionable, data-driven solutions that drive value for high-profile clients across various industries. Unlike product-focused roles, this position demands a high degree of versatility, as you will likely pivot between diverse projects, sectors, and technical environments.

How much statistics you need depends on the flavour of the seat. Experiment-facing work wants you deep enough to notice that repeated looks at accumulating data inflate the false positive rate of a fixed-sample test; modelling-facing work wants estimation and honest uncertainty intervals.

Focus areas

Reconstruct pipeline stage history from mutable rows
Compute utilisation against a defended availability denominator
Cluster inference at the account, not the engagement

Overview

This role is critical to Business Integration Partners (BIP) because you act as the bridge between raw information and executive decision-making. You will be expected to not only build robust models—ranging from predictive analytics to Generative AI applications—but also to communicate these findings effectively to stakeholders who may lack a technical background. Success in this role requires a balance of rigorous academic knowledge, practical coding proficiency, and the consulting mindset required to thrive in a high-turnover, fast-paced environment.

Because Business Integration Partners (BIP) functions as a consultancy, emphasize your ability to adapt quickly to new domains and your capacity to explain technical trade-offs in business-relevant terms during your interviews.

The Business Integration Partners (BIP) interview process

Business Integration Partners (BIP) candidates report 2 rounds · ≈ 2-4 weeks. The stages below are what candidates describe, not a published process.

Initial Screening Call

A screening call is a matching exercise run by someone who will not evaluate your statistics. They are checking that the work described on your resume is work you personally did, and that its scope matches the level the role is written for. Logistics get settled in the same half hour so nobody spends an interviewer's afternoon on a mismatch. The answer that fails is the one narrated in the plural. If every sentence is 'we built' and 'the team decided', there is nothing specific to write down about you. Name the piece that was yours, the decision you made inside it, and what changed after.

What to demonstrate

Whether the ownership implied by your resume survives one round of follow-up about who actually did which part
Whether your described scope (data size, stakeholders, what shipped) matches the seniority the role is written at
Whether timeline, location and compensation expectations make the rest of the loop worth scheduling

How to prepare

Rewrite your top three resume bullets in the first person singular, each with the decision you made and what moved afterwards, then say them out loud once so the 'we' does not return under pressure
Attach one number to each project: the baseline, the change, and the window it was measured over. Where impact was never measured, say that plainly rather than inventing a figure
Settle your compensation range before the call and give it as a range with a reason behind it, such as current total comp or a competing timeline, instead of deflecting the question twice

Technical Assessment

A handful of shapes account for most of what gets asked in this format: a ranking or deduplication inside groups, a running or rolling total, a period-over-period comparison, and a cohort tracked forward over time. Recognising the shape quickly is most of the speed here; deriving it from scratch while a clock runs is where the time goes. Know that a window function keeps every row while a GROUP BY collapses them, and know which one the question needs. If the exercise is in Python instead of SQL, the same shapes arrive as groupby with transform, shift and merge, and the same grain mistakes are available.

What to demonstrate

Whether you reach the right construct without a detour, such as ROW_NUMBER over a partition to deduplicate instead of a self-join against a MAX subquery
Whether you know what your window frame actually is, since adding ORDER BY inside OVER changes the default frame and silently changes a running total
Whether the thing runs. A near-miss that throws an error scores below a plainer query that returns the right rows.

How to prepare

Write each of the four shapes once from memory against a small schema and keep the working version somewhere you will reread it: dedupe with ROW_NUMBER, a running total, a month-over-month change with LAG, and a retention table
Compute one running total twice on data with tied timestamps, once on the default frame and once with ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW, and look at where the two disagree
If Python is on the table, rebuild the dedupe and the running total with groupby and cumsum, then assert the two implementations return identical rows

Where candidates lose points

Computing days-to-pay or proposal cycle time over completed records only

At any snapshot date, invoices that have already been paid are disproportionately the fast ones, and proposals that already have a decision are disproportionately the quick ones. Averaging over the completed set alone biases both numbers downward, and the bias grows exactly when the business is deteriorating, because the slow cases are the ones still open. Unpaid and undecided records are right-censored; use Kaplan-Meier or a restricted mean up to a fixed horizon, and never fill paid_at with a placeholder.

Treating accounts as independent observations

Revenue is concentrated: a small number of client_ids typically carries a large share of fees, and engagements within one account share a partner, a rate card and a delivery team. Ordinary standard errors computed over engagements therefore understate uncertainty badly. Cluster at client_id, and with fewer than roughly 40 clusters use a wild cluster bootstrap or a CR2 correction, because cluster-robust standard errors are downward-biased in that regime and will manufacture significance that a replication will not reproduce.

Analysing at a different unit than the one randomised

Say out loud what was randomised (user, device, account, cluster) and make the analysis unit match, or account for the clustering with cluster-robust standard errors, the delta method, or aggregation up to the randomised unit. Randomising users and then running a test over sessions understates variance and inflates the false-positive rate.

Building features from data that postdates the prediction time

Check every feature against the timestamp at which the model would actually score, and drop anything computed from a window that includes or follows the label event. For a forecasting use case, split train and test by time rather than at random, and split by entity when the same entity recurs.

Questions & practice

Can you explain how you would implement a basic recursive algorithm?

Medium · machine learning and modelling

Approach

Set a baseline first, so any model has something honest to beat.
Check what information would not exist at prediction time, and exclude it.
Say how the offline result would be validated online before it is trusted.

Follow-up

How would you choose the decision threshold, and who owns that choice?
What would you monitor after launch to know the model is still valid?

What are the primary metrics used to evaluate a classification model?

Medium · machine learning and modelling

Approach

Check what information would not exist at prediction time, and exclude it.
Pick an evaluation metric that matches the cost of each error type, not a default.
Say how the offline result would be validated online before it is trusted.

Follow-up

How would you choose the decision threshold, and who owns that choice?
What would you monitor after launch to know the model is still valid?

What are the core principles of optimization techniques used in training models?

Medium · machine learning and modelling

Approach

Pick an evaluation metric that matches the cost of each error type, not a default.
Frame the prediction: the label, the moment of prediction, and the action it triggers.
Check what information would not exist at prediction time, and exclude it.

Follow-up

What would you monitor after launch to know the model is still valid?
Where could label leakage enter this setup?

Measure the timesheet backfill curve and pick a reporting cutoff

Easy · late-arriving data · data quality · cohort curves

time_entries has work_date (date), entered_at (timezone-aware UTC timestamp), hours and status. Given a snapshot_date, restrict to work_date in [snapshot_date - 180 days, snapshot_date - 60 days] so every cohort is fully observed. For k = 0..45, compute F(k): the share of a work_date cohort's final hours that already existed as of work_date + k days, pooled across cohorts. Return the 46-point curve and the smallest k with F(k) >= 0.99. Some rows are entered before the work date; those lags are real, not errors.

Approach

Compute lag = (entered_at converted to the reporting timezone and taken as a date) - work_date in whole days, then clip negative lags to 0 instead of dropping them; leave and planned time are routinely entered ahead of the work date and dropping them deflates the early curve.
Take cohort totals as groupby(work_date).hours.sum() over the restricted window. These are final only because the window stops 60 days short of the snapshot, which is why the restriction is in the prompt.
Build the numerator by summing hours per (work_date, lag), sorting by lag, taking a per-cohort cumsum, then reindexing each cohort onto the full 0..45 lag grid and forward-filling, so a cohort with no entries at a given lag holds its previous level rather than disappearing.
Pool as sum(numerators) / sum(denominators) at each k, not as the mean of per-cohort shares. Holiday weeks are tiny cohorts and would otherwise carry the same weight as a full week.
Read k* off the pooled curve and report F(45) with it: if F(45) is below about 0.995 the tail runs past the grid and k* is a lower bound, not the answer.

Worked solution (25 min)

Restrict rows to the [snapshot - 180d, snapshot - 60d] window and compute lag_days = (entered_at.dt.tz_convert(tz).dt.normalize().dt.date - work_date).dt.days, then lag_days = lag_days.clip(lower=0).
cohort_total = df.groupby('work_date').hours.sum(); by_lag = df.groupby(['work_date','lag_days']).hours.sum().
Reindex by_lag onto MultiIndex.from_product([cohorts, range(0,46)]), fill 0, cumsum within work_date to get hours_by_k.
F = hours_by_k.groupby(level='lag_days').sum() / cohort_total[cohorts_in_grid].sum(); assert F is non-decreasing.
k_star = int(F[F >= 0.99].index.min()) if any, else report 'not reached within 45 days' along with F(45).

Expected result: A monotone non-decreasing 46-point series F(0)..F(45) bounded by 1.0, plus an integer k* (or an explicit 'not reached by day 45') reported together with the value of F(45).

Verify it yourself

F is non-decreasing in k and F(45) <= 1.0, with equality only if no row in the window has a lag above 45 days.
The pooled curve lies between the minimum and maximum per-cohort curve at every k, since it is a weighted average of them.
One cohort recomputed by hand from raw rows matches the vectorised result.
Removing the clip and dropping negative lags lowers F(0); the difference equals the hours entered ahead of their work date.

Follow-up

The dashboard refreshes daily. Would you hold the window back past k*, or publish an as-of-entered_at series instead, and what does each choice cost the reader?
One practice area has a tail twice as long as the rest. Does that change the firm-wide cutoff, or does it change what you publish per practice area?

Write a simple Python function to solve a specific data manipulation task.

Medium · sql and data manipulation

Approach

Check whether any join is one-to-many before aggregating, or the sums inflate.
Handle the rows that do not match: a LEFT JOIN with a NULL check is usually the question.
State the window function and its partition and ordering out loud before writing it.

Follow-up

How does the query change if the join becomes one-to-many?
What breaks if events arrive late or out of order?

What are the best practices for structuring a data science project?

Medium · sql and data manipulation

Approach

State the window function and its partition and ordering out loud before writing it.
Say which table is the grain you start from, and join outward from it.
Handle the rows that do not match: a LEFT JOIN with a NULL check is usually the question.

Follow-up

What breaks if events arrive late or out of order?
How does the query change if the join becomes one-to-many?

Dense consultant-week series with a trailing four-week average

Medium · window functions · calendar spine · running aggregates

fct_time_entry holds consultant_id, engagement_id, charge_code, work_date, hours, is_billable and status. dim_consultant holds consultant_id, is_billable_role, hire_date, termination_date and is_current. Produce one row per billable-role consultant per ISO week over the last 26 weeks with approved billable hours and the trailing four-week average including the current week. Weeks with no time entries must appear as 0, not disappear. No consultant may appear before hire_date or after termination_date. State where you put the right-hand edge of the window and why.

Approach

Build the week spine with generate_series over date_trunc('week', ...), which is Monday-aligned in Postgres, and CROSS JOIN it to the eligible consultant set, bounding each consultant by hire_date and termination_date. The spine is what converts an absent week into a zero week; no amount of COALESCE on a query driven by fct_time_entry can recover a row that was never there.
Aggregate time entries to (consultant_id, week_start) in a CTE first, then LEFT JOIN that onto the spine and COALESCE(hours, 0). Aggregating before the join keeps it one-to-one and removes any chance of fan-out.
Average with AVG(billable_hours) OVER (PARTITION BY consultant_id ORDER BY week_start ROWS BETWEEN 3 PRECEDING AND CURRENT ROW). Use ROWS rather than RANGE: on a dense spine they agree, but ROWS states the intent in row terms and does not change meaning if the spine ever develops a hole.
Decide what the first three weeks of each consultant's series mean. That window averages over fewer than four rows, so either label them as partial with a COUNT(*) OVER the same frame, or suppress them. Pick one and say so.
Hold the right edge of the window back past the measured timesheet backfill tail. Entries are created days to weeks after work_date, so the most recent weeks are systematically incomplete and the series will show a decline that reverses on the next refresh. Measure the tail rather than guessing a round number.

Worked solution (30 min)

Generate the 26 week_start values and confirm the count and the boundary dates before joining anything.
CROSS JOIN to billable-role consultants and apply the hire_date and termination_date bounds, then count rows per consultant.
Aggregate approved billable entries to consultant-week, LEFT JOIN onto the spine, COALESCE to 0.
Add the windowed average with an explicit ROWS frame, plus a COUNT over the same frame so partial windows are visible.
Hand-verify one consultant: print their 26 weeks and check that week 5's average equals the mean of weeks 2 through 5.

Expected result: 26 rows per eligible consultant, fewer only where hire_date or termination_date truncates the series. Zero-hour weeks are present with 0.00 hours. The trailing average on each row equals the arithmetic mean of that week and the three preceding weeks in the same consultant's series.

Verify it yourself

SUM(billable_hours) over the dense series equals SUM(hours) over approved billable entries in the same window, proving the LEFT JOIN added no rows and lost none.
Row count per consultant equals 26 minus any weeks outside their hire and termination bounds.
The hand-checked consultant's week-5 average matches the mean computed by hand from weeks 2 to 5.
No week_start in the output falls inside the held-back backfill tail.

Follow-up

Extend to a 13-week average. Does your choice between ROWS and RANGE change, and why?
Add the availability denominator so this becomes utilisation. What has to be subtracted from calendar hours, and what has to be prorated?
Reproduce this series as it would have looked 30 days ago. Which column do you filter on, and why do the two versions differ?

Proxy delivery quality when no satisfaction data is collected

Medium · proxy metrics · measurement bias · quality · composites

The firm records no survey or satisfaction data. A steering group still wants a quality metric on the monthly scorecard. From fct_time_entry (written_off_hours, hours, is_billable), fct_invoice_line (line_type, status, amount_usd), fct_engagement (status, close_reason, prior_engagement_id) and dim_client (client_id, account_tier, parent_client_id), construct a composite quality proxy. For each component, state the direction of its bias and where the bias comes from, and name at least one account segment on which the proxy is systematically wrong. Then say what you would instrument to replace it.

Approach

Write the target construct down first: whether the client received what they paid for. Then show that every available column records a decision made by someone inside the firm or by the client's finance function, not an observation of the work.
Assemble four components at engagement grain: write-off rate (written_off_hours / billable hours), disputed and credit-noted share of invoiced value, early-close rate on close_reason IN ('scope_dispute','quality'), and twelve-month repeat purchase on the account rolled up through parent_client_id.
State each bias precisely. Write-offs record a partner's willingness to concede, so a strategic-tier account with a partner protecting the relationship shows high write-offs on good work while a transactional account shows low write-offs on bad work: across account_tier the proxy runs against the construct. Disputes require a client AP function that disputes at all, which scales with client size. close_reason is entered by the person closing the engagement and is the field most likely to be recorded defensively. Repeat purchase is confounded by switching cost and by whether the client has budget at all.
Refuse to blend them into one index without weights that a named person owns, and report the four as a strip stratified by account_tier so a shift in concession policy cannot read as a shift in delivery.
Specify the replacement: a post-close instrument tied to engagement_id, collected by someone outside the delivery team, with a response-rate floor agreed before launch, plus a constrained close_reason enum enforced at write time instead of after the fact.

Worked solution (25 min)

Compute the four components at engagement grain for the trailing four quarters.
Cross-tabulate write-off rate by account_tier and by pricing_model, and confirm the tier gradient exists before making any claim about quality.
Check whether write-off rate and twelve-month repeat purchase agree in sign at the account level; if they disagree, the composite has no single direction and must not be blended.
Write the one-paragraph caveat that has to travel with the number, naming the specific segment where it inverts.

Expected result: Four separately reported components, each with a stated direction and named bias source, stratified by account_tier, plus an explicit statement that write-off rate inverts on strategic-tier accounts where concessions are relationship decisions rather than quality signals. No blended index without an owner for the weights, and a named instrumentation plan that would replace the proxy.

Verify it yourself

Write-off rate differs materially across account_tier. If it does not, either the tier field is stale or concessions are centrally policed, and both are worth reporting.
The four components do not all point the same way on every account. If they do, check whether one large engagement is driving all four.
The caveat names a specific segment and direction, not a generic statement that the number is directional.

Follow-up

Firm-wide write-off rate falls 30% in one quarter. Give one benign and one alarming explanation, and the query that separates them.
The steering group insists on a single number. What do you hand them, and what do you decline to do?

Cut variance with pre-period margin before buying more accounts

Medium · cuped · variance reduction · stratification · ancova

You are designing an account-randomised pilot of a delivery-review process, measured on engagement gross margin over one quarter. The design is underpowered at the account count available. Each account has two prior quarters of margin history reconstructible from fct_invoice_line and fct_time_entry, correlated 0.6 with the pilot-quarter outcome. Specify a variance-reduction plan: the estimator, the coefficient it uses, how you handle accounts whose first engagement starts inside the pilot window, and the sample-size equivalent of the reduction you expect. State the precondition that makes the adjustment safe.

Approach

Define the adjusted outcome Y* = Y - theta * (X - Xbar) with X the pre-period margin and theta = Cov(Y, X) / Var(X). The precondition is that X is measured strictly before assignment, so its arm means agree in expectation and subtracting it removes the account-level variance component without touching the treatment contrast.
State the payoff exactly: Var(Y*) = Var(Y) * (1 - rho^2). At rho = 0.6 that is a 36% variance reduction, a 20% standard-error reduction since sqrt(0.64) = 0.8, and a sample-size equivalent of 1 / (1 - rho^2) = 1.56 times the accounts. Real, but it will not rescue a design that is five times short.
Implement it as the ANCOVA regression of Y on treatment and X, which is numerically the same estimator when theta is the OLS coefficient and which hands you cluster-robust inference for free. Estimate theta on pooled data, never separately per arm, which reintroduces bias.
Keep accounts with no history rather than dropping them: impute X at the sample mean and add a no-history indicator. Because X is pre-treatment, imputation cannot bias the treatment coefficient, while dropping those accounts silently changes the estimand to accounts with history.
Balance at assignment as well as adjusting after it. Block on account_tier and pre-period margin tercile, randomise within block, and carry block fixed effects into the model. At roughly 120 accounts, blocking guarantees balance where post-hoc adjustment only achieves it on average.

Follow-up

Why is pre-period outcome usually a better covariate than account_tier alone, and when does that ranking flip?
A colleague wants to add hours worked during the pilot quarter as a second covariate. What happens to the estimate?
Your pre-period window is two quarters. What sets the optimal length, and what degrades if you extend it to eight?

Realisation rate steps up overnight after a warehouse release

Medium · definition change · realisation · restatement

Realisation rate for one practice area steps from 0.93 to 1.02 on a single reporting date. Bill rates, hours worked and the client set are unchanged. The metric is SUM(amount_usd) from fct_invoice_line over SUM(hours * bill_rate_usd) from approved billable fct_time_entry rows for the same engagement and period. A warehouse release shipped that week. Determine what in the definition can produce a level shift with no operational change, and deliver a back-restated series plus the definition you would keep.

Approach

Treat the shape as evidence: a definition change is a discontinuity at one processing boundary, while a behaviour change ramps over weeks. Plot daily, not monthly, to see which one this is before forming any hypothesis.
Diff the metric's lineage across the release and enumerate the candidate predicates: which line_type values enter the numerator (dropping credit_note and write_off inflates it), whether the period join moved from period_start_date to issued_at, and whether the denominator counts status = 'approved' only or now includes 'submitted'.
Run both definitions over the same fixed pre-release month. If old and new differ by approximately the size of the step, the step is definitional; if they agree, look for a behaviour change coinciding with the release date.
Sanity-check the new level against the metric's physics: values above 1.0 are legitimate only on fixed_fee work delivered under its hour budget, so a practice dominated by time_and_materials sitting at 1.02 is itself a red flag.
Restate the full history under the chosen definition, publish old and new series together with the changeover marked, and add a reconciliation test that recomputes one known engagement-month from raw rows.

Follow-up

Which definition is correct, and what does excluding write-offs from the numerator do to the guardrail relationship with utilisation?
How do you prevent the next release from silently restating a headline metric?
If the release also changed the denominator's status filter, which direction does that push realisation and by roughly how much?

Suggested practice checklist

Four days spend equal time on query work, statistics, modelling and product judgement at deliberately shallow depth, which produces a scored map of where you actually stand. The last three days spend everything on the two areas the role weights most, and close by re-running day one to measure movement.

Day 1 — Breadth pass: query fluency

Solve six prompts spanning aggregation, joins, window functions and date arithmetic in 60 minutes total, stopping at 10 minutes each whether or not it works, and mark every prompt as solved, solved slowly, or stuck.
For each unsolved prompt write the single blocking sentence (I lost the grain, I did not know the frame clause, I could not express the date boundary) instead of reading the solution.
Translate one pandas transformation you know well into SQL and one SQL query into pandas, checking that both return the same row count and the same totals.

Deliverable: A scored six-row table, one line per prompt, saved for the day-seven re-run.

Day 2 — Breadth pass: statistics and inference

Answer ten short questions in writing with nothing open: what a p-value is conditional on, what a 95 percent interval covers across repeated samples, when a paired test is the right one, what the bootstrap estimates, why multiple comparisons inflate false positives, how controlling the family-wise error rate differs from controlling the false discovery rate, what power depends on, what a missed real effect costs a product, the three situations where the central limit theorem does not rescue you (small n, very heavy tails, dependent observations), and what a standard error is the standard deviation of.
Grade yourself against a reference and count only the answers that were exactly right, not the ones that were nearly right.
Rewrite the two weakest answers the following morning from memory in full sentences.

Deliverable: Ten graded answers with an honest count of exact hits.

Day 3 — Breadth pass: modelling

Take one tabular dataset end to end in 90 minutes: a leakage-safe split, a baseline that is not a model (majority class or historical mean), one regularized linear model, one gradient-boosted tree, and a single evaluation metric chosen before you look at any result.
Write why that metric fits the cost structure: precision at a fixed recall for alerting, calibration for anything feeding a price or a threshold, ranking metrics for retrieval, and note that area under the ROC curve is insensitive to class balance in a way that can flatter a rare-positive problem.
Name the leak you were most likely to introduce (an encoding fit on all rows before splitting, or a feature computed after the label's timestamp) and write the check that would have caught it.

Deliverable: A notebook whose first cell states the metric and the baseline, plus two lines on what beat what and by how much.

Day 4 — Breadth pass: product judgement

Answer three case prompts aloud at 15 minutes each, timing how long passes before you state a success metric.
For one case write the first segmentation you would run and the row counts you expect per segment, so that a tiny segment cannot quietly drive the conclusion.
Take a metric definition you did not write, from a public dashboard, a textbook, or documentation you already have open, and list every place two analysts implementing it would diverge: which rows the denominator admits, whether the unit is an account or a person, what the time window is anchored to, and what happens to data that arrives late. Then write the one question that would close the largest of those gaps.

Deliverable: Three recorded case answers plus an ambiguity list for a metric someone else defined, ending in the single question you would ask about it.

Day 5 — Depth, first area

Rank the four areas by how many bullet points in the role description each one covers, pick the top one, and spend the entire day inside it.
Work the six hardest problems you can find in that area and for each write the generalizable move you should have reached for first, rather than the answer.
Re-solve the two you failed the same evening with notes closed.

Deliverable: Six generalizable moves written as instructions to yourself, not as solutions.

Day 6 — Depth, second area, and the seam between them

Repeat the depth protocol on the second-ranked area with the same six-problem structure.
Construct one problem that requires both areas at once, for example a metric redefinition whose effect you must validate with a test whose readout you then have to query.
Solve your own combined problem end to end and note where the handoff between the two areas cost you time.

Deliverable: One combined problem, solved end to end, with the handoff failure written down.

Day 7 — Integration and re-measurement

Re-run the six prompts from day one under the same clock and compare both correctness and time.
Run a 60-minute mixed mock that moves between areas without warning, since switching cost is what breadth passes do not train.
Write the two areas you would still fail on, and the sentence you will use in the interview when you hit one of them.

Deliverable: A before-and-after score table plus a written plan for the two remaining gaps.

Stories where someone disagreed with you

Have two ready. In one, the data was on your side and you had to move someone who outranked you. In the other, the pushback was correct and you changed position. The second is the harder story and it lands better, because it shows you separate being right from being attached to an answer. Name the person's actual objection.

How do you handle imbalanced datasets in a production environment?

Medium · behavioural and stakeholder questions

Approach

Quantify the outcome, including what you would not claim credit for.
Close with what you would do differently, concretely.
Name the disagreement or constraint, and how you resolved it with evidence.

Follow-up

What did you decide not to do, and why?
What would you do differently if you ran that project again?

How do you handle situations where you are unsure of the data quality?

Medium · behavioural and stakeholder questions

Approach

Name the disagreement or constraint, and how you resolved it with evidence.
State the situation in two sentences and spend the rest on your reasoning.
Quantify the outcome, including what you would not claim credit for.

Follow-up

How did you know the outcome was caused by your change?
What did you decide not to do, and why?

Scoping a one-line question about practice profitability in twenty minutes

Medium · scoping · metric definition · exclusions

A practice leader asks, in one line, whether the data_and_ai engagements are profitable. You have fct_engagement, fct_time_entry and fct_invoice_line, and twenty minutes before they travel. Some engagements are retainer or outcome_based, so contracted_hours is NULL; some invoices are unpaid; pursuit hours sit on charge_code = 'client_pursuit' with engagement_id NULL. Produce the scoping conversation: the questions you ask, the metric you commit to in writing, the exclusions you will have to make, and what you deliver by when.

Approach

Name the probe: whether you convert an ambiguous one-liner into a decision with a metric attached, or start querying and return a number nobody can act on.
Ask what changes based on the answer. Repricing the rate card, changing the staffing pyramid, and deciding whether to keep selling fixed_fee are three different questions, and they need different cuts of the same data. Pick the one the leader actually has authority over.
Commit the metric in writing on the spot: fees plus milestone plus credit_note lines from fct_invoice_line as the revenue side, the sum of hours times cost_rate_usd over all approved entries, billable and non-billable alike, as the cost side, inception to date, reported separately by pricing_model.
List what you will not answer and why: overrun on retainer and outcome_based work, because contracted_hours is NULL there and needs an explicit predicate rather than a silent NULL drop; cash collected, because unpaid invoices are censored; and pursuit cost, which has no engagement_id and must either be allocated on a stated rule or reported as a separate line.
Commit two deliverables with dates rather than one vague one: the stratified margin table within two days, the mix decomposition within a week. Name the single assumption that, if wrong, flips the conclusion.

Follow-up

They insist on one number for a partner meeting. Which single number do you give, and what sentence goes with it?
If you had to allocate client_pursuit hours to engagements, what rule would you use and how would you show the answer is not sensitive to it?