Data work in software is like any other software work. One thing critical to do is to make sure that all of the code you write is in source control.
This can help in several ways. First, if you need to change something already on production, you have a starting point. Second if an employee goes out on vacation or emergency leave or gets seriously ill (they shoudl be checking into a personal branch daily at a minimum), you have a record of what he or she was working on for someone else to use to continue the project. Third, the code can also often be used as starting point for new projects. Fourth, it makes it easy to code review everything and it ensures that only the official version is sent to production as none of your researchers should have direct rights on the production databases and code they write to query it should always be pushed by someone else for security reasons. Finally, if it is organized by type of project, you can look at what was checked in to see what lines of research have been worked on. Since alot of things won;t work out, I would suggest that all lines of research get checked in and that you havea separate location for deployments of things that are approved to go to production. Source control can also store documents as well as code. We put reuirements in there and some othere documents. IN your case, again , it is agood way to store onformation you collected for reseaech where others can see it and know what you did and did not do.
Another critical item is that all code should be code reviewed. We review 100% of all code here including any database imports/exports/reporting queries/ analyses/changes. This ensures all are familar with more than their own code. IT helps people see different ways of approaching problems and learn new techniques and it catches a lot of errors before they go into production.
Jira can work fine as a ticketing system. What is critical though is that no one on the team including yourself, start to work on something that does not have a ticket. Ticketing systems are only as good as your willingnees to use them. YOu have to mdel good habits to your subordinates and you have to make sure they are not allowed to circumvent the system.
AS far as managing projects, generally I prefer to havea daily meeting where everyone says their progress and tell what they are planning to do. You might make it twice a week if you think daily is too intrusive. Meeting should not cover how to fix problems just state what roadblcoks they have run into and you can then get together with just the people involved in fixing the roadblock after the meeting. I recomment you spend no more than five minutes on each person's status in the status meeting and anythign that needs more depth be put off until after and then only includes the people directly affected.
Another thing to realize is that getting rid of their roadblocks is now more critical than any direct data analyses you want to do. You should never be assigned to the mroe ciritical taks becasue you will be frequently pulled off to make sure others can keep going.