A manual system can be adequate for a small project with straightforward monitoring and clearly organised records. In my experience, it becomes risky when a project lasts several years, information comes from multiple people, or missing evidence is not discovered until verification.
What manual project data management actually looks like
I have worked across several types of carbon projects, but biogas and biomass projects are particularly useful examples of the challenges of manual data management. These waste-to-energy projects involve numerous monitoring parameters that must be collected and tracked consistently over long periods.
A lot of that information is still recorded manually on site. Some measurements can be taken directly, while others require additional processing. For example, testing chemical oxygen demand (COD) means taking a sample, sending it to a laboratory and waiting for the result. Other information, such as wastewater flow rates, may be recorded continuously by monitoring equipment.
Having monitoring equipment does not necessarily mean that the information is easy to use. When a consultant needs the data, it may be exported as a PDF. Records covering an entire year might also be provided as hard copies or scanned images.
The consultant then has to extract the relevant figures before they can be used in calculations or reports. That takes a lot of time, and it is only one part of the job.
The wider project documentation may be spread across emails, Google Drive and Google Docs. Project managers, advisers and other contributors need to review and shape the documents. Each person may add comments or create another version.
When the project reaches validation or verification, the validator or verifier may request changes and further supporting evidence. More comments and revised documents are added. What I have found is that the longer the project continues, the more documents there are to deal with and the more difficult they become to manage.
This matters because some projects take three or five years to develop. Over that length of time, managing files is not just an administrative task. It affects whether people can understand what happened, find the evidence and support the emission-reduction calculations.
When missing data has a real consequence
I have seen what happens when project records are physically vulnerable.
On one occasion, flooding affected a project site. Monitoring records were damaged or lost, and documents had to be moved elsewhere. We lost data for part of the monitoring period. As a result, the project could not claim the emission reductions associated with that period.
That is a very practical consequence. The problem was not that the project team did not understand the methodology. The evidence was simply no longer available.
There is another risk that can be less obvious. Something may go wrong with equipment or a process at the factory, and the project manager on site makes a change to fix the immediate operational problem. That decision may make perfect sense from the factory’s point of view.
However, the person making the change may not realise what it means for carbon-credit certification. A monitoring parameter may need to change, or additional information may need to be recorded. If that does not happen, the consultant may discover the gap only when preparing for verification.
By then, it may be too late to recreate the missing record.
This is why I think communication between the project owner, the site team and the consultant is so important. If the consultant can see a problem early, the team has a chance to address it straight away. Waiting until the next verification can turn a manageable issue into missing evidence that cannot be recovered.
The problem of staff changes
One issue that is easy to underestimate is staff turnover.
I have experienced this both at factory level and on the consultancy side. When someone leaves or moves to another role, the next person may not know where the former employee kept the data. They may not know the relevant folder, filename or document version.
They may also be unable to reconstruct earlier communication. Important context may be buried in one person’s email account or may have been discussed during a phone call. The new project manager can see the final decision but not why it was made.
For me, this is another sign that the problem is not only how much information a project produces. It is also whether that information can still be found and understood when the people involved change.
Managing the work in Thrive 2050
This is where I see practical value in managing the work through Thrive 2050. The main difference is the speed with which information can be brought together and reviewed.
A surveyor can collect information and upload it to Thrive 2050 rather than allowing it to remain in a paper record, scanned image or separate folder. When an input is updated, the connected calculations can also be updated. The consultant does not have to wait until the end of a full monitoring year before analysing the information.
That earlier visibility is important. In a manual system, completing the calculations repeatedly can involve enough work that they are left until verification is approaching. In reality, consultants often become closely involved again when verification time comes. If the data is incomplete, discovering the problem at that stage may be too late.
Keeping the project information and uploaded records connected in Thrive 2050 can also make it easier for another person to pick up the work. It cannot capture a conversation that nobody records, so people still need to document their decisions properly. However, it gives the team a clearer place to maintain the evidence used for the project and its calculations.
Using Thrive 2050 does not mean that the system decides whether the monitoring is correct. It makes the available information easier to review and the calculations quicker to update. A qualified person must still assess what the data means.
For example, a methodology and the project design document set out what must be measured and how it should be measured. If a piece of equipment breaks, the site may need to use a different monitoring method. Someone must then assess how far that change departs from what was proposed.
If the site changes how COD is measured, someone must assess whether the new method complies with the monitoring requirements and produces results that remain comparable with the earlier records. That requires technical knowledge and professional judgement.
When a manual system is still enough
I do not think every project must stop using spreadsheets and documents immediately.
A manual system can be adequate when a project is limited in scale, only a small number of people are involved, and everyone can find and trace the records. If the monitoring requirements are straightforward, the files are organised and responsibilities are clear, changing systems may not be the most urgent priority.
The difficulty begins when the project lasts for several years, information comes from different people and formats, or staff changes make the history difficult to follow. It also becomes risky when operational decisions on site can affect certification but the consultant will not see the data until much later.
My advice to a project developer would be to look beyond whether the current spreadsheet still works today. Ask whether another person could understand the project history, locate the supporting evidence and identify a monitoring problem in time to act.
If the answer depends on one employee’s memory, one folder or a collection of paper records surviving for several years, the manual system is no longer adequate. The purpose of changing it is not to remove professional judgement. It is to give the people making those judgements better access to the project information while there is still time to respond.