In this topic 6 sections
Keep several delivery options open
Translate confirmed requirements into alternatives before selecting a supplier. Existing systems may be improved through new reports, interfaces, configuration or targeted upgrades. Replacement may involve a purchased package, bespoke development or a combination. Outsourcing concerns who supplies or operates an activity; it can accompany either purchased or custom software.
| Option | Potential attraction | Question that could rule it out |
|---|---|---|
| Improve the present system | Preserve useful functionality and reduce disruption | Can it meet essential needs over the intended period? |
| Configure a package | Obtain established functions and supplier support | Will important processes fit without excessive customisation? |
| Develop a tailored system | Design around distinctive requirements | Are development, testing and maintenance capabilities available? |
| Use an external provider | Access skills or delivery capacity | Can service quality, data access and supplier dependence be managed? |
The 2020 UK Outsourcing Playbook treats delivery choice as an assessment of alternatives, including internal, external and mixed arrangements. Its general lesson is to compare capability, costs, benefits and risks before fixing the delivery model. It is historical public-sector guidance, not a rule for every business.
Concept sources: UK Cabinet Office, The Outsourcing Playbook, version 2.0, June 2020, section 3 — delivery-model assessment.
Consider remaining useful life and update history, not age alone. Delaying replacement can be sensible when requirements remain unsettled and continuing risks are understood.
Plan the work across the system life cycle
The systems development life cycle gives structure to work from initial need through operation and eventual replacement. It helps identify responsibilities, dependencies, time and cost. The detail varies with the project; iterative development can revisit stages as learning changes the design.
| Planning stage | Evidence needed before proceeding |
|---|---|
| Initiation and analysis | Agreed problem, requirements, alternatives and preliminary feasibility |
| Design or acquisition | Chosen solution, interfaces, controls and implementation approach |
| Implementation | Tested functions, validated migrated data and prepared users |
| Operation and maintenance | Performance evidence, support arrangements and controlled changes |
| Review and retirement | Decision to retain, improve or replace, with information preserved appropriately |
A build requires programming and detailed design; a package still needs selection, configuration, integration, testing and conversion. Buying software therefore changes the work rather than eliminating it. Security and control requirements should be considered during development, not postponed until installation.
Concept sources: NIST, SP 800-64 Revision 2, October 2008, section 2.1.1 — a historical life-cycle model. NIST withdrew this publication in 2019; it is used here for historical context, not current security requirements.
- Confirm requirements
- Compare feasible options
- Design or configure
- Test and prepare conversion
- Implement and support
- Review performance and future needs
Apply three feasibility tests
Feasibility is an early decision gate, not merely a document completed after a preferred product has been chosen. Reassess it when material assumptions change.
| Test | Central question | Evidence to investigate |
|---|---|---|
| Technical | Can the proposed solution work with available technology and capability? | Integration trials, capacity, reliability and specialist skills |
| Economic | Do expected benefits justify all relevant costs and risks? | Whole-life estimates, alternative uses of resources and sensitivity |
| Operational | Can the organisation adopt and use it effectively? | Workflow fit, staffing, training, ownership and user acceptance |
Concept sources: Information Systems for Business and Beyond, First Canadian Edition, 2022, section 7.5 — economic, technical and operational feasibility.
A technically possible project can be uneconomic; attractive forecast savings can fail through poor adoption. Explain the evidence and conditions required before approval.
Select criteria that reflect ERP objectives
An enterprise resource planning system can integrate activities and information across functions. Specify the intended outcomes before scoring products: for example, fewer duplicate entries, more reliable availability information or faster reconciliation. A supplier's list of modules does not show that those outcomes will occur.
Evaluate the scope needed, fit with business processes, adaptability, interfaces, reporting and analytical capability. Examine the skills required from staff and support providers. Consider whether additional modules can be introduced later and whether customisation will complicate upgrades or make support dependent on scarce expertise. Check supplier capability through relevant evidence, including demonstrations against agreed requirements.
GAO's framework supports criteria that reflect organisational goals and balance benefits, costs and risks. Agree priorities and minimum requirements before comparison. A high overall score should not conceal failure of an essential requirement.
Concept sources: GAO, Information Technology Investment Management, March 2004, “Defining the Portfolio Criteria” — selection factors, thresholds and relative importance.
Prevent specification and selection errors
Requirements can grow because every possible report appears useful. Ask what decision each output supports, who will use it and how often. Transaction detail may be necessary for investigation, while summaries and exceptions are more useful for routine management. Retaining access to detail does not require putting every transaction on the main report.
Rejecting a request needs explanation: distinguish a low-value enhancement from an essential control or genuine information gap. Avoid treating the cheapest purchase price as the lowest total cost. Configuration, integration, conversion, internal staff time, training, support and later changes can materially alter the comparison.
Trace requirements to proposed features and acceptance tests. Use demonstrations involving users' realistic work. Record unresolved gaps and their owners, making selection reviewable and defining success for implementation.
Sources and further reading
- Cabinet Office, June 2020 Outsourcing Playbook: section 3 on delivery options.
- NIST, October 2008 life-cycle publication: historical development stages.
- NIST publication status: withdrawal on 31 May 2019.
- GAO, March 2004 investment framework: criteria aligned with business needs.
- First Canadian Edition, 2022: section 7.5 on feasibility; maintained publisher edition.