The acquisition and development of information systems represent a critical strategic juncture for modern enterprises, serving as the primary mechanism through which business objectives are translated into tangible technological capabilities. The academic and professional literature on Information Systems (IS) acquisition and development emphasises a structured, risk-aware approach to ensure that IT investments deliver verifiable value, maintain strict alignment with corporate strategy, and embed robust controls from inception. As digital transformation accelerates globally, the way we manage these processes has changed. We're moving from rigid, prescriptive compliance models to strategic, resilient frameworks that can handle extreme environmental turbulence.

Evolution of IT Governance and Project Management

The foundation of any successful information system initiative lies in robust project governance and management. The scientific output on IT governance from 1999 to the present demonstrates a clear progression, marked by distinct phases of growth and a shift in thematic focus. Research indicates moderate growth until 2008, followed by a pronounced surge in publications through 2013, and a sustained stabilisation period thereafter. The literature reveals that early studies were predominantly descriptive, whereas contemporary research reflects a mature, multidisciplinary field capable of adapting to emerging global challenges.

A significant inflexion point in this evolutionary trajectory occurred in 2020 due to the COVID-19 pandemic, which highlighted the need for adaptive, resilient governance models. When traditional corporate mechanisms proved insufficient during the crisis, agile IT governance played a critical mediating role in organisational responsiveness. Furthermore, modern governance frameworks are increasingly integrating the Sustainable Development Goals (SDGs) and linking IT performance to social and environmental value creation, reflecting the rise of "green governance".

In this governance context, effective project management is the coordinated application of activities to direct and control the accomplishment of agreed objectives, continuously constrained by budget, duration, and deliverables. Organisational structures significantly influence the effectiveness of project management. The literature categorises these structures into three primary models :

• Functional-structured organisations, where the project manager holds limited formal authority, and work is distributed across traditional, siloed departmental lines.

• Project-structured organisations, which grant the project manager formal authority over team members, budgets, and schedules, fostering dedicated focus.

• Matrix-structured organisations, where management authority is shared between the project manager and functional department heads, necessitate delicate stakeholder management and communication strategies.

Critical success factors in project governance consistently emphasise the formal appointment of a competent project manager with a high level of authority. Additional factors include clearly defined, measurable project goals; an experienced project team; and visible, unwavering support from top management. The literature underscores the necessity of clearly defined roles to ensure accountability, identifying several key entities :

• Project Steering Committee: Provides overall strategic direction, ensures alignment with the broader business strategy, and assumes ultimate accountability for the project's success.

• Project Sponsor: Champions the project at the executive level, secures necessary funding, and resolves high-level organisational roadblocks.

• Project Manager: Manages day-to-day operations, tracks progress against the baseline schedule and budget, and mitigates immediate operational risks.

• Quality Assurance (QA): Maintains strict organisational independence from the project manager to objectively assess project deliverables, code quality, and adherence to methodologies.

• Project Management Office (PMO): A permanent structural entity aimed at improving project and program management quality. The PMO maintains the project portfolio database, standardises methodologies, and supports resource allocation, though it does not focus on specific project content.

In the context of program management—where multiple closely linked projects are managed concurrently to achieve common strategic objectives—the inherent risks and durations are substantially higher. Governance mechanisms in this area must ensure high-quality decisions, allocate resources efficiently, and balance value creation, risk mitigation, and regulatory legitimacy. Using frameworks such as COBIT 2019, the Digital Trust Ecosystem Framework (DTEF), and the Project Management Body of Knowledge (PMBOK) helps align project management practices with enterprise IT governance, ensuring capital investments deliver the best financial returns.

Business Case and Feasibility Analysis

Before an enterprise commits financial and human resources to a system development or acquisition project, a comprehensive business case and feasibility analysis must be conducted and formally approved. The business case provides the essential informational foundation required for executive leadership to decide whether a project should proceed. It meticulously describes the business rationale, expected benefits, and justification for initiation, ensuring that the project is not pursued merely for technological novelty but for verifiable strategic value.

The feasibility study is a multi-phase evaluation that assesses the practical viability of the proposed solution. The academic and professional literature breaks this evaluation down into several critical, sequential components :

