Thought Leadership:

Change Request or Bug?

In the fast-paced world of Commodity Trading and Risk Management (CTRM) software, not all issues are created equal. Traders, operators, and finance teams often use the words “Bug” and “Change Request” interchangeably, but the distinction matters. Understanding the difference can dramatically improve prioritization, vendor relationships, delivery speed and even reduce project costs.

In fact, one of the most common sources of friction between business and IT teams comes down to a simple question: Is it a Bug or is it a Change Request?

This article digs into the differences between a Change Request and a Bug, why it matters, and how modern CTRM teams can streamline the process for clarity and speed.

Defining the Terms

BUG

A Defect in the System

A Bug is a behaviour that deviates from the CTRM’s expected functionality. From the users’ perspective it is something that should work but doesn’t. It is an issue with the correct operation of existing functionality delivered in the system.

Examples:

  • An exchange trade does not get automatically entered into the CTRM.
  • A data capture screen rejects valid data or the dropdown for user selection is blank.
  • A Unit-Of-Measure, UOM, conversion rate incorrectly applied, e.g. MT to BBL.

Bugs are typically unintentional and occur due to coding issues, or integration failures. They either break something that used to work or the current functionality does not work for new, similar activities.

Change Request

A Planned Evolution

A Change Request is a formal proposal from the client to the CTRM vendor to modify existing functional or non-functional characteristics of the software, initiated to address new requirements or improvements. From the users’ perspective this isn’t a mistake, it’s an enhancement. An enhancement is a request to provide functionality that does not yet exist in the system.

Examples:

  • Adding a soft/hard validation for certain actions
    • Soft: a warning message to appear to alert user before proceeding
    • Hard: action not allowed
  • Creating a report/dashboard for a new business strategy.
  • Adding a new field in the User-Interface to capture additional data.

In summary, Change Requests can be expected as business needs evolve, whereas Bugs indicate a deviation from expected behaviour.

Why the Difference Matters

Prioritisation

  • Bugs can require urgent attention, if for instance, they impact financial results.
  • Change Requests are typically scoped, budgeted, prioritised and placed on the roadmap.

Treating a Change Request as a Bug can cause false alarms and disrupt support and development teams. Conversely, overlooking a Bug as a Change Request can expose risk to the users.

Cost Implications

CTRM contracts will differentiate between:

  • Defects (Bug fixes)
  • Enhancements (Change Requests)

Defects will be covered under the Maintenance and Support Agreement, with response times determined by their assigned priority level, covered in a previous article.

Enhancements could be subject to additional Professional Service fees, charged at the daily rate set in the initial contract.

The vendor will evaluate the proposed enhancement to determine whether it benefits the CTRM platform for other clients or is specific to the requesting client.

  • Platform-wide enhancements: If the change improves functionality for multiple clients, the vendor may cover the cost fully or partially, especially when the client provides a Subject Matter Expert (SME) to assist with the development.
  • Client-specific enhancements: If the change is niche and unlikely to be used by others, the vendor will issue a Statement of Work (SOW) outlining the cost. Development proceeds only after the client reviews and signs the SOW.

Frequency of Change Requests

A client implementing a CTRM solution should experience minimal change requests within the first few years post go-live, as at go-live sign-off, the client confirms that the system delivers the agreed scope of functionality.

During the sales and implementation phases, any identified key functional gaps are typically addressed and incorporated into the implementation plan. As a result, the initial production release should reflect the client’s defined requirements at that point in time.

Once the system is live and embedded into daily operations, new requirements can emerge. These may stem from evolving business models, integration expansion, process optimisation, or simply deeper user familiarity with the platform.

Checklist to Decide

Here’s a simple checklist you can use when assessing issues:

What’s Required from the Client

Whether it’s a Bug fix or a Change Request, the client needs to be involved, dedicating resources to the solution.

  • For Bugs, a few screenshots or a screen-sharing session with Support is usually sufficient.
    • Client input: often less than one hour
  • For Change Requests, a Functional Specification document is typically required, including defined acceptance criteria. This document is prepared by the vendor in collaboration with the client, who will supply the relevant test cases.
    • Client input: several days can often be necessary

Conclusion

Distinguishing between a Bug and a Change Request isn’t semantics, it’s a strategic advantage. Getting it right accelerates delivery, reduces risk, and aligns IT and business teams around what really matters.

Key takeaway: Bugs prevent existing functionality, while Change Requests shape and evolve them. Handle each accordingly.

Real time commodity trading and risk management software