Tech Consulting Cases

PPTD framework

People, Process, Technology, Data. Use it to break down how an organization operates. Best for current-state analysis, diagnosing problems, readiness, and risks.

PPTD: People

Who uses the system; their skills, roles, capacity, pain points, and attitude toward change. Gather via interviews, observation, surveys, org charts.

PPTD: Process

How work flows end to end; handoffs, approvals, bottlenecks, manual steps, processing times. Gather via process maps and walking through real workflows with users.

PPTD: Technology

The systems themselves; what each does, overlaps, integrations, age, documentation, maintenance burden. Gather via IT interviews, system inventory, documentation review.

PPTD: Data

What data is stored, where, in what format; duplication, quality, completeness, security. Gather by comparing database structures and sampling records.

When to use PPTD vs the project lifecycle

PPTD when the question asks what is going on or what to analyze. The lifecycle when it asks what you would do and in what order.

Project lifecycle (7 stages)

Requirements, Design, Build, Test, Train, Deploy, Maintain. Use for any "how would you implement or roll out X" question.

Lifecycle: Requirements

Interview stakeholders, map current processes, document and prioritize what the new system must do. Output: prioritized requirements list.

Lifecycle: Design

Turn requirements into a blueprint: data structure, how systems connect, screens and workflows. Output: design documents such as an ERD.

Lifecycle: Build

Configure the system, build integrations, migrate and clean data. Output: working system in a test environment.

Lifecycle: Test

System testing, integration testing, user acceptance testing, and load testing. Output: sign-off that the system is ready.

Lifecycle: Train

Prepare users through training sessions, guides, and change champions. Core of change management.

Lifecycle: Deploy

Go live, either all at once or in phases, with a cutover plan and a rollback plan.

Lifecycle: Maintain

Fix issues, monitor KPIs against the baseline, and govern the data and system going forward.

Requirements prioritization approach

1) Rank and weight requirements with objective, client-agreed criteria. 2) Small leadership group approves the final priority list. 3) Track requirements through delivery with a traceability matrix.

Weighted scoring criteria (examples)

Impact on the client's goal, number of users or units affected, dependencies, effort and cost, risk or compliance need.

MoSCoW

Prioritization method: Must have, Should have, Could have, Won't have (this time).

Scope constraints framework

Time, budget, resources, then case-specific factors such as policy changes, documentation quality, compliance requirements, and the client's acceptance of change.

Decision framework for comparing two options

Benefits, costs (one-time vs ongoing), timing (short vs long term), and risks. Give one sentence per bucket, then make a recommendation.

Package gap decision rule

Adopt the software's standard process where possible; configure where needed; customize only as a last resort; avoid workarounds.

Questions to ask for each fit-gap item

1) Is it legally required? 2) Is it a real need or just habit? 3) What is the cost and time against the deadline? 4) What is the long-term impact on maintenance, upgrades, and end users?

Data-for-AI framework

Can we use it (regulations, policy)? Should we use it (ethics, bias, PII)? Is it good enough (data quality)? Where does it go (storage, access, how it is used)?

Roadmap contents

Parallel workstreams, milestones, outcomes, dependencies, and a phased timeline. Detail (activities, owners, schedules) lives in supporting documents.

The "so what" after numbers

1) What the result means. 2) How confident you are (key assumptions). 3) What the client should do with it.

Common sorting lenses

PPTD; business/organization/workforce; internal/external; short-term/long-term; before/during/after; can we/should we/are we able to.

Answer delivery habit

Brainstorm, group into 3-4 labeled buckets, signpost the labels first, prioritize the most important bucket, and close by linking back to the client's goal.

Case note-taking template

Client; Goal; Constraints (time, budget, people); Key numbers; Anything odd (oddly specific details are usually clues).

Current state

How the organization and its systems work today.

Future state

How the organization and its systems should work after the change.

Gap analysis

Comparing the current state with the desired future state to identify what must change.

Fit-gap analysis

Comparing a software package's out-of-the-box capabilities against the client's requirements to find where it fits and where there are gaps. The core activity early in a package implementation.

Requirements gathering

Collecting and documenting what a system must do, through interviews, workshops, process walkthroughs, and document review.

Functional requirements

What the system must do, such as calculate eligibility or generate a letter.

Non-functional requirements

How well the system must perform, such as speed, capacity, security, uptime, and accessibility.

Use case

A description of how a user interacts with the system to accomplish a specific task.

User story

Agile format for a requirement: As a [user], I want [goal], so that [benefit].

Traceability matrix

A table linking each requirement to its design, build, and test items, so nothing gets lost through implementation.

Stakeholder analysis

Identifying everyone affected by or influencing the project, their interests, and how to engage them.

Maturity assessment

Evaluating how ready each part of an organization is to adopt a capability, across people, process, technology, and data.

Change readiness assessment

Evaluating how prepared users and the organization are to accept and adopt a change.

Enterprise architecture

The overall blueprint of how an organization's systems, data, and processes fit together to support its goals.

Data architecture

The blueprint for how data is organized, stored, related, and shared across systems.

Data model