• Project Scope Definition: A clear, concise, and unambiguous definition of the specific business problem or opportunity to be addressed.

• Current State Analysis: An exhaustive evaluation of the existing legacy system to determine if it is functioning correctly, requires targeted modification, or necessitates complete replacement.

• Requirements Definition: A rigorous definition of project requirements based on diverse stakeholder needs, regulatory and compliance constraints, end-user functional necessities, and technical architectural attributes.

• Approach and Alternative Evaluation: The definition of a specific course of action to satisfy the requirements, including the identification of all viable alternatives (e.g., build versus buy) and the strategic rationale for selecting the preferred solution.

• Economic and Technical Evaluation: An examination of the cost-effectiveness of the project, including estimated total costs, resource availability, compatibility with existing enterprise architecture, and detailed project schedules.

• Formal Review: Formalised checkpoints designed to validate the completeness and accuracy of the study, culminating in a definitive go/no-go decision by the steering committee.

From an IS audit perspective, the auditor's role during the business case development phase is to review the criticality of the business requirements, independently determine if existing systems could achieve the desired outcomes more efficiently, and assess the objective reasonableness of the chosen solution. The auditor must ensure that all anticipated benefits are verifiable, realistic, and accurately reflect the projected costs, thereby preventing the authorisation of projects based on inflated ROI projections.

System Development Methodologies (SDLC)

The System Development Life Cycle (SDLC) provides the foundational structural framework for systems engineering and software development. The current literature presents a comprehensive, ongoing debate regarding the optimal application of traditional, heavy-weight approaches versus modern, light-weight methodologies.

The traditional Waterfall model is a linear, sequential approach in which each distinct phase—planning, requirements definition, design, implementation, testing, and maintenance—must be formally completed and signed off before the next phase begins. This methodology is highly praised for its clear milestones, thorough documentation, and predictable timelines. The literature indicates that the Waterfall model remains highly effective in environments with well-defined, stable requirements, such as core Enterprise Resource Planning (ERP) systems, where reliability, strict auditability, and clear traceability of financial transactions are paramount. However, the literature also notes significant structural drawbacks: the Waterfall model lacks inherent flexibility, making it exceedingly difficult and costly to adapt to changing risk priorities or shifting business requirements discovered late in the development cycle.

In response to the rigidities of the Waterfall model, Agile methodology emerged as a dominant alternative. Agile emphasises flexibility, cross-functional collaboration, iterative development cycles, and continuous user feedback. Agile methodologies—encompassing frameworks such as Scrum, Kanban, and eXtreme Programming (XP)—allow organisations to dynamically adjust their focus in response to changing risk landscapes and market demands. This adaptability is particularly valuable in rapid digital transformation initiatives, web-based application development, and consumer-facing platforms. However, Agile introduces unique challenges from an IS audit and governance perspective. The rapid pace of modifications, historically decentralised documentation, and iterative prototyping can complicate formal change control, making it difficult for auditors to trace specific requirements to tested code. To address this, the literature advocates for "agile auditing," which incorporates a risk-based perspective, allowing auditors to align their evaluations with iterative development cycles dynamically.

Recent academic literature extensively highlights the specific complexities of the SDLC in Global Software Development (GSD) environments. GSD leverages distributed engineering teams across multiple geographic time zones to increase productivity, enable 24/7 development, and reduce labour costs. However, this structural dispersion introduces severe communication barriers and deeply complicates Requirement Engineering (RE). Changes in requirements—particularly at the detailed design level—can severely impact project duration and escalate costs across distributed teams. Effective change management in GSD requires rigorous impact analysis, continuous stakeholder communication, and tools like the Analytical Hierarchy Process (AHP) to prioritise requirements and manage divergent stakeholder expectations across cultural boundaries.

Research indicates that changes to requirements should be categorised by granularity to manage them effectively in distributed environments. Studies categorise requirements into four levels: system-level (Level 1), component-level (Level 2), sub-component-level (Level 3), and design-level (Level 4), with empirical evidence indicating that the design level experiences the highest frequency of changes.

