Measuring project carbon emissions across materials transport and on-site machinery on a unified web platform

PROJECT OVERVIEW

ABOUT THE CLIENT

This case study is based on a real VNEXT project. The client's identity and certain project details have been anonymized or generalized for confidentiality purposes.

Our customer is a global technology company working in the energy sector, and it wanted to give its own project teams a clear picture of the carbon footprint behind what they plan and deliver. Emissions rarely come from one place. They accumulate across the materials a project buys, the fuel it burns, the journeys people make to reach it, and the machinery and equipment that run on site, so measuring them honestly means bringing all of those threads together. Exact financials are withheld for confidentiality.

THE CHALLENGE

The project was a replacement for an existing product, which is a very different thing from a blank page. Our customer already knew what it did not want to lose, and its expectations for the new platform had been shaped by the one it was replacing. That is helpful in many ways, and it also means requirements tend to move as people compare the new screens against the old ones.

The way we received requirements added to that. Instead of arriving as a finished specification, they were passed to our team through knowledge transfer sessions with the customer's end users, who were describing how they work and what they imagined the product could become. Many details were still ideas at that stage rather than decisions, and carbon accounting is a specialist subject with its own vocabulary and rules, so the distance between an idea and a buildable requirement was real.

Finally, the platform had to serve more than one purpose. One area of the product measures emissions from materials, fuel, transport, and travel, while another measures emissions from machinery, equipment, and operations, and both sit behind a single entry point where users are managed and routed to the right tool.

PROJECT OBJECTIVE

Our customer wanted a family of web platforms that make the carbon footprint of a project visible from several angles at once: what goes into it, what moves it, and what runs it. It also wanted a way of working in which requirements that were still forming could be pinned down early, confirmed by the customer, and tracked against a schedule everyone agreed to.

APPROACH AND METHODOLOGY

Bringing the right people into the knowledge transfer

Because so much of the requirement was spoken rather than written, our team made sure that a designer and a technically experienced engineer attended the transfer sessions alongside the people gathering requirements. That meant questions about how a screen should feel, and questions about what it would take to build, could be raised while the customer's end users were still in the room, and both were answered at the source.

Learning the business from the product it replaces

To understand the rules behind the numbers, our team also studied the customer's previous system as a reference. Seeing how the existing product handled each calculation and each workflow helped us clear up business rules quickly, and it gave us a shared starting point for conversations about what should stay the same and what should improve.

Turning conversations into user stories the customer approves

After each knowledge transfer, our team wrote user stories that captured what we had understood, including the basic flow of each feature, and sent them back to the customer for review. The customer could correct anything we had misread, and once the stories were agreed, they became the reference everyone worked from. This simple loop is what turned ideas into requirements without anyone having to guess.

Agreeing the schedule as carefully as the scope

Once the user stories were settled, our team prepared a schedule and an estimate and asked the customer to confirm them. When specifications changed, which was expected in a replacement project, the same schedule became the place where the effect of the change was discussed and agreed, so a change was a conversation about timing rather than a surprise.

TEAM SCALE

Our team for this engagement numbered seven, working as a dedicated team that combined design, technical depth, and development from the first knowledge transfer session onward.

• A designer: joined the knowledge transfer so that the look and flow of each screen reflected how the customer's users actually work
• A technically experienced engineer: attended the same sessions to judge what each requirement would involve and to shape the technical design
• Developers: built the platforms and the shared services behind them

THE SOLUTION AND TECHNOLOGY STACK

The result is a set of platforms that look at the same project through different lenses, brought together under one entry point so that users do not have to think about where each tool lives.

What was built

• Central landing page and user management: gives users one place to sign in, manages who has access, and routes each person to the right platform
• Emissions from inputs and movement: one platform measures the carbon footprint of a project's materials, fuel, transport, and travel
• Emissions from machinery and operations: a second platform measures the carbon footprint of machinery, equipment, and the way a project is run
• Shared backend and administration: one backend with an administration panel serves every platform, so user and project data are managed once
• Secure, scalable hosting: the frontends are served as static sites through a global entry point, while the administration side sits behind protection against denial of service attacks

Technology Stack

THE RESULTS

A requirement that began as an idea now has a written, approved form, and a schedule that the customer trusts when plans change.

• A written baseline the customer adopted: the customer chose to use the user stories our team wrote as its own reference document when evaluating the product
• Changes handled by agreement rather than surprise: the customer now relies on the shared schedule to confirm the impact whenever a specification changes
• Emissions visible from every angle: materials, fuel, and travel sit in one platform and machinery and operations in another, giving project teams a fuller picture than any single view could
• One doorway to several tools: a central landing page and shared user management mean a new platform can be added without teaching users a new way to sign in
• Security considered in the hosting design: protection against denial of service attacks and a controlled entry point were part of the architecture from the beginning

For a customer measuring the climate impact of what it builds, the numbers matter only if people trust where they came from. A platform whose requirements were confirmed in writing, and whose schedule was agreed together, gives that trust a solid place to start.