Technical Feasibility: Map the Risks Before Software Development

The screen list for a dealer portal is ready: products, stock, orders and reports. During scheduling, the team learns that stock must come from an older system. Nobody yet knows who can grant access, how often the records update or whether a test environment exists. Design can continue while the fundamental dependency remains unresolved. Technical feasibility turns that uncertainty into a decision before it becomes an expensive surprise during development.

The dealer portal is hypothetical. We will use it to examine a practical risk map. Feasibility is more than selecting technology or saying something can be built. It should explain the conditions, dependencies and limits of a proposed approach. The outcome may be development, a focused experiment or a revised scope. In each case, preserve the evidence behind the decision and identify what has not yet been verified, rather than letting a positive conclusion imply certainty across the entire project.

Start with the critical assumption

What must be true for the portal to serve its purpose? Stock information must arrive appropriately, dealers must see only authorised records and orders must reach the intended system. These statements expose foundational assumptions. Review them before giving every screen equal attention. An attractive report does not solve unavailable source data. Feasibility should prioritise information capable of changing the project's direction instead of beginning with the most visible or enjoyable part of the interface.

Separate a requirement from its enabling condition. Showing stock is desired behaviour; being able to obtain suitable stock information from the existing system is a condition to verify. Combining them can make uncertainty appear resolved. Record the evidence beside each condition: documentation, tested access or a person's statement. This distinction keeps expectation separate from established knowledge. An owner and review point can make the next investigation understandable rather than leave an open question buried in a general specification.

Investigate integration dependencies directly

Knowing the external system's name does not define the connection. Ask which record moves in which direction, what access is available and whether current documentation and testing exist. Reading stock and creating orders may need different authority and behaviour. Involve the source-system owner. Complete “integration is available” with evidence about the operation required under relevant conditions. A ready-made connector can cover a different data scope, so a matching name does not establish fitness for the intended workflow.

Discuss failures early. What should users see when information is delayed? If an order is sent but no response arrives, should the application retry or investigate status? How are maintenance and changes communicated? Every detail may not be resolved initially. Still, list consequential questions and identify the appropriate technical test. Discovering a dependency does not mean answering everything that day. It means establishing a visible route towards the information required before making a stronger commitment.

Distinguish available data from usable data

A table containing product information is not necessarily ready for the portal. Are codes consistent, inactive products identified and duplicate records understood? Names and descriptions for dealers may come from another source. Examine appropriate sample records. Empty interface designs do not expose these problems. Prepared or anonymised examples make relationships and omissions easier to discuss than a field list whose values and history nobody has inspected.

Identify data ownership. Which team corrects a wrong product definition or stock value? Does a portal change write back to the source? If both systems allow editing, which record governs? These decisions affect operations as well as implementation. Feasibility should not reduce data problems to a developer's import task. Cleaning, verification and everyday maintenance require responsible people. Their availability is part of whether the project can operate, not merely an administrative issue to address after technical approval.

Test permissions and context through examples

Dealers, internal sales staff and managers may need different information. Some see prices while others see descriptions only. Define record ownership and permitted actions. Saying that roles will exist does not explain those boundaries. A scenario in which one dealer must not see another's orders is more concrete. Evaluate behaviour beyond hiding interface elements. The data rules should support the same boundary so the intended separation does not depend only on what a screen displays.

Investigate everyday use too. Are people working on phones or desktops, editing the same record or handling interrupted connectivity? These conditions can change the design and technical approach. Excluding every difficult situation can make a plan look simple while removing its practical usefulness. Separate required conditions from optional expansion. Usability review belongs within feasibility because the system must work in the real operation, not only run successfully in a controlled demonstration detached from user circumstances.

Connect performance expectations to a scenario

Fast is agreeable but ambiguous. Which operation, data volume and concurrent-use condition matter? Search, large orders and reporting can create different demands. Select critical scenarios, then establish suitable targets through evaluation. Do not insert guessed numbers as confirmed requirements. Where volume is unknown, record how it will be investigated or the conditions within which it will be assessed. A useful target gives testing a meaningful business context rather than a decorative figure in a proposal.

Explain how well a performance test represents expected use. A small dataset does not prove behaviour at a larger scale. Conversely, using an irrelevant extreme scenario as the sole criterion can encourage unnecessary complexity. Present environment, records and limits together. The aim is not an impressive number. It is evidence that an approach can meet the organisation's need under stated conditions, with further investigation planned where the available test cannot yet support the intended conclusion.

Make security and operation visible