Regardless of the overarching methodology selected, the literature standardises the SDLC into several core, universally applicable phases :

• Phase 1: Feasibility Study, which defines the timeframe, determines the optimum alternative, and evaluates the cost of development versus acquisition.

• Phase 2: Requirements Definition, which identifies user interactions, operating conditions, and security, privacy, and governance constraints.

• Phase 3: System Acquisition and Design, which develops a detailed logical and physical design based on requirements, illustrating data flow, defining inputs and outputs, and establishing comprehensive test plans.

• Phase 4: Configuration or Development, which involves actual coding for in-house systems or parameter configuration for acquired systems, heavily supported by strict change management policies to ensure "security by design."

• Phase 5: Final Testing and Implementation, where the operation of the system is established in test environments, full-system tests are executed, and migration to the production environment is authorised.

• Phase 6: Post-Implementation Review, which ensures the deployed system meets the original business objectives and that all designed controls are operating effectively.

Infrastructure Development and Software Acquisition Practices

If an organisation decides, through a feasibility study, to acquire a commercial off-the-shelf (COTS) system rather than build a bespoke solution, the acquisition process must be carefully managed. This governance maximises ROI, ensures cost transparency, and guarantees integration with the existing enterprise architecture. The literature emphasises that the acquisition process must start with a formally defined business need and be followed by a rigorous, objective evaluation of multiple competing vendors.

The Request for Proposal (RFP) serves as the cornerstone of the formal software acquisition process. A well-constructed RFP must precisely delineate product and system requirements, demand empirical evidence of product scalability and interoperability, and explicitly outline security, privacy, and compliance expectations. Furthermore, the RFP process should evaluate the vendor's long-term financial viability, audit their customer references, negotiate the availability of source code (often using software escrow agreements to protect the purchasing organisation in the event of vendor bankruptcy), and scrutinise the vendor's post-implementation support structures. IS auditors play a critical oversight role during this phase by reviewing the RFP to ensure that all security and governance requirements are addressed and that the acquisition process adheres to internal procurement policies.

Evaluating vendors extends significantly beyond simply reading RFP responses. The literature recommends a phased, empirical approach including architecture workshops, proof-of-concept demonstrations, and objective, data-driven evaluations of system capacity, throughput, turnaround time, and response time under simulated loads. The strategic decision between cloud-based and on-premises infrastructure is a pivotal consideration during vendor selection. Cloud solutions offer superior scalability and are highly beneficial when internal IT resources are scarce. In contrast, on-premises solutions may be mandated when absolute data sovereignty, physical control, and extreme security are the highest organisational priorities.

Control Identification and Design

A fundamental objective of information systems development is the early identification and integration of application controls. The literature emphasises that controls must be architected into the system during the design phase rather than bolted on post-development. Application controls ensure that data remains accurate, complete, valid, verifiable, and consistent as it traverses the digital ecosystem.

These controls are broadly categorised into three distinct operational areas :

• Input/Origination Controls: These mechanisms are designed to ensure that only authorised, complete, and valid data is entered into the computer system. Techniques encompass batch controls, mathematical balancing, data validation routines, and automated editing procedures that reject erroneous formats before they enter the database.

• Processing Controls: These procedures ensure that the system accomplishes the correct tasks and maintains data integrity during manipulation. They include data file control procedures, sequence checks, logical processing validations, and run-to-run totals.

• Output Controls: These procedures verify that processing results meet expectations, reports are accurate, and sensitive output is distributed exclusively to authorised personnel.

The literature shows that a comprehensive risk assessment during the design phase is essential to identify potential threat vectors. For instance, in developing web-based payment systems, a layered defence strategy is required. Preventive controls (such as secure coding practices and data-in-transit encryption), detective controls (such as continuous vulnerability scanning, penetration testing, and intrusion detection systems), and corrective controls (such as automated patch management and formalised incident response plans) must be seamlessly integrated into the application. The auditor's responsibility during this phase involves reviewing logical system flowcharts, assessing the cryptographic adequacy of audit trails, verifying the integrity of key mathematical calculations, and ensuring that appropriate stakeholder approvals were obtained for all system design changes