A proposal can be strategically sound and still be poorly understood.

The objective may be clear. The sponsor may be credible. The anticipated benefit may be worth pursuing. Yet the organization can remain uncertain about which capabilities must change, whose work will be affected, what information must become reliable, which other initiatives share the same dependencies, and who will own the result once the project ends.

Those uncertainties do not disappear when funding is approved. They become delivery problems.

A team discovers that the proposed improvement depends on information nobody owns. A process change transfers work to an organization that was not involved in the proposal. Two initiatives promise different outcomes but require changes to the same capability, system, and operational team. A technology implementation finishes while the decisions, responsibilities, and measures needed to use it remain unresolved.

Each problem may eventually receive a name: scope growth, a resource constraint, a requirements gap, a change-management issue.

But some of these problems begin earlier. The enterprise commits to a change before it understands enough about what that change touches.

Impact assessment belongs in that space. Its purpose is to make consequences visible while leaders still have meaningful choices about whether to proceed, what to fund, how to sequence the work, and which conditions must be satisfied first.

What are we actually approving?

Consider a fictional equipment-services company proposing a customer self-service portal. Customers should be able to check equipment availability, request service, view agreement details, and track open work without calling a service center. The proposal anticipates fewer routine calls and a better customer experience.

A technology estimate can describe the effort needed to build the interface and connect it to existing applications. That estimate is necessary. It does not describe the whole change.

What does “available” mean when equipment is physically present but awaiting inspection? Which source determines whether a customer is entitled to service? Who resolves a disagreement between the agreement record and local operating practice? What happens when the portal accepts a request that a branch cannot fulfill? Which team handles exceptions, and how will its workload change?

If availability information is unreliable, the portal may make that unreliability more visible. If service entitlements are interpreted differently across branches, self-service requires a decision about whether those differences should continue. If customers can create requests around the clock, the operating model needs a corresponding response policy.

The investment decision is therefore larger than “Should we build a portal?” It includes information, service rules, accountability, operational readiness, and the acceptable boundaries of the first release.

Begin with the decision and the intended outcome

An early proposal may need a decision about whether to investigate further. A portfolio review may need evidence to compare investments. A funded initiative may need a decision about release boundaries or a material scope change. These decisions require different levels of detail.

Start by establishing the problem, intended outcome, options, decision required, authorized decision-maker, constraints, and material assumptions.

“Improve customer experience” is too broad to guide the portal assessment. “Reduce routine status calls by enabling customers to obtain dependable equipment and service information” gives the team something more specific to test. The assessment should establish the current call baseline, desired reduction, measurement period, and accountable owner. Where evidence is missing, finding it becomes part of the work.

Call volume alone is insufficient. Calls could fall because customers successfully serve themselves, or because they give up. Successful self-service completion and exception-resolution performance would help distinguish those outcomes.

Fewer calls also do not automatically produce lower cost. They might release capacity, improve service, or enable an actual spending reduction. The business case needs to explain which benefit is expected and what operating decision would realize it.

This framing creates room to challenge the proposal. If unresolved service exceptions cause most customer frustration, better visibility alone may have limited value.

A useful assessment follows relationships

A list saying “people, process, data, and technology” offers little help unless it explains what changes, why those changes matter, and how they relate.

Business architecture provides a structured way to investigate those relationships. Begin with the objective and its measures. Identify the value streams and stages affected, then the capabilities enabling those stages. Follow the connections to information, stakeholders, organizations, and existing initiatives.

In the fictional company, the customer seeks equipment that can be used when needed. An assessment might locate the impact in a stage where the customer confirms availability before committing to a request. That stage depends on the ability to determine equipment availability, establish service entitlement, and accept a request the company can fulfill.

Those abilities rely on information about equipment, inspections, agreements, and service requests. “Present at the branch” and “ready for customer use” describe different conditions. The assessment must determine which conditions support the customer promise and who can establish them.

The relationships lead to inspection teams, branch operations, agreement owners, and service-center staff. They also point toward existing work: an inspection-system replacement or an agreement-standardization initiative might already be changing the same information and capabilities. That overlap warrants investigation for dependencies, conflicts, or opportunities to share work.

