Delivery Approach Guide
Knowledge Guides /How do you transition from technical feasibility research to formal development, and can a prototype be accepted directly?
Last updated: · New Horizon Digital Outsourcing Team
Prototypes answer risk questions; formal delivery also requires production engineering, exception handling, and handover capability. A working prototype can support the next-stage decision but should not automatically be treated as deployable. Specify what it has and has not verified.
Plan feasibility work around risks, rather than page counts
- Prioritize interface, performance, or algorithm issues most likely to invalidate the approach. Define success and stopping conditions for feasibility work and bound its effort. Building only the easiest parts to demonstrate may leave critical issues unresolved until the end.
Retain the prototype's limitations
- Document simulated data, manual steps, simplifications, and temporary dependencies. A success message in a prototype may represent a fixed result; replace such shortcuts with real processing paths before the formal phase. A single demonstration video is not a maintainable asset.
How should the production-engineering checklist be defined?
- Add configuration management, logging, permissions, error recovery, build and deployment processes, and documentation. Assess which prototype code is worth retaining and which needs restructuring. An unchanged user workflow does not justify reusing the internal implementation without review.
How should acceptance differ between stages?
- Feasibility acceptance examines whether risks have been addressed with evidence; formal acceptance examines agreed functions and quality conditions. Deliver feasibility conclusions, reproducible examples, and next-stage recommendations. A finding of infeasibility can be a valid outcome; failures should not be hidden to make the work appear successful.