IT Project Audit: Method, Deliverables and Cost

The application still runs, but every release feels risky. The original supplier replies slowly. Tests are incomplete. A full rewrite looks as dangerous as it is expensive.

In that situation, the first decision should not be which framework to use next. You need facts. An IT project audit explains what works, what blocks delivery and what is reasonable to do next.

A useful audit does more than produce a technical score. It should help management choose whether to repair, stabilise, recover gradually, rewrite selected parts or stop.

What is an IT project audit?

An IT project audit is a bounded review of software and the way it is built, released and operated. It connects three realities:

• the business need that was agreed;
• the system that actually exists;
• the team’s ability to change it safely.

It is not only a source-code audit. A clean repository can still depend on one person for deployment. An older application can remain dependable when critical paths are tested, documented and monitored.

The review should cover the full path from business request to code, data, security, deployment, production incidents and operating cost.

Seven signs that an audit is needed

1. Delivery dates no longer mean anything

Every estimate slips. One fix opens three more problems. Developer speed may not be the issue: scope, dependencies or acceptance may have become impossible to read.

2. Only one person can release

If one absence stops every deployment, the project carries an immediate risk. Access, pipeline, rollback and manual steps need to be mapped.

3. The same incidents keep returning

A patch without root-cause analysis calms production but does not stabilise it. Repeated incidents often expose missing tests, poor logs or unclear ownership.

4. The business works around the software

Users return to spreadsheets, email files or enter the same data twice. The product may be technically online while no longer supporting the real work.

5. Maintenance cost cannot be explained

Invoices grow without a readable backlog, service level or separation between fixes, enhancements and operations. Useful application maintenance should make run cost easier to understand.

6. You are preparing to change supplier

Changing teams without a map only moves the problem. An audit prepares access, knowledge and priorities before handover.

7. Someone proposes a full rewrite

A rewrite can be justified, but it needs an observed reason: security that cannot be repaired, unsupported technology, an architecture that cannot carry the business or a change cost that has become unreasonable.

• RepairThe foundation holds. A few specific blockers prevent delivery.
• StabiliseTests, deployment, monitoring and documentation before more features.
• RecoverOne business path at a time, without replacing the entire system in one cutover.
• Rewrite or retireOnly when evidence shows that keeping it costs more or preserves unacceptable risk.

What the audit should examine

The business need

Which journeys must work? Who accepts a release? What workarounds do teams use today? Without these answers, a review can optimise software that nobody needs.

Architecture and code

The goal is not to grade every file. It is to identify active components, critical dependencies, dead code, unsupported versions and areas where a small change becomes dangerous.

A technical review should answer a practical question: can a new developer understand where to work without relying on one gatekeeper?

Data and access

Where is data stored? Who can read or change it? Are former employee accounts closed? Are secrets stored safely? Can backups actually be restored?

When GDPR or sovereignty requirements apply, hosting region and remote access must be agreed with the client. A vague “European cloud” statement is not enough.

Testing and acceptance

You do not need thousands of tests. You need protection around paths that are expensive when they fail: sign-in, orders, payments, calculations, imports and transfers to another system.

The audit also checks who performs acceptance and in which environment. Automated tests without a business owner do not prove that the right behaviour is covered.

Deployment and production

How does a version reach production? Can it be rolled back? Are environments separated? Can logs explain an incident? Is basic monitoring in place?

An application is not reliable because it was deployed once. Another authorised person must be able to repeat the operation safely.

Organisation

Who owns the product? Who decides scope? Who responds to an incident? Where is the documentation that matters? Sound architecture cannot compensate for decisions nobody can make.

Operating cost

The audit should separate:

• hosting and third-party services;
• corrective maintenance;
• enhancements;
• monitoring and intervention;
• licences;
• manual operations still required around the software.

There is no perfect number. An explainable estimate is already more useful than an opaque monthly fee.

Deliverables you should require

A fifty-page report is not automatically useful. Management should leave with working material:

1. A short system map covering applications, data, dependencies, environments and owners.
2. A ranked risk list with impact, likelihood, urgency and proposed action.
3. Immediate decisions such as closing access, testing a backup, freezing a release or treating an incident.
4. A 90-day plan with work order, expected outcome and owner.
5. Build and run estimates for recovery and ongoing operation.
6. A clear recommendation to keep, repair, recover, replace or retire.

Every recommendation should point to an observed fact. “Modernise the stack” is not a decision. “This version no longer receives security fixes and blocks the next upgrade” is.

How much does an IT project audit cost?

Cost mainly follows scope:

• one application or several;
• one accessible repository or scattered code;
• documented or unknown production;
• available or missing contacts;
• a technical review alone or business, security and run analysis as well.

Ask for a fee tied to deliverables, not an open number of days. The provider should state what is included, which access is needed and which conditions could expand the scope.

At IT Empower Solutions, most fixed-price IT assessments stay under €2,000. A multi-application landscape or difficult access can exceed that range. We say so before starting.

How long should it take?

A standalone application with a clean repository and available contacts can be reviewed in a few days. Several connected applications, missing documentation and slow access require longer.

Duration should not be reduced to make a proposal look attractive. Ask when urgent decisions will be available and when the complete action plan will be delivered.

Repair, recover or rewrite?

Repair when the system remains understandable and a small number of identified defects block delivery.

Stabilise and maintain when the application still serves the business but testing, deployment or monitoring is fragile.

Recover gradually when some parts hold and others need replacement. Protect one journey, release it, then move to the next.

Rewrite when the current foundation cannot be secured or maintained at an acceptable cost. The decision must include data migration, temporary coexistence and rollback.

Retire when a component is barely used, expensive and duplicated elsewhere. Not every system deserves another delivery team.

Our article on recovering a stalled IT project covers what comes next when recovery is the right decision.

Mistakes that make an audit useless

• Looking for someone to blame instead of establishing facts.
• Reviewing code without speaking to the business.
• Giving full administrator access when read access is enough.
• Confusing technology preference with real risk.
• Producing a hundred recommendations without priority or owner.
• Promising a rewrite before measuring the existing system.
• Ignoring the operating cost of the proposed solution.

A useful audit reduces uncertainty. If it leaves management with more jargon and no decision, it has failed.

Checklist before opening access

• NDA signed when needed.
• Written scope and deliverables.
• Read access to the code repository.
• List of environments and third-party services.
• Existing documentation gathered, even when incomplete.
• Business and technical contacts identified.
• Temporary, named and limited accounts.
• Production access avoided or logged when essential.
• Review date agreed.
• Action-plan format accepted.

The purpose is not to make the project perfect in one week. It is to replace assumptions with a map, priorities and a decision the team can execute.