From there, process and technology specialists can examine handoffs, controls, exceptions, applications, integrations, and suppliers. Operational owners must test capacity, decision rights, and how the business will function during transition. The architectural connections give those investigations a common business context.

The models are starting evidence. Their completeness and currency still need to be tested. A capability map may not reveal that three branches interpret availability differently or that a daily spreadsheet compensates for a system limitation. The assessment has to reach the people who know how the work operates.

Two questions guide the investigation:

What must be different across the enterprise for the intended outcome to become possible?

What else becomes different because we make those changes?

The first identifies necessary change. The second looks for consequences beyond the sponsor’s immediate scope.

Distinguish evidence from expectation

“The service organization will absorb the additional exception workload” could represent an agreed commitment, a preliminary estimate, or an unsupported assumption. Those are materially different conditions for an investment decision.

An important finding should identify the affected area, expected change, supporting evidence, who validated it, and unresolved uncertainty. In the fictional portal assessment, a finding might read:

The first release depends on a consistent definition of equipment availability. Branch interviews identified differing treatment of equipment awaiting inspection. An enterprise definition has not yet been approved. The relevant business owners must resolve this before customer-facing availability can be treated as dependable.

This identifies a dependency, records an unresolved decision, and connects it to the proposed outcome. Leaders could resolve the definition, narrow the release, fund discovery, or reconsider the benefit.

An unexplained red cell on a heat map does much less.

Unknowns are legitimate assessment results. The discipline lies in deciding which must be resolved before commitment, which can be managed during delivery, and which should limit confidence in the business case.

Match the effort to the consequence

Impact assessment will lose support if every proposal triggers the same extensive process. I would use three tiers as a practical starting point:

  • Initial screening: Establish the outcome, likely impacts, ownership, dependencies, and uncertainties. Determine whether deeper assessment is needed.
  • Focused assessment: Validate cross-functional impacts, compare meaningful options, and recommend boundaries or conditions for proceeding.
  • Extended assessment: Investigate substantial enterprise consequences, difficult reversibility, or tightly connected dependencies, with specialist analysis and transition planning where needed.

Budget alone is an inadequate guide. A relatively inexpensive change to a shared definition can affect many business units. Screening should consider reach, uncertainty, reversibility, disruption, external obligations, and dependence on other changes.

Proportionality requires a distinction between breadth and depth. A lightweight assessment can limit detail while still checking for consequences beyond the sponsoring team. Calling a proposal “local” does not establish that its effects are local.

Follow the relevant relationships far enough to test that boundary. Deepen the assessment where the evidence warrants it, and revisit the tier when new dependencies emerge.

Put the assessment in front of a real decision

An assessment has less influence once dates are announced, suppliers selected, teams assigned, and benefits communicated as settled expectations. Initial screening should occur early enough to shape entry into the portfolio, with deeper assessment integrated into the organization’s planning and funding cycle.

Sometimes the appropriate decision is to fund discovery. A bounded investment can establish whether information is usable, the operating model is feasible, or a dependency can be resolved before the next commitment.

The assessment should support a concise decision brief, backed by detailed evidence. Explain the outcome, significant impacts, options, dependencies, recommendation, accountable owners, and unresolved conditions. Make clear what would change the recommendation. The findings should inform target-state design, initiative scope, and the business case.

The decision may be to proceed, proceed with conditions, fund discovery, narrow or resequence the change, combine related work, defer, or stop. Governance should recognize all of these as legitimate outcomes.

If approval is the only acceptable answer, assessment becomes a justification exercise.

Exhaustiveness has a cost. A large assessment that gives every observation equal prominence can obscure the few findings that should determine the decision. The architect’s contribution includes selecting and explaining what matters.

Accountability must survive the meeting

An architect can organize the assessment, trace relationships, challenge inconsistencies, and explain consequences. The architect cannot make every operational commitment on behalf of the affected organizations.

The sponsor needs to own the proposed outcome and its business rationale. Business owners need to validate impacts and commitments within their areas. Technology, finance, security, legal, and other specialists contribute where the proposal requires their expertise. The authorized decision-maker accepts the tradeoffs and unresolved uncertainty.