A definition of the types of records, their fields, and how they relate to each other.

ERD (entity-relationship diagram)

A diagram showing record types (entities), their fields, and how they relate. Used in the design stage.

Data mapping

Comparing fields across systems to see where the same information is stored, under what names and formats.

Master data / golden record

A single, trusted version of a key record (such as a customer or applicant) used by all systems.

Data migration

Moving data from old systems to a new one, including cleaning and validating it.

ETL

Extract, Transform, Load: pulling data out of source systems, cleaning and reformatting it, and loading it into the target system.

Data cleansing

Fixing errors, inconsistencies, and missing values in data before or during migration.

Deduplication

Finding and merging duplicate records. Done with automated matching rules, with humans reviewing only uncertain cases.

Data validation at entry

Checks built into a system that stop bad or duplicate data from being entered in the first place.

Data governance

Rules and ownership for how data is defined, managed, accessed, and kept clean over time.

Data quality

How accurate, complete, consistent, and current data is. AI and analytics are only as good as the data behind them.

PII

Personally identifiable information, such as names, Social Security numbers, account numbers. Must be protected.

PHI

Protected health information. Health-related personal data with strict legal protections.

Legacy system

An older system still in use, often hard to maintain, poorly documented, and hard to integrate.

Technical debt

The future cost created by quick fixes, custom code, and workarounds that make systems harder to maintain and change.

COTS

Commercial off-the-shelf software: a ready-made package bought from a vendor rather than built from scratch.

SaaS

Software as a service: software hosted by the vendor in the cloud and accessed over the internet, usually by subscription.

Cloud scalability

The ability of cloud systems to add capacity automatically when demand spikes.

Configuration

Setting up packaged software using its built-in tools (settings, workflows, rules, forms) without writing new code. Preferred approach.

Customization

Writing new code to change what packaged software does. Riskier: costlier, harder to maintain, and can break when the vendor updates.

Workaround

A manual step or separate tool used outside the main system to fill a gap. Hard to control; often creates undocumented spreadsheets.

Integration

A supported connection that lets two systems exchange data, such as a case system sending payments to a treasury system.

API

Application programming interface: a standard way for systems to talk to each other and exchange data.

System integrator

The firm that implements and connects software for a client, such as Deloitte implementing a purchased platform.

ERP

Enterprise resource planning: software that runs core functions like finance, HR, procurement, and supply chain (e.g., SAP, Oracle, Workday).

CRM

Customer relationship management: software for managing interactions with customers or constituents (e.g., Salesforce).

Waterfall

Project approach where stages run one after another in sequence.

Agile

Project approach that builds and tests in short cycles (sprints), getting user feedback along the way.

Sprint

A short, fixed agile work cycle, usually two to four weeks, that delivers a usable piece of work.

Pilot

A small-scale trial with a limited group of users or sites before full rollout.

Big-bang rollout

Launching the new system for all users or sites at once. Faster, but higher risk.

Phased rollout

Launching in waves (by site, unit, or function). Lower risk, but takes longer and means running two systems in parallel for a while.

Parallel run

Running the old and new systems side by side for a period to compare results and reduce risk.

Cutover plan

The step-by-step plan for switching from the old system to the new one at go-live.

Rollback plan

The plan for reverting to the old system if go-live goes badly wrong.

Go/no-go criteria

Agreed conditions that must be met before launch, so the go-live decision is based on facts, not pressure.

Hypercare

A period of extra, intensive support right after go-live.

System testing

Testing whether the system works correctly on its own.

Integration testing

Testing whether connected systems exchange data correctly.

User acceptance testing (UAT)

Real users test whether they can complete their actual tasks in the system before sign-off.

Load / performance testing

Simulating high volume (such as a surge in claims) to confirm the system will not slow down or fail.

Regression testing

Re-testing existing features after changes to make sure nothing that previously worked has broken.

Change management

The structured approach to helping people adopt a change: analysis, design (training, communications, champions), and implementation and measurement.

Change impact analysis

Assessing which groups are affected by a change, how, and how much.

Change champions / super users

Respected users trained early who support and train colleagues and feed back issues.

Training plan

Who needs to learn what, how (sessions, guides, demos), and when, timed to match the rollout.

Communications plan

What messages go to which stakeholders, through which channels, and when.

Adoption metrics

Measures of whether people actually use the new system, such as share of work processed in it, logins, and help desk tickets trending down.

KPI

Key performance indicator: a specific, measurable target used to track success (e.g., time to first payment).

Baseline

The measured starting point before a change, used to prove improvement later.

ROI

Return on investment: the benefit gained relative to the cost.

Workstream

A parallel track of related work within a project, such as data, testing, or change management.

Milestone

A key checkpoint in a project, such as "first pilot live."

Dependency

Something that must be completed before another task can begin.

Project governance

The structure for decision-making, oversight, and approvals on a project.

PMO

Project management office: the team that tracks progress, risks, and coordination across workstreams.

Scope creep

Uncontrolled growth in project scope beyond what was agreed, usually threatening time and budget.

RACI

Responsible, Accountable, Consulted, Informed: a chart clarifying who does what on each task.