A useful software business case connects a proposed change to measurable work. For a geotechnical laboratory, that means understanding how much effort is spent preparing records, processing supported tests, producing reports and resolving corrections. A license price is only one part of the decision. The organization also needs to know what changes in daily work and how the benefit will be realized.
This guide explains how to build a GDMS business case using your laboratory’s own evidence. The numerical example is deliberately hypothetical and is not a customer result, price quotation or promised saving. Replace every assumption with measured information before using the calculation for a purchase or implementation decision.
Define the workflow being evaluated
GAEA describes GDMS as software for supported geotechnical laboratory measurements, calculations, engineering curves and reports linked to project and sample records. Evaluate the specific test workflows your laboratory needs. Confirm methods, outputs, access arrangements and any required integration rather than assuming that every laboratory activity is included.
Choose a clearly bounded process for the business case. For example, follow accepted measurements through calculation, review and report issue for a defined group of tests. Identify what remains unchanged, such as physical specimen preparation and measurement procedures. Crediting the software with reducing unrelated laboratory work would inflate the estimate and make the result difficult to defend.
Map the current process before timing it
List the actual steps: locate the sample record, enter measurements, check calculations, create a curve, format the report, obtain review and file the issued result. Include transfers between worksheets or applications. Ask operators and reviewers to describe exceptions as well as the ordinary case. Workarounds often consume time that is absent from a formal procedure.
Identify repeated entry separately from necessary technical work. Copying a project name into three files is different from checking whether a specimen measurement is reasonable. The business case should target avoidable handling while preserving the review needed for reliable results. A shorter process is not an improvement if it simply removes a required quality check.
Establish a representative baseline
Measure several ordinary jobs across relevant test types and staff members. Record the task, volume, time and notable circumstances. Separate waiting time from active staff effort. A report delayed while a reviewer is unavailable may have a long turnaround without consuming an equivalent number of labor hours. Both measures matter, but they answer different questions.
Use a consistent definition of a completed report. If the current timing stops before review but the proposed timing includes approval and filing, the comparison is unfair. Include normal corrections in the baseline or record them separately with their frequency. Avoid selecting only unusually difficult historical jobs to make the proposed change appear more favorable.
Measure the proposed workflow through a pilot
Test representative records with the intended GDMS configuration and trained users. Include routine examples, an exception and a revision request. Compare output content and selected calculations independently. The pilot should demonstrate that the required result remains correct and reviewable before its timing is used in a financial model.
Record learning and configuration effort separately from repeatable production time. A specialist demonstration may be faster than normal operation, while a first attempt by an untrained employee may be slower. Use a realistic assumption about performance after agreed training. Explain the evidence and remaining uncertainty rather than presenting a single timing as universally achievable.
Calculate time released from comparable tasks
A simple starting formula is annual hours released equals the number of comparable reports multiplied by the reduction in minutes per report, divided by sixty. Use separate calculations for workflows with materially different effort. A weighted average can be useful, but its underlying volumes and timings should remain available for review.
For illustration only, assume a laboratory completes 1,200 comparable reports annually. Suppose the current administrative and reporting effort averages 24 minutes per report, and a tested alternative averages 16 minutes. The assumed reduction is eight minutes. Multiplying 1,200 by eight and dividing by sixty gives 160 hours of annual capacity released.
Those figures do not establish that GDMS will produce that result in your laboratory. They demonstrate the calculation. If your pilot shows a smaller reduction, use it. If some reports are outside the tested scope, exclude them or model them separately. The strength of the business case comes from credible assumptions rather than a large percentage.
Translate capacity into an appropriate value
Using a hypothetical loaded labor cost of $50 per hour, 160 hours represents $8,000 of annual labor capacity. The currency is unspecified for this example; use a consistent currency and an organization-approved rate in your own model. A loaded cost may include employment overhead, but it should not be confused with the laboratory’s selling rate.
Capacity value is not automatically a cash saving. If staffing costs remain unchanged, the benefit may be additional throughput, less overtime or more time for review. State how the laboratory expects to use the released hours. Only classify an amount as avoided expenditure when there is a credible mechanism for that expenditure to decrease.
Include recurring and initial costs
Obtain current pricing for the required licenses, access configuration, maintenance and support. Add recurring costs that change because of the implementation. Do not substitute an old website price for a current quotation, and keep taxes and currency treatment consistent. If costs are shared across several workflows, document how they are allocated to this business case.
Initial costs may include training, template preparation, configuration, data transfer and internal staff time. Some of these costs may not appear on the supplier’s invoice but still consume organizational resources. Include a reasonable allowance for the transition period, especially if staff temporarily maintain parallel processes while the new workflow is being accepted.
Calculate payback with transparent assumptions
Continuing the hypothetical example, suppose annual capacity value is $8,000 and additional recurring costs are $2,000. The modeled annual net benefit is $6,000. If initial implementation costs are $9,000, simple payback is $9,000 divided by $6,000, or 1.5 years. These are invented planning inputs, not GAEA prices or a forecast for any customer.
Simple payback ignores factors such as financing, the time value of money and changes in workload. Use the financial method required by your organization for a formal investment decision. If the modeled annual net benefit is zero or negative, a positive simple payback cannot be calculated from those assumptions. Show that result rather than forcing a favorable conclusion.
Test low, expected and high cases
Vary the assumptions that matter most: annual volume, repeatable minutes saved, labor value and implementation effort. A lower-volume case may reveal that the decision depends on future work that is not yet secured. A higher training-cost case may show that the implementation schedule is more important than a small license-price difference.
Use the same quality and scope assumptions in every case. Do not make the optimistic scenario depend on skipping review or excluding corrections that are included in the baseline. Explain which assumptions are measured and which remain estimates. This helps decision-makers understand where a pilot or additional information could reduce uncertainty.
Treat quality benefits carefully
Better traceability and more consistent reports may be valuable even when they cannot be converted confidently into dollars. Describe the observed improvement: fewer files to search, clearer links to measurements or easier review of a corrected result. Support the statement with pilot evidence rather than promising that software eliminates mistakes.
Avoid double counting. If reduced correction effort is already included in the measured minutes per report, do not add the same hours again as a separate quality saving. Similarly, additional throughput and labor capacity may describe the same released time. Present them as alternative uses unless the model establishes genuinely separate benefits.
Plan how the benefit will be realized
Assign ownership for configuration, training and adoption. A business case based on standard templates will not succeed if every operator continues using a different uncontrolled version. Agree the first workflows to move, the acceptance checks and the point at which the old process will cease being the normal production route.
Track a small set of measures after implementation: active reporting effort, revision frequency, time to retrieve supporting measurements and the proportion of work using the agreed process. Compare equivalent workloads and investigate differences. If benefits are lower than expected, determine whether the cause is an unrealistic assumption, incomplete configuration or a training need.
Review adoption with operators as well as managers. Ask which steps remain awkward and whether the reported timings include the work that occurs outside the main application. A new spreadsheet maintained beside the system may indicate an unresolved requirement. Capturing that feedback helps the laboratory improve the workflow and keeps the benefit assessment grounded in actual practice rather than installation completion.
Present a decision-ready business case
Summarize the problem, evaluated scope, pilot evidence, costs, benefits and key uncertainties in a short decision document. Attach the calculations and assumptions so another person can reproduce them. Include qualitative benefits and limitations alongside the financial result. A balanced case is more useful than a promotional claim that cannot be connected to actual work.
Build the estimate around your laboratory. Contact GAEA with your test mix, report examples, user requirements and current workflow. Use a representative evaluation to establish where GDMS can help, then calculate the business case from the work your team performs and the improvements it can demonstrate.