Access management, history, backup, restoration and issue reporting influence sustainability. Who performs each control, and what information reaches which team after a problem? Feasibility should go beyond establishing that the original developers can write the code. The business must be able to operate and maintain the result. Review depth depends on data and operational risk. Listing control names is not evidence that they have been designed, implemented or verified for the intended environment.

Assign ownership of hosting, domains, third-party accounts and deployment access. A setup tied to one person's private account can complicate handover. Discuss maintenance and support separately: which work can the business perform, and where is specialist help required? When assessing Custom Software Projects, connecting these operating conditions with discovery and development makes responsibilities beyond the first delivery clearer. It also prevents an apparently feasible build from depending on an undefined support arrangement after launch.

Put reasoning behind the risk map

For each risk, record cause, possible effect, evidence, owner and next action. If using likelihood and impact labels, agree what they mean. Precise percentages without adequate information create artificial certainty, while a high label alone provides little direction. In our portal, unavailable stock access can block the main journey; delayed visual customisation has a different effect. Reasons make that difference visible and help different disciplines discuss the same problem without treating a colour-coded score as a complete explanation.

Connect risks to work: an access discussion, a sample-data delivery or a technical experiment. Each needs an owner and checkpoint. The map becomes a plan for reducing uncertainty rather than a catalogue of why development is difficult. Preserve the evidence when an issue closes. Someone saying it is fine does not reveal what was tested or agreed. A usable record lets the next decision build on established knowledge instead of reopening the same question through another informal conversation.

Different responses may suit the same risk

A dependency can be resolved, scope changed, another source selected or a limit accepted under stated conditions. Not every response requires building more technology. A visible stock-update time may suit one operation and fail another's fundamental need. Decide alongside the business effect and keep the information boundary understandable to users. Feasibility is useful when it shows alternatives honestly, allowing management to answer a more meaningful question than whether development is theoretically possible.

End with an actionable decision

The review can support development, targeted investigation or reconsideration of scope. These are not rigid categories but ways to turn findings into work. State conditions on continuation: what is confirmed, which dependency remains and what must happen before the next task starts? Research needs a question and output. Scope changes need assessment of their effect on users. A vague positive opinion is not an adequate ending when important actions and unresolved dependencies still have no owners.

Return to the portal. The team can obtain records, but the operational effect of delayed updates remains unknown. Instead of committing the entire project to a fixed schedule, it may select a limited workflow and usage review. That looks smaller than the original screen list while resting on more concrete information. This is the practical output of feasibility: a project starting with an understood route, explicit conditions and open questions that people know how to investigate before the next larger decision.

Keep procurement and business decisions visible

A test account, participation from another system's owner or an internal decision about data cannot be supplied merely by writing code. Include these tasks in the plan. If work depends on a business decision, identify its owner and required information rather than assigning a developer an undefined deadline. Review current third-party terms where relevant. Feasibility should not hide these dependencies as details the technical team will somehow resolve. Delivery depends on obtaining cooperation and inputs as well as having the skills to implement the software.

Frequently asked questions

When should technical feasibility be assessed?

Review foundational dependencies before a major development commitment. Depth varies with risk; a simple internal tool and a multi-system operation need different effort. The important point is to keep critical assumptions visible behind screen and schedule decisions. Revisit findings when new information appears. Feasibility is a basis for informed progress, not a document whose existence prevents later learning or removes the need to assess changed conditions.

Does feasibility make every detail certain?

No. It should show confirmed information and open questions. Some points need a prototype or technical experiment. A useful conclusion selects the next action rather than hiding uncertainty. A decision with an explained confidence boundary can be more valuable than a plan appearing complete while resting on unknown assumptions. The review should improve the basis for commitment, not imitate certainty the evidence cannot provide.

Is feasibility the same as a scope document?

They support each other but have different functions. Scope describes what will be developed and how it will be accepted. Feasibility investigates the conditions and uncertainties affecting that work. Findings may change scope. Connecting the two helps requested features reflect real dependencies instead of treating the desired list as proof that access, data and operational responsibilities are already available.

Is a prototype always necessary?

Some questions can be assessed through documentation, sample records or existing access. Others require experiments. Do not apply one prototype method to every unknown. Select evidence appropriate to the decision. A visual design does not prove integration behaviour, and a technical demonstration does not automatically establish that users understand the journey. The methods can complement each other while remaining clear about what each actually shows.

Must a project stop after a negative result?

Consider alternatives. Scope can change, a dependency can be resolved or a different approach selected. Sometimes stopping is appropriate. A negative finding can improve a larger investment decision rather than represent failure by itself. Record which changed condition would justify reconsideration. That preserves useful knowledge and prevents the same unsupported proposal from returning later without acknowledging what the review already established.