IS Acquisition & Development: Common Mistakes
Skipping feasibility studies before system acquisition.
A feasibility study evaluates whether a proposed system is technically viable, economically justified, and operationally practical. Without it, organizations may invest in systems that do not meet their needs, exceed budgets, or introduce unnecessary complexity.
Correct approach: Conduct a thorough feasibility study covering technical, economic, operational, and schedule factors before committing to any acquisition or development effort.
Assuming the waterfall model is always the best SDLC approach.
The waterfall model works well for projects with stable, well-defined requirements, but it is inflexible when requirements evolve. Agile, iterative, and spiral models may be more appropriate for projects with uncertain or changing needs.
Correct approach: Select the SDLC methodology based on project characteristics such as requirement stability, complexity, timeline, and stakeholder involvement.
Treating user acceptance testing (UAT) as optional.
UAT is the final validation that the system meets business requirements. Skipping it means the organization deploys a system without confirmation that it works as intended from the end user's perspective. Defects discovered after deployment are far more costly to fix.
Correct approach: UAT is mandatory before production deployment. Business users should formally sign off that the system meets their documented requirements.
Allowing developers to migrate code directly to production.
Separation of duties requires that developers do not have access to promote code into production environments. This control prevents unauthorized or untested changes from reaching live systems. Violating this principle increases the risk of fraud, errors, and system instability.
Correct approach: Establish a formal change management process where an independent team or individual handles production migration. Developers should only have access to development and testing environments.
Confusing verification with validation in software testing.
Verification checks whether the system was built correctly according to specifications ("Did we build it right?"). Validation checks whether the system meets the actual business needs ("Did we build the right thing?"). Mixing these up leads to incomplete testing strategies.
Correct approach: Perform verification activities (reviews, inspections, walkthroughs) throughout development. Conduct validation activities (UAT, beta testing) to confirm the system satisfies business requirements.
Neglecting regression testing after changes are applied.
Changes to one part of a system can introduce defects in previously working functionality. Without regression testing, these side effects go undetected until they cause problems in production. This is especially critical in complex, integrated environments.
Correct approach: Perform regression testing after every change, patch, or update to confirm that existing functionality remains intact. Automate regression tests where possible.
Failing to include rollback procedures in the change management plan.
Not every change succeeds, and without a documented rollback plan, a failed deployment can cause extended downtime or data loss. The organization must be able to revert to the previous stable state quickly and reliably.
Correct approach: Document and test rollback procedures as part of every change request. Include criteria for triggering a rollback and assign responsibility for executing it.
Overlooking data conversion and migration risks.
Data migration from legacy systems to new platforms is a high-risk activity. Data can be lost, corrupted, or incorrectly mapped during the process. Without proper planning and validation, the new system may operate on inaccurate data.
Correct approach: Plan data migration carefully, including data mapping, cleansing, and validation steps. Perform trial migrations and reconcile results before the final cutover.
Assuming that purchasing commercial off-the-shelf (COTS) software eliminates development risk.
COTS products still require configuration, customization, integration, and testing. Vendor lock-in, lack of source code access, and dependency on vendor support introduce their own risks. The total cost of ownership often exceeds the initial purchase price.
Correct approach: Evaluate COTS products with the same rigor as custom development. Assess integration requirements, vendor viability, licensing terms, and long-term support before acquisition.
Not involving the IS auditor early enough in the SDLC.
Auditor involvement from the early stages of system development allows control requirements to be built in rather than added after the fact. Late auditor involvement often results in costly rework or acceptance of inadequate controls.
Correct approach: Involve the IS auditor during the requirements and design phases. The auditor should review control specifications without compromising independence by designing the controls themselves.