Understanding Feasibility Study Approach for Packaged Software Implementation by SMEs

Software engineering often no longer involves building systems from scratch, but rather integrating functionality from existing software and components or implementing packaged software. Conventional software engineering comprises a set of influential approaches that are often considered good practice, including structured programming, and collecting a complete set of test cases. However, these approaches do not apply well for packaged software (PS) implementation; hence this phenomenon requires independent consideration. To explore PS implementation, we conducted ethnographic studies in packaged software development companies, in particular, to understand aspects of the feasibility study approach for PS implementation. From an analysis of these cases, we conclude that firstly; the analyst has more of a hybrid analyst-sales-marketing role than the analyst in traditional RE feasibility study. Secondly; the use of a live scenario software demonstration in order to convince the client to buy into the PS may lead to increased perceived feasibility and reduced resistance to PS implementation. Thirdly; the assessment criteria that are used to estimate the effort and time needed for PS implementation are new features, level of customization, software ‘output’, and technical needs. Fourthly; the feasibility study for PS implementation differs strongly from traditional RE as the analyst mainly considers how to deal with requests for modifications to existing functions.

💡 Research Summary

The paper investigates how feasibility studies for packaged software (PS) implementation differ from traditional requirements‑engineering (RE) practices, especially in the context of small‑ and medium‑sized enterprises (SMEs). Recognizing that modern software projects increasingly rely on integrating off‑the‑shelf components rather than building systems from scratch, the authors argue that conventional engineering methods—such as strict structured programming and exhaustive test‑case collection—do not map cleanly onto PS projects. To explore this gap, an ethnographic field study was conducted within several packaged‑software development firms, focusing on real‑world SME deployments. Data were gathered through observations, semi‑structured interviews with analysts, salespeople, and clients, and analysis of project artefacts (proposal documents, implementation plans, and post‑mortem reports).

Four principal findings emerged. First, the analyst’s role in PS feasibility studies is a hybrid of technical analyst, salesperson, and marketer. Unlike the purely technical RE analyst, this hybrid must simultaneously elicit client needs, demonstrate product value, and negotiate contractual terms. Second, live‑scenario software demonstrations are employed early in the feasibility phase to reduce perceived risk and resistance. By allowing clients to experience the packaged solution in a realistic workflow, the demonstration raises the perceived feasibility of the project and creates a stronger buying commitment. Third, the criteria used to estimate effort and schedule diverge from classic function‑point or COCOMO‑style metrics. The study identifies four new dimensions: (1) New Features – the extent to which the client requires capabilities not native to the package; (2) Level of Customization – the depth of configuration, scripting, or interface extensions needed; (3) Software Output – the quality and format of deliverables such as reports, data exports, or UI/UX; and (4) Technical Needs – infrastructure compatibility, security policies, performance constraints, and integration requirements. These dimensions provide a more nuanced basis for cost‑time estimation in PS projects. Fourth, handling modification requests becomes the central concern of the feasibility study. Because packaged solutions are inherently less malleable than custom‑built systems, analysts must model the impact of each requested change on the package’s architecture, licensing, and upgrade path, then quantify the associated cost and schedule implications. The paper recommends a structured “modification impact assessment” that is communicated to the client to set realistic expectations and to negotiate scope limits.

Overall, the authors propose a re‑engineered feasibility‑study framework for PS implementation in SMEs that integrates sales‑oriented communication, experiential demonstrations, a revised set of effort‑estimation criteria, and a systematic approach to modification management. This framework aims to lower implementation risk, improve client acceptance, and increase project success rates. The study also highlights avenues for future research, including the development of quantitative models and decision‑support tools that embed the identified criteria and impact‑assessment processes, thereby enabling more objective feasibility evaluations for packaged‑software projects.