Information Technology and Digital Consulting Case Studies
Professional5 Case StudiesUpdated Sep 2026
The cases below come from engagements where technology work meets a deadline, a budget, and people who did not ask for the change. None of them is a clean example. Each one has partial evidence, a sponsor who wants an answer before the data is ready, and an operational setting that limits what can be tried. The situations are described as they arrived, and the analysis explains which facts carried weight and which were noise. Pay attention to who bears the cost of each choice, because that is usually where the disagreement starts.
Case Study 1
Checkout failures after a Friday release
Tallow Creek Payments, a mid-sized processor of card transactions for small merchants, with about 180 staff and two data centers.
The situation
Tallow Creek shipped a change to its payment routing service late in the week. Within the first hour, approval times for card transactions rose from under one second to four or five seconds, and roughly one request in twenty began timing out. Merchants noticed before the monitoring dashboards did. The on-call engineer rolled the routing service back, but timeouts continued, which suggested a second cause. A large retailer had started a seasonal promotion that afternoon, and traffic to the fraud scoring service climbed past its usual peak. The connection pool to that service had been sized for the old volume. By the end of the shift, the support queue held more than 600 open tickets.
The challenge
The business needed checkout working again before the retailer's promotion peaked, and it needed to know whether the rollback had fixed the problem or only hidden it. The team had logs from three services, a partial trace sample, and a vendor status page with no useful detail. Rolling back once more would cost another deployment window, and the fraud service could not be restarted without a brief drop in scoring, which the risk group would have to approve. Support wanted a message to merchants soon.
Analysis
The first question was what the business was protecting. Approval latency mattered more than the error count, because a merchant whose customer waits five seconds at the register loses the sale. The rollback removed the release from the picture, yet timeouts stayed, which weakened the idea that the code change was the trigger. The connection pool metrics were the most useful source, and the trace sample confirmed that requests spent most of their time waiting for a free connection. Teams grounded in Information Technology and Digital Consulting usually separate the symptom from the trigger early, and here the two had been merged in the first status update.
The constraints shaped the order of work more than the diagnosis did. Restarting the fraud service would drop scoring briefly, and the risk group had to approve any step that could let transactions pass unscored. The team raised the pool size and added a queue limit at the gateway, both of which could be changed without touching scoring. Merchants were most affected, and they wanted to know whether their own transactions had been charged twice. That question went unanswered for two hours, which hurt trust more than the slowdown did.
Actions taken
- Restored approval latency by raising the fraud gateway's pool limit and adding a bounded queue so requests fail fast. Confirmed the fix with a replay of the previous afternoon's traffic.
- Published a merchant notice that stated what was affected, what was not, and when the next update would arrive. Did not promise a root cause until the trace evidence supported one.
- Added a duplicate-charge check that compared authorization and capture records for the affected window, then gave support a short script to answer merchant questions with specific transaction counts.
- Required load tests with a promotional traffic profile for every release touching the scoring path, and added an alert when fraud gateway pool saturation passed seventy percent.
Results
Approval latency returned to normal within the same shift, and timeouts fell below the level that had triggered the first merchant calls. The duplicate-charge check found no double captures, which allowed support to answer with confidence. The post-incident review was more difficult. The release team and the promotions team each argued that the other had not warned them, and the review took longer than the fix. The load test requirement went into the release checklist, and the next promotion passed through the gateway without a visible slowdown.
Questions for discussion
- Which evidence would have changed the decision to roll back first, and what would it have taken to collect it earlier?
- How should the team weigh a merchant's trust in the status page against the risk of publishing an unconfirmed cause?
- Who should own the capacity assumptions for a partner's seasonal promotion when the partner never tells the platform team about it?
Case Study 2
Conflicting occupancy reports before the board meeting
Fenwick Row Housing Cooperative, a nonprofit that manages about 2,300 rental units across three counties and reports to its board each quarter.
The situation
Fenwick Row's finance and operations teams each produced an occupancy figure for the same month, and the two differed by about four points. The board packet was due at the end of the week. Operations drew from the property management system, where unit status was updated by leasing staff when a lease was signed. Finance drew from the accounting ledger, which recorded rent receipts. Units that were leased but not yet paying were counted by one team and not the other. A third figure, from a regional dashboard, matched neither. Two properties moved to a new system last quarter, and some unit identifiers were reassigned, so the joins between sources quietly dropped records.
The challenge
The board chair wanted a single number she could defend, and the finance director did not want a corrected figure presented without an explanation of the gap. The data team had about four working days, one analyst with partial access to the migration logs, and no written definition of occupancy that both departments had signed. Property managers were already receiving calls from residents who had been told different things about their lease status.
Analysis
The board needed a figure it could defend, and the lenders needed consistency over time. The migration logs were the most informative source, listing which identifiers had changed and when. Lease records looked more reliable than they were, since signed dates often reflected paperwork arrival rather than effective dates. The team wrote a definition that separated leased, occupied, and paying units, then traced each count back to source rows. Settling definitions before arguing about numbers is the cheapest reliability step available.
The four days shaped what could be verified. A full unit-by-unit reconciliation was not realistic, so the team sampled forty units per migrated property and checked them against lease files. The sample found the dropped records in a pattern that could be corrected with a mapping table. Residents mattered here in a way that did not show up in the spreadsheet. Several residents had received conflicting notices, so the property managers asked for one approved sentence to give on the phone. The board packet went out with the corrected figure, a footnote on the gap, and a named owner for the mapping table.
- Trace lineage Map each reported metric back to its source tables and transformation steps.
- Validate transforms Test joins and mappings against a hand-checked sample before results reach stakeholders.
- Monitor row counts Alert when record counts, null rates, or unmatched identifiers move beyond agreed thresholds.
- Review definitions Revisit shared definitions each cycle with finance, operations, and report users.
Actions taken
- Wrote a one-page occupancy definition signed by both finance and operations, with each status mapped to a specific source field and an effective date rule.
- Rebuilt the unit mapping table for the two migrated properties, then reran the sample of forty units and recorded every mismatch with its cause.
- Added reconciliation checks that compare counts at each handoff between the property system and the ledger, failing loudly when unmatched identifiers exceed two percent.
- Gave property managers one approved sentence explaining the discrepancy, and assigned a named owner to the mapping table with a review date each quarter.
Results
The corrected occupancy figure differed from the operations number by about two points and from the finance number by less than one. The board accepted it with the footnote, and the chair asked for the definition to be attached to every future packet. The mapping table had nineteen records that had been silently dropped, and each was traced and fixed. Two months later the unmatched identifier alert fired once, on a small batch from a late data load, and the owner corrected it within a day. Property managers reported fewer calls about lease status, though the team did not measure this formally.
Questions for discussion
- Which of the three figures would you have presented to the board first, and what would you have needed to know to choose?
- When a definition is agreed, how should the team handle a stakeholder who keeps reporting a figure built on the old one?
- What would a sampling plan need to look like if the migration had affected every property rather than two?
Case Study 3
Unusual logins on a finance administrator account
Lantern Mill Credit Union, a member-owned lender with four branches and about 210 employees, running its own online banking platform.
The situation
A monitoring rule flagged the account of a finance administrator at Lantern Mill after eleven failed sign-in attempts, followed by a successful sign-in from a region where she had never worked. The session then exported a list of member payment schedules. The security analyst on shift had three open alerts from the same week and needed to decide quickly whether this was a compromised credential, a misconfigured vendor integration, or an employee traveling. The administrator reported that she had not traveled and had received a password reset message she did not request. Export activity was the sensitive signal, because the file held names, account numbers, and scheduled debit amounts for several thousand members.
The challenge
The response had to contain the risk without tipping off whoever was inside, preserve evidence that investigators and the regulator might need, and avoid locking out a finance team that was processing payroll that week. The analyst could see authentication logs and endpoint telemetry for the administrator's laptop, but not the mail server. Nobody on shift had written authority to disable accounts across the credit union.
Analysis
The business objective was narrow and clear: protect member data and keep payroll running. The evidence pointed in two directions. The failed attempts and foreign sign-in fit credential theft, but the reset request might have come from a help desk ticket someone else opened. The export itself was the most urgent fact, because it showed the session had reached data of value. The team treated the session as hostile until endpoint evidence said otherwise, and logged each fact with its source and time. A plausible innocent explanation stays a hypothesis until a log confirms it.
The constraints set the order of containment. Disabling the account outright would have cut payroll processing for the afternoon, and the finance director had no backup approver. The analyst revoked sessions and tokens, required managed-device sign-in, and blocked the export path. Member impact was the hardest part to judge. If the file had left the network, notification duties would follow, so the team imaged the laptop and mail store before cleanup and kept custody records with compliance.
Actions taken
- Revoked active sessions and tokens for the administrator, required sign-in from a managed device, and blocked the export path, keeping the account usable under watch.
- Imaged the laptop and the mail store before any cleanup, recording hashes, times, and the analyst's actions in a log that compliance could later review.
- Pulled authentication history for the past several weeks and compared the foreign sign-in against the administrator's travel records and VPN logs before drawing any conclusion.
- Worked with the finance director on a short approval path for payroll, so the account could be reset safely without halting the processing run that week.
Results
The export was traced to the administrator's session, and the reset request was confirmed as an attacker action, since the help desk had no ticket for it. The file had left the network through a personal sync client, which led to a notification review with compliance. The administrator's password was replaced, and a mailbox rule that forwarded her vendor emails was removed, so the attacker's access ended within the same shift. Member notification was limited to accounts in the export after the team matched account numbers to the file. The incident review added a rule that flags scheduled-payment exports and requires a second approver.
Questions for discussion
- What evidence would have been enough to lift the containment steps early, and who should have the authority to make that call?
- How should a team weigh the payroll impact of a lockout against the chance that stolen credentials are still in use?
- When the export has already left the network, which parts of the notification decision depend on facts the team does not yet have?
Case Study 4
Choosing a read architecture for peak booking traffic
Pelham Street Scheduling, a software company that builds appointment booking for dental and physiotherapy practices, with about 90 staff.
The situation
Pelham Street's booking product had grown from a few hundred practices to several thousand in active use. Peak appointment searches on Monday mornings were pushing page loads past four seconds, and the main relational database was carrying both transactional writes and heavy availability queries. Two options had been proposed. One was to add read replicas and a caching layer in front of availability searches. The other was to move availability to a separate search-oriented store updated by events. The replicas were cheaper to run but would need careful consistency handling, while the event store added moving parts that the four-person platform team had not operated before.
The challenge
The team had to pick an approach before the next onboarding wave of practices, and the choice had to satisfy three constraints. Booking must never double-book a slot, patient data had to stay under the same access controls as before, and the on-call rota could not grow. Leadership wanted the cost curve flattened, while clinic managers wanted search results to feel instant.
Analysis
The business objective was reliability at peak, not raw throughput, since a slow search at nine in the morning costs a booking. That reframed what counted as evidence. Load tests on a staging copy showed that most of the slow requests came from availability searches that scanned large date ranges, not from writes. Replica lag figures were less useful, since they depended on a batch schedule that had changed twice. Teams often benchmark only the painful workload, because general benchmarks flatter whichever design the team already favors.
Each option carried a different risk profile. Replicas kept patient data inside the existing access boundary, but stale reads could show a taken slot as open. The event store needed its own access controls, audit trail, and rebuild procedure, which the four-person team could not staff without pausing feature work. Clinic managers would feel a wrong answer first, so the booking engine, not the interface, had to own the final check. A short hold state on the cache was the proposed compromise.
Actions taken
- Built a benchmark from the slowest real availability queries, using a copy of production bookings with dates shifted to the current quarter, and ran each option against it.
- Wrote a booking-hold rule so that a cached slot could be shown as tentative until the booking engine confirmed it against the primary store.
- Set a service boundary around availability so the access model, audit logging, and encryption settings for patient data stayed identical to the existing core.
- Agreed an on-call change: the new cache layer would have its own alert on hold expiry and stale-read rate, and nobody joined the rota until the runbook had been tested.
Results
The hybrid approach brought search latency under a second at the busiest hour in testing, and the same held in production during the following onboarding wave. Spending stayed within the agreed budget, and the event store was deferred to a later review. A stale-hold incident did occur in the second week, when a cache node restarted and served old holds for about four minutes. The alert fired, the runbook worked, and no double-booking reached a patient, which the team counted as evidence that the design choice had been sound. Clinic managers reported that search felt faster, although the team had no direct measure of their perception.
Questions for discussion
- What would have to change about the workload for the event-driven option to become the better choice on its own merits?
- How much weight should a team give to an operational skill gap when the technically stronger option depends on it?
- Who should decide how much staleness is acceptable in a booking system, and how should that decision be recorded?
Case Study 5
Automated claim triage with a documented oversight plan
Greyfield Insurance Services, a claims administrator handling motor and home policies for regional insurers, with about 460 staff.
The situation
Greyfield's claims intake team sorted incoming claims into fast-track, standard, and fraud review queues by hand. Volume had grown, and a vendor proposed a model that reads claim notes and photos and assigns a queue, with the promise that most claims could skip manual sorting. The vendor's pilot report claimed a large reduction in handling time, but it used a sample from one insurer and excluded claims with incomplete notes. Greyfield's own sample of recent claims showed that the model would have sent a disproportionate share of rural and non-English claims to fraud review. Two claims adjusters had already flagged that the vendor's damage categories did not match how they coded losses.
The challenge
Leadership wanted a decision within the quarter, and the sponsor argued that the efficiency case was strong enough to proceed. The risk team wanted evidence that the model would not systematically delay or flag certain policyholders. Claims staff worried that the tool would become the default and their judgment would be overridden. The team had no labeled outcomes for fraud, only the decisions adjusters had made, and those decisions were shaped by past sorting habits.
Analysis
The business objective was faster, consistent triage without a rise in missed fraud or unfair delays. Those are two different measures, and the vendor reported only one of them. The company's own recent sample was the most useful evidence, since it included the incomplete notes the pilot had dropped. The adjusters' past decisions were also a biased reference, because they reflected older routing rules. The question to ask of any label is what it actually measures, since a model can copy a historical habit accurately and still be wrong for today's claims.
The constraints were mostly about who would be affected and how fast a bad output could spread. A misrouted claim does not fail loudly. A rural policyholder whose claim lands in fraud review waits longer, receives fewer updates, and may not know why. Oversight had to be built into the queue design, not added later as a review step, because a sampling check after the fact would only see the damage in aggregate. Adjusters needed a reason-coded override that fed back into evaluation, and the risk team needed routing rates by region and claim language. The sponsor's timeline could absorb a limited pilot, but not a full rollout.
- 1Shadow runModel suggests queues while adjusters keep sorting, and disagreements are logged.
- 2Regional pilotLive share in one region, every fraud flag reviewed by a person.
- 3Fairness checkCompare routing and delay rates across regions and claim languages before any expansion.
- 4Stop rulesPause routing automatically if fraud misses or override rates pass agreed limits.
- 5Wider releaseExpand only after two full review cycles with metrics inside agreed bounds.
Actions taken
- Defined evaluation metrics before the pilot: missed fraud rate, median handling time by region, override rate by adjuster, and error rate on incomplete notes, each with a stated threshold.
- Set a human checkpoint so no claim with a fraud flag or a coverage dispute was routed without an adjuster reviewing the model's reasoning in the case file.
- Rebuilt the damage categories with the two adjusters who had flagged the mismatch, then retrained on relabeled examples and compared results against the original vendor configuration.
- Wrote a rollback procedure that returned queue assignment to manual sorting in one step, tested it during the shadow run, and named the person who could invoke it.
Results
The shadow run showed that the model agreed with adjusters on about four out of five routing decisions, but the disagreements clustered in exactly the groups the risk team had worried about. After the categories were rebuilt and the fairness check was added, the regional pilot ran for two full review cycles. Handling time fell for standard claims, though the gain was smaller than the vendor had projected. Fraud misses stayed within the agreed limit, and the team chose not to expand to a second region until rural and non-English disagreement rates converged with the rest.
Questions for discussion
- Which of the proposed metrics would you trust least on a pilot this small, and what would you add to compensate?
- When the disagreement pattern follows a region or language, who should decide whether the model, the categories, or the historical labels are to blame?
- What should trigger the stop rule, and who should be allowed to restart a paused routing system?
Learning Resources
Professional CASE STUDIES
China, India, United States, Indonesia, Pakistan, Nigeria, Brazil, Bangladesh, Russia, Japan, Mexico, Philippines, Vietnam, Egypt, Turkey, Germany, United Kingdom, France, Italy, Canada, South Korea, Australia, Spain.