Business problem

A raw incident log gave no view of where risk actually concentrated, so mitigation effort had no ranking to work from.

Solution

Wrote MySQL queries to aggregate incidents by cause, state and operator, joining reference tables and filtering for the incidents responsible for material product loss.

Insights

• A handful of cause categories accounted for most of the total product lost.
• Incident counts and incident severity ranked states in very different orders.
• Repeat incidents clustered around a limited set of operators and corridors.

Recommendations

• Prioritise inspection budget by product lost rather than raw incident count.
• Target the top recurring cause categories with dedicated preventive maintenance.
• Track repeat-incident corridors on a standing risk register.

Business problem

The raw dataset carried duplicates, inconsistent company and industry naming, and blank values, making any aggregate figure unreliable.

Solution

Built a staged cleaning pipeline with CTEs and window functions to remove duplicates and standardise fields, then ran rolling-total and ranking queries across industry, country and funding stage.

Insights

• Layoff volume concentrated in a narrow set of industries rather than spreading evenly.
• Rolling monthly totals revealed distinct waves instead of a steady trend.
• Late-stage and post-IPO companies contributed the largest single cuts.

Recommendations

• Segment workforce risk reporting by industry and funding stage, not headcount alone.
• Use rolling totals rather than monthly snapshots when reporting trend.
• Enforce standardised company and industry naming at data entry.

Business problem

Transaction records were inconsistent and uncategorised, so there was no reliable picture of where customer balances actually moved.

Solution

Standardised the records, classified transactions by type and channel with SQL, and profiled inflow and outflow patterns per customer segment.

Insights

• A small share of customers accounted for a large share of transaction volume.
• Outflow spikes followed a predictable calendar pattern tied to salary cycles.
• A cluster of transactions deviated clearly from each customer's normal range.

Recommendations

• Set monitoring thresholds per customer segment rather than one global rule.
• Plan liquidity around the observed salary-cycle outflow peaks.
• Review the flagged anomalous cluster before it enters reporting aggregates.

Business problem

The incident log held years of safety and cost data, but no one could answer basic operational questions from it — which year cost the most, which operators caused the most harm, or which product types were most dangerous.

Solution

Wrote MySQL queries using aggregations, grouped rankings, conditional filtering and joins to operator reference data, including handling columns with spaces and special characters via backticks.

Insights

• Total accident cost concentrated heavily in a single peak year rather than spreading evenly.
• One liquid type accounted for a disproportionate share of explosions.
• A small group of operators was responsible for most reported injuries.

Recommendations

• Prioritise inspection and audit resources against the top operators by injuries caused.
• Apply stricter handling controls to the liquid type with the highest explosion rate.
• Track property damage per operator as a standing safety KPI.

Business problem

Country economic classifications sat in a raw table with overlapping UN and IMF labels, making it hard to segment countries consistently for comparison.

Solution

Wrote MySQL queries using WHERE with AND/OR/NOT, IN, BETWEEN and LIKE wildcards, plus ordering and limits, to slice the dataset by classification, wealth rank band and fuel-exporting status.

Insights

• UN and IMF classifications disagree for a meaningful subset of countries.
• Fuel-exporting status clusters within specific wealth rank bands rather than spreading across them.
• Unclassified countries form a distinct group that skews aggregate comparisons if left in.

Recommendations

• Choose a single classification standard before running cross-country comparisons.
• Exclude or flag unclassified countries in aggregate reporting.
• Segment fuel exporters separately when analysing wealth rank movement.

Business problem

Promotions went out to the whole customer base with no evidence about who actually needed a discount to buy.

Solution

Built pivot-table models and a dashboard sheet segmenting customers by frequency, category preference and discount response across seasons.

Insights

• One segment bought at the same rate with or without a discount.
• Discount-sensitive customers concentrated in a small number of categories.
• Seasonality shifted category preference more than it shifted total spend.

Recommendations

• Stop discounting to the segment that buys regardless — protect the margin.
• Focus promotions on the discount-responsive category and customer overlap.
• Rotate merchandising by season rather than adjusting overall promotion depth.

Business problem

Enrolment data was split across three tables, so questions about course demand and student profile could not be answered from any single table.

Solution

Joined the three related tables with INNER, LEFT and RIGHT joins, then aggregated registrations per course and computed average student age with grouped queries.

Insights