Agreement also needs to be precise. A stakeholder’s attendance at a workshop does not establish that their organization has accepted additional work, committed resources, or approved a new operating responsibility.

For the portal, the service organization might agree that an exception process is necessary while withholding any commitment to operate it with existing staffing. Recording that distinction protects the investment decision.

Disagreement is useful evidence. It may reveal competing incentives, unclear authority, or a transfer of cost from one part of the enterprise to another. Removing those tensions from the final presentation can make a proposal look easier to execute than it is.

Carry the findings into execution and back into the repository

Assessment findings describe a proposed change under particular conditions. A supplier changes, an enabling initiative is delayed, or a release adds a business unit. Material changes should trigger focused reassessment of the conclusions that depend on them.

Important findings should carry into delivery planning, readiness reviews, and benefit evaluation. For the portal, an approved availability definition becomes a delivery and readiness requirement. Exception ownership becomes part of the operating transition.

Important assumptions also need an owner, an observable test, and a point at which contrary evidence prompts reconsideration. If a pilot shows that customers repeatedly call after checking the portal, the team should investigate while it can still change the service. Waiting until implementation is complete wastes the opportunity to learn during execution.

That learning should improve the shared architecture repository. Validated definitions, ownership, and dependencies belong in maintained models and cross-mappings, with their evidence and approval status. Unconfirmed relationships should remain marked for validation. Updates should follow the repository’s governance process.

Otherwise, each initiative pays to rediscover the same enterprise. A useful assessment leaves behind both a better decision and knowledge the next team can reuse.

Measure whether the discipline helps

Counting completed assessments tells us that a process exists. It provides little evidence that the process improves decisions.

Did the assessment change the proposal, sequence, boundaries, or funding conditions? Were dependencies identified early enough to influence action? Did affected owners understand and accept their commitments? Were assumptions tested?

During delivery and after implementation, compare assessed impacts with actual consequences. Examine what was missed and whether weak evidence or a changed proposal explains the difference. Use the findings to improve future assessments.

Track elapsed time as well. Repeated document revision and an unresolved business decision require different responses. The useful question is whether assessment improves commitments at a reasonable cost.

Where AI can help

AI can help extract candidate impacts, compare terminology, summarize interviews, and assemble questions for affected owners. It can highlight contradictions, such as a proposal claiming to preserve the operating model while its process description transfers decision authority.

The result inherits the limitations of its evidence. Incomplete models, outdated documents, and undocumented work remain problems. Fluent prose can make them harder to notice.

I would require AI-assisted assessments to distinguish source-supported findings, inferred relationships, and unanswered questions, with significant findings traceable to evidence. The architect evaluates the relationships; affected owners validate their operational meaning and confirm commitments.

AI can accelerate the preparation and examination of evidence. It cannot establish stakeholder agreement or accept business accountability.

Make commitments with a clearer view

Impact assessment will not eliminate surprises. Enterprises are complex, information is incomplete, and people respond to change in ways a model cannot fully predict.

The discipline should help an organization understand enough to make a responsible commitment. Business architects are well placed to lead that analysis when they combine enterprise relationships with operational evidence and stakeholder judgment.

The test is what happens to the decision.

Can leaders see what they are committing to? Can affected owners recognize their responsibilities? Can delivery teams trace the conditions behind the promised benefit? Can the organization explain why this approach is preferable to the alternatives?

Before an enterprise asks how quickly it can deliver a proposal, it should understand what delivering that proposal will require of the enterprise.

Source note: This field note draws on the Business Architecture Guild’s BIZBOK® Guide, version 11.0, §2.1, especially the strategy impact-analysis guidance on pp. 52–53; Charles F. Bowman and William M. Ulrich’s End-to-End Strategy Execution: From Inception Through Solution Deployment (2026), Chapter 5; and the operational learning principles in Steven J. Spear’s The High-Velocity Edge, Chapter 1. The assessment tiers and AI recommendations are practical proposals here, rather than prescriptions attributed to those sources. The equipment-services example is fictional.