technical audit of the IT project

technical audit of the IT project

35 questions for a quick assessment of the quality of an IT project.

I’m doing the audit

Hello Habre! There are situations in life when it is necessary to assess the quality of the project at once by all articles. You can order an external audit, or you can check everything yourself using the following guide.

I have a bachelor’s degree in Applied Computer Science (Enterprise Information Systems) and 6 years of experience in web development, so I’ve put together this checklist (which you’ll find at the end) with a 100-point system that will give you a good idea of ​​the quality of the project. The material is more suitable for fresh projects, although it can also be useful for stale ones.

I divided the article into subsections of the check with a brief description of the criteria. Perhaps you will find insights in them and delve deeper into a topic.

  1. Requirements and obligations

First of all, we study the requirements from the customer – the main deadlines for submitting/rolling out features. We check obligations to organizations, if there is accreditation (conditions for obtaining/supporting). We write out all control dates.

Here we check the requirements documentation – a description of the system processes. Ideally BPMN/Activity/IDEF0. Why? The graphic way of presenting information is the fastest to understand, and the popular notations are understandable to everyone and unambiguous in interpretation.

  1. Development methodology

It is important to check the presence of the development methodology: its presence indicates the organization of the process. Lack of methodology in large teams predicts problems, although small projects can get by with close communication. There are many methodologies that suit everyone’s desire. Examples of popular methodologies:



What to check


Iterative and highly flexible methodology. Aimed at adapting to changes.

In the processes – sprints, daily, planning, retrospectives are possible.


Agile implementation option, the most popular methodology. The same principles, a little more structured

In Scrum, important roles (Scrum Master, Product Owner, Team), artifacts (Product Backlog, Sprint Backlog) and Events (Sprint Planning, Daily Scrum, Sprint Review, Retrospective)


Talk less and work more.

There should be a focus on customer value, feedback should influence development as soon as possible


Suitable if there are VERY clear end requirements. At the beginning, a development plan with deadlines is built.

There should be clear adherence to the plan, there should be a plan in general, clear documentation


A product prototype is quickly created and then refined until an acceptable result is obtained.

Must be a product version, well user tested and quick to adapt.

  1. Project management system

A project management system is required, preferably Jira/Redmine/Trello/Asana/Microsoft Project.

Agile needs a task board of the current sprint with testing, Waterfall needs a Gantt chart. A backlog of tasks is important. In Agile/Scrum, tasks should be structured (Epic > Story > Tasks + Test execution).

A clear description and title of the task, indication of testing and attachment of commits for integration with the repository are important.

Here we check the terms from point 1. Perhaps the plans will be in another system, this is not a problem. Check the compatibility of plans and risks. Obviously, if there is a discrepancy, something needs to be changed.

  1. Repository

We look at the branches in the project, behind them the git flow will be clear. It is bad if there are few branches – only master and develop, for example. Features should be developed in separate branches, they should be.

Next, we go to Merge requests. There should be:

  • Normal description

  • The task number must be specified in the commits, without this the code will turn into hell in a couple of years, you will not find the ends

  • There should be discussions, at least in large MRs, Approves – otherwise arbitrariness

  • Pipeline – must be. In the tests – assembly, linter, tests (+ deployment result, static analysis if desired)

  1. The composition of the team

There are many options, but a good basic one is this:

  • front end

  • backend

  • designer

  • the product

  • the project

  • the tester

  • devops

If the team is incomplete, something will sag. If there is no separate frontend and backend, the code may be of low quality. Without a designer, it will look like a collective farm. Without a product – there is no development plan (if it is a waterfall with a ready-made plan). Without a project, there will be chaos in development. Without testers – there will be bugs, without devops – the system will be unstable.

  1. Releases and environment

Regardless of the stage of the project, there must be a plan. The biggest standard for environments – dev, prod, stage. Releases should have a plan – Git flow, Continuous Deployment.

There should also be a plan for managing hotfixes and emergency releases to ensure stability and business continuity in the production environment.

  1. Deployment

If you do have devops, you should first look at the deployment diagrams. Here it is worth evaluating whether docker or other containerization tools are needed, as well as applications for orchestrating containerized applications (k8s, etc.). It is especially relevant for several environments, if you want automatic deployment (for example, to avoid errors when deploying the next environment) and in general for large applications, microservice architectures.

  1. Testing

Here we are talking about testing separately from development. In my experience, the most important thing here is exploratory testing. Because the developer himself can check the tasks after completion with the help of his developer friends, but you cannot check the intervals between the tasks. Some things just need to be pushed by hand sometimes. And this, in my opinion, is the most important thing. Of course, the best option is when there is both manual and automated testing, but even when it is only manual, it is already good.

Load testing will also be a plus.

  1. Code

First of all, modern technologies should be chosen. In order not to offend anyone, let’s say this: the versions of frameworks, libraries, interpreters/compilers should not be old, they should correspond to modern trends. Example (February 2024):

PHP 8 is the norm, PHP 7 is obsolete.

Node 16 is normal, Node 13 is obsolete.

If there is an examination – you can check whether the architecture is in the application and whether it is modern.

There must be tests.

Check any file – how readable it is, whether there are comments. If there is expertise, you can look deeper (SOLID, design principles).

Are there linters?

If the frontend must be indexed, SSR is highly desirable.

Documentation – how the program is arranged. I prefer class diagrams (in general, I like all UML diagrams), but other popular ways of presenting information will also work.

  1. Technical compliance

Technical compliance: here, ensure compliance with data storage requirements, use of cookies with warning and user consent, fulfillment of requirements of partner companies (for example, such as mandatory logging of transactions).

Security: Vulnerability testing and code scanning for potential threats (you can make a report directly in Gitlab or use other tools).

Logging: Having a monitoring and logging tool would be very useful. For example, Sentry. This will be very useful when the product is released to users and incomprehensible errors are thrown.

Performance: Load speed and system response tests, especially important for the frontend.

Compatibility with browsers and devices: a cursory check of display and functionality on different devices and browsers.

Accessibility and SEO: Make sure the product is accessible to users with disabilities, do SEO checks or check the report

  1. Summary table




There is documentation of processes


There is a development methodology


The methodology corresponds to the description


There is a project management system


The project management system corresponds to the methodology


Features are structured by epics and stories


The description of tasks is complete and clear, with the scope of testing


There is integration with the repository


The plans for the SUP meet the requirements


Repository – there are features of branches


MR – full description


MR – the task number is indicated in the commits


MR – there are discussions and approvals


MR – there is a pipeline


MR – the pipeline has assembly, linter, tests


The composition of the team is complete


There is a release plan


There is a Continuous Deployment plan


There is a plan for managing hotfixes and emergency releases


There are deployment charts


The deployment corresponds to the complexity of the project


There is manual testing


There is a self-test


There is load testing


Code – new technologies


Code is architecture


The code is readable and complies with design principles


Code – there are linters


Code – there is documentation


Technical compliance – fulfilled legal obligations (logging, warnings, security requirements)


There is an error logging system


Security – a minimum of potential threats


Performance – fast loading and response


Works in the right browsers


Accessibility and SEO



Thanks to everyone who read to the end! I hope this material was useful to you. Share your project review criteria!

Related posts