• Registrations concentrated in a small number of courses rather than distributing evenly.
• Left joins exposed students with no enrolment record at all — invisible in inner-join reporting.
• Average student age varied noticeably between course types.

Recommendations

• Plan capacity around the courses carrying most registrations.
• Follow up with the enrolled-nowhere student cohort surfaced by the outer joins.
• Segment course marketing by the age profile each course actually attracts.

Business problem

Squad and wage data sat in a single wide table with no view of how spend and age distributed across positions, teams and nationalities.

Solution

Wrote MySQL queries combining wildcard and range filtering with COUNT, SUM, AVG and ROUND aggregations, grouped by position, team and nationality and ordered with HAVING and LIMIT.

Insights

• Wage spend concentrated in a small set of nationalities and positions.
• Average squad age varied sharply by position, not by team.
• Contract expiry years clustered, creating a renewal bottleneck.

Recommendations

• Review wage spend per position against contribution before renewals.
• Stagger contract expiries to avoid a single-year renewal cliff.
• Recruit against the positions with the oldest average age first.

Business problem

Sales performance lived in monthly spreadsheets, so basic questions about which categories and regions were carrying revenue took hours to answer.

Solution

Cleaned and modelled the sales data, defined DAX measures for revenue, average order value and growth, and built a filterable dashboard by category, region, season and customer segment.

Insights

• A small group of categories generated the majority of revenue while occupying a disproportionately small share of inventory attention.
• Regional performance diverged sharply in peak season rather than across the year as a whole.
• Average order value, not order volume, explained most of the month-on-month revenue movement.

Recommendations

• Re-weight stock and promotion budget toward the categories driving revenue concentration.
• Plan regional campaigns around the peak window instead of spreading spend evenly.
• Track average order value as the primary sales KPI alongside total revenue.

Business problem

The raw dataset was seriously dirty: employee statuses written six different ways, 36 spelling variations of department names, negative salaries and performance ratings of 0 and 7 on a 1–5 scale. No reliable HR reporting was possible until it was fixed.

Solution

Cleaned the data in Excel (Find & Replace with match-entire-cell, IF/ABS/IFERROR/SUBSTITUTE helper columns, lookup tables for department standardisation, duplicate removal), then modelled it in Power BI with DAX measures (UPPER, AVERAGEX with FILTER) and built an interactive dashboard covering attrition, salary bands, tenure and performance.

Insights

• Operations has 19% attrition and the lowest average salary in the bank (₦959,840) — nearly double the IT department's exit rate.
• HR itself has the third-highest attrition at 16.8%, despite owning engagement across the bank.
• 164 employees are paid outside their approved salary band, with Mid-Level carrying the most violations (66).
• Every department scores between 2.95 and 3.06 out of 5 — the rating system isn't discriminating between performers.
• IT has the lowest attrition (11.2%) with above-average tenure and salary, and nobody is studying why.

Recommendations

• Review Operations compensation before spending further on recruitment there.
• Audit and correct the 164 out-of-band salaries — a fairness and compliance risk in a regulated institution.
• Rebuild the performance rating process so scores actually differentiate.
• Study what IT does differently on retention and apply it to the higher-attrition departments.

Business problem

Admissions data was captured but never analysed, so staffing and bed planning ran on intuition rather than on observed demand.

Solution

Cleaned and standardised the admission records in Excel, then built a Power BI report with time-series admission volume, department load and length-of-stay breakdowns.

Insights

• Admissions clustered into predictable weekly peak windows rather than arriving evenly.
• A minority of departments absorbed a disproportionate share of total admissions.
• Length of stay varied far more by department than by patient demographic.

Recommendations

• Shift staffing rosters toward the identified peak admission windows.
• Review capacity in the highest-load departments before adding beds elsewhere.
• Monitor length of stay per department as an operational efficiency metric.

Business problem

MySQL Shell configuration guidance was scattered across reference docs, leaving DBAs without a practical, tested path from default install to tuned instance.

Solution

Researched, tested and wrote a sequenced six-part series with reproducible commands, benchmarks and recovery procedures, reviewed for technical accuracy before publication.

Insights

• Most default configurations left memory and CPU settings badly matched to the host.
• Disk I/O configuration produced larger gains than query rewriting in several tested scenarios.
• Backup and recovery steps were the most frequently skipped part of tuning guides.

Recommendations

• Follow the series as a sequenced playbook rather than as isolated tips.
• Benchmark before and after each configuration change.
• Validate recovery procedures on the same schedule as tuning work.