Are you wondering about the best way to write functional requirements for an Energy Trading and Risk Management (ETRM) system? Before you begin to write out your Request for Proposal (RFP), you need to perform some due diligence, starting with listing out and carefully considering your requirements. It will take time and effort, but you’ll find the right vendor for you if you are thorough and thoughtful.
If you’re still getting to grips with the world of ETRMs consider reading this blog post first: What is An ETRM System and How Does it Work for Power Companies
Orchestrate targeted workshops
To compose your functional requirements, put together some targeted workshops with your commercial business teams to ensure they’re committed to helping you gather information related to current and future operations. Both leadership and operations teams are required to collect the right information with you as you assemble requirements.
Your executive team should provide an overview of their current and future commercial objectives and related business goals they hope to accomplish with the new solution. They should also convey and share details related to current trading and risk policies in place. These objectives, goals, and policies should be considered requirements and will help set the direction when completing the workshops with the operations teams.Â
The operations teams, comprised of the front, middle, and back-office and IT, should provide their current set of process narratives, process flow charts, commodities traded, and trading markets. In addition, they should provide sample trading contracts, transaction sets, market prices, operational and financial reports, risk and accounting calculations, key financial controls, manual processes, spreadsheet workarounds, technology standards, hosting/infrastructure standards, inbound and outbound interfaces, and known pain points with current systems.
During each workshop, it’s essential to identify distinct transaction sets and have each team walk through with you their daily, weekly, and monthly responsibilities and scenarios required to manage those transaction sets. At the core of the ETRM is the end-to-end transaction process, so it’s essential to capture the requirements along the life cycle of a transaction. That includes counterparty and contract setup, deal capture, scheduling/tagging, checkout/invoicing, and accounting and reporting to the general ledger. You may consider a workshop to understand if any internal/external audit findings are unresolved related to the commercial trading operation and review with the leadership team to understand how those should be included as requirements. Lastly, a workshop with internal regulatory reporting teams will provide additional reporting requirements required for periodic FERC and PUC reporting.
Before conducting the workshops, it’s best practice to have each of the targeted teams provide you with as much material and sample data in advance so you can start the requirements list and provide a starting point for each workshop. Doing this in advance will make the workshop more efficient and effective in helping you probe for unknown or missing requirements.
As you can see, you have many categories to review and much data to gather. Every unit in the company needs to play its part so your company can select the best ETRM system to fit your current and future operations.
Must-have or nice-to-have requirements
So, you have your ETRM master list of functional requirements now. But, my goodness, it is long. You may have hundreds of items on your list. Now, it is time for the next step: prioritizing list items as high, medium, or low. Each group should go through its list and decide on one of three things based on how it impacts their team and the operation as a whole:
- High – Your business cannot operate without this working completely and accurately, has a high frequency of use, no known workarounds, and operational risk is high if not available
- Medium – Your business cannot operate without this working completely and accurately, has a low frequency of use, could consider a workaround, operational risk is medium if not available
- Low – Nice to have, low risk to operation, could be helpful in the future as business scales
When you know what’s most important, you can move on to the next step of writing a requirement statement.
What’s the right way to write a functional requirement statement?
When putting together your RFP, you can write a functional requirement statement in two ways: the wrong way or the right way. The wrong way is when you’re too vague about what you want. For example, if you write that you want the ability to monitor credit exposure, you leave out detailed information. Who in your company needs that information and why? How will that information help in the long run?
So, what’s the right way? The best way to write a requirement statement is to put it in the form of a user story. These are well-expressed requirements from the perspective of an end-user goal. User stories focus on the viewpoint of the role that the solution will impact. They clarify the reason for the requirement at a high level. A user story should be brief and serve as a placeholder for a future detailed discussion with the ETRM vendors you’re looking into.
Now, instead of simply writing that you want the ability to monitor credit exposure, you can add more detail. Consider writing your statement in the following form: As a <type of user>, I want <some goal> so that <some reason>. For instance, “As a credit analyst, I want to monitor daily credit exposure so that our counterparty credit limit is not breached as contained in the Risk Policy.” This statement is much clearer and will ensure that the product you buy meets your requirements. And this statement will become the basis for a future test case during implementation.
Putting together your RFP
You’ve prioritized your ETRM functional requirements and written up user-based statements. What’s next? First, combine all your requirements in a spreadsheet marked as high, medium, or low. Your preferred vendors can then respond to clear and effective requirements. Next, combine some of your user stories into scenarios. A scenario combines 10-15 of your user stories into a “day in the life” story of activities that happen regularly or have created challenges/risks for your operations. Vendors prefer to receive scenarios as it provides a more precise context of the type of system you need. Review everything. Have each unit look over its sections of the requirements. Have you overlooked anything important? Once your review process is complete, it’s time to find a vendor!
Choosing the right vendor
As important as it is to research what you need in an ETRM system, choosing the right vendor is also essential. Clients typically start with a list of three to five qualified vendors and then choose one or two to short-list and perform a demo for you. Because of all the work putting together your functional requirements and “day in the life” scenarios, a vendor should easily be able to demonstrate how their system will benefit your unique needs.
Now that you’ve taken the time to complete the thorough process of writing ETRM functional requirements, you’re now ready for vendor selection and contract negotiations.
If you’re interested in learning more about ETRM, check out “ETRM Implementation: 5 Lessons You Can Learn From” on our blog.
