Enterprise System Discovery

Owners often jump straight to a solution (“we need an AI system”) without defining the problem. If the problem is vague, the system will be vague, overbuilt, or solve the wrong thing.

A specific pain, cost, risk, delay, or missed opportunity. Ask: “What does this problem cost us today in money, time, risk, or customer satisfaction?”

“We just need to be more digital” or “everyone else has one.”

Urgency reveals whether the project is a real priority or a pet idea. Triggers include regulation, competitor pressure, growth, an outage, a failed audit, or a new executive.

A concrete event or deadline. If there’s no trigger, funding and attention may disappear later.

“What changes if we delay by six months?”

This tests whether the project is truly necessary. If nothing bad happens, it may be a “nice to have” and should be scoped small or deferred.

Quantified consequences: lost revenue, compliance fines, churn, manual cost, security exposure.

“Nothing much, but it would be nice.”

Projects aligned to strategy get resources, executive cover, and priority. Misaligned projects die quietly.

A clear link to revenue, margin, customer experience, risk reduction, or scalability.

“Which strategic goal does this support, and who owns that goal?”

Outcomes, not features, define success. They also help prioritize trade-offs later.

Measurable outcomes like “reduce onboarding time by 40%” or “cut fraud losses by $2M annually.”

A list of features instead of outcomes.

Reveals hidden expectations, political risks, and non-negotiables. It also surfaces what the owner fears most.

Specific failure scenarios: late delivery, poor adoption, security breach, cost overrun, loss of control.

“How would we detect that early enough to correct it?”

Without metrics, success becomes opinion. You need a baseline, target, timeframe, and owner.

A small set of metrics tied to the business outcomes. Ask: “Where does that number come from today?”

“We’ll know it when we see it.”

Prevents scope creep and forces prioritization. V1 should be the smallest thing that delivers value.

A short list. Use MoSCoW: must, should, could, won’t.

“If we could only ship one of these, which one?”

Boundaries prevent later misunderstandings. “Out of scope” is as important as “in scope.”

Clear exclusions: geographies, user groups, integrations, reports, edge cases.

“Everything is in scope.”

Defines acceptance criteria and closes the project. Without sign-off, projects drift forever.

A named person or group, a checklist, and a date.

“What evidence do you need to see to sign off?”

Deadlines drive scope and approach. A regulatory date is different from an arbitrary one.

The reason behind the date: audit, product launch, budget cycle, board meeting.

“Is the date fixed, or is it negotiable if scope changes?”

You cannot maximize all four. The owner must choose what matters most.

A clear priority order. If everything is fixed, the project is set up to fail.

“We need it fast, cheap, perfect, and with everything.”

Systems are used by real people with different skills, incentives, and workloads. Admin and support ownership must be clear.

Personas, volumes, locations, skill levels, and current tools.

“Can I speak to three of them?”

A new system means new processes. If you don’t map the change, people will work around it.

Current workflow, future workflow, exceptions, approvals.

“The system will just automate what we do today.”

Projects fail because of politics, not just technology. Identify champions and blockers early.

Teams that gain power, teams that lose autonomy, managers whose headcount changes.

“How will you handle that resistance?”

Workarounds reveal real requirements, data gaps, and hidden complexity.

Shadow systems, duplicate entry, offline approvals, personal databases.

“Nobody uses spreadsheets” when everyone knows they do.

Adoption is not automatic. Training, documentation, and support must be budgeted.

Number of users, turnover, digital literacy, language needs.

“Who will own training after go-live?”

In some regions, employee consultation is legally required. Ignoring it can delay or block deployment.

Consultation requirements, collective agreements, communication plans.

“We’ll just tell them after it’s built.”

Data defines interfaces, schemas, volumes, and quality requirements.

Source systems, fields, formats, frequency, ownership.

“What happens if the data is wrong or missing?”

Data ownership affects access, quality, and accountability. Without an owner, data problems become project problems.

Named data stewards, systems of record, access controls.

“IT owns all data” with no business owner.

Garbage in, garbage out. Poor data can require cleansing, migration, and ongoing governance.

Duplicates, missing fields, inconsistent formats, manual corrections.

“Who is accountable for fixing data quality?”

Integrations are often the biggest source of delay and cost.

APIs, file transfers, middleware, authentication, rate limits, legacy systems.

“It should integrate with everything” with no list.

Reporting is frequently underestimated. It can drive data model and performance requirements.

Audience, frequency, dimensions, drill-down, export needs.

“What decision will this report drive?”

Legal, compliance, and storage costs depend on how long data is kept and how it moves.

Retention periods, legal holds, archiving, historical migration.

“Keep everything forever” with no policy.

Standards reduce risk, cost, and support burden. They also limit choices.

Approved stacks, existing enterprise agreements, security baselines.

“What is the process to approve a new technology?”

Security must be designed in, not bolted on. These requirements affect architecture and cost.

Identity provider, access model, encryption at rest and in transit, logging, penetration testing.

“We’ll worry about security later.”

Compliance determines data handling, audit trails, vendor contracts, and liability.

Specific regulations, audit history, certification requirements.

“Who is the compliance owner, and what evidence do they need?”

Data may need to stay in certain countries or be processed under specific privacy rules.

Geographic restrictions, consent management, data subject rights.

“We’ll store it wherever is cheapest.”

Defines how much downtime and data loss the business can tolerate.

Recovery time objective (RTO), recovery point objective (RPO), backup frequency, failover.

“Have we tested that before?”

Without early approval, you risk rework or a blocked launch.

Architecture review board, security team, CISO, data protection officer.

“We’ll get approval at the end.”

Budget reveals realism and constraints. CapEx vs OpEx affects vendor and cloud choices.

Total cost of ownership, not just build cost. Include licensing, support, training, and operations.

“What happens if we exceed this by 20%?”

Identifies the real decision-maker and funding path.

Budget owner, approval thresholds, committee reviews.

“We’ll figure out funding later.”

Projects fail when they lack business input and technical support.

Named people, percentage allocation, backfill plans.

“Are they available, or are they already overcommitted?”

Milestones create accountability and allow phasing.

Business events, regulatory dates, board reviews, budget cycles.

One big-bang deadline with no interim value.

This is a strategic choice with different cost, speed, and flexibility trade-offs.

Appetite for custom development, vendor lock-in, internal capability.

“What have you done successfully in the past?”

The build is only part of the cost. Operations can be 2–5× the initial build.

Annual budget, headcount, vendor management.

No plan for ongoing costs.

Without a sponsor, projects stall when priorities conflict.

A named executive with authority and budget.

“The steering committee decides” but no single owner.

Identifies veto holders and required consultations early.

Security, legal, compliance, finance, works council, key business units.

“What would make them say no?”

Decision cadence prevents delays and rework.

Meeting rhythm, escalation path, decision log.

“We’ll decide as we go” with no owner.

Adoption depends on people understanding why and how their work changes.

Communication channels, training, champions, feedback loops.

“Who is responsible for adoption?”

Unspoken conflicts can kill a project. Better to know early.

Past failed projects, turf wars, budget battles, personal histories.

“There are no politics here.”

Resistance is normal. The response determines whether the system is used.

Incentives, training, escalation, willingness to enforce.

“What happens if a team refuses to adopt it?”

Someone must own incidents, requests, and uptime. SLAs define expectations.

Support team, hours, escalation, response times.

“The project team will support it” with no long-term plan.

Operational readiness prevents outages and security gaps.

Tools, schedules, responsibilities, runbooks.

“Who gets paged at 2 a.m.?”

Documentation reduces dependency on individuals and speeds onboarding.

Owner, format, review cycle, localization.

“We’ll document it later.”

Scalability and extensibility should be designed early, not retrofitted.

Expected growth, multi-language, multi-currency, multi-entity.

“What does 3× volume look like?”

You need a way out if the vendor fails, costs rise, or strategy changes.

Data ownership, export formats, termination assistance.

Proprietary formats with no export.

Prevents building a dead end. The system should support future business plans.

Phases, new capabilities, integrations, user growth.

“What would trigger a replacement?”

Data is a business asset. Custom IP may be valuable later.

Clear ownership terms, licenses, rights to use.

Vendor owns your data or custom work.

Legal protection if the vendor underperforms.

Uptime commitments, remedies, exit clauses, notice periods.

“What happens if they miss the SLA repeatedly?”

Vendors introduce risk. Contracts should require security controls and insurance.

Security addendum, breach notification, liability, cyber insurance.

No security terms.

Validates claims and reduces risk.

Similar industry, size, geography, use case.

“Can we speak to them directly?”

You don’t want to buy a product that is being sunset or moving in a different direction.

Investment areas, release cadence, customer advisory board.

No roadmap or vague promises.

Continuity planning protects your operations.

Source code escrow, transition assistance, data export rights.

“What is our contingency plan?”