Choosing the most appropriate front and middleoffice software can be a perplexing task. Getting the most out of your software selection requires a structured approach, writes Ryan Rogers of Enite Group.
The rampant activity in energy trading risk management (ETRM) system implementations looks set to continue this year. This trend, driven primarily by regula tory requirements and mergers & acquisitions, has driven investment in vendor systems and led to a robust selection of increasingly mature software.
However, choosing the right system for your needs is not easy, as marketing materials and sales pitches often gloss over the inherent complexity of such software. Before you purchase a particular system, it is imperative to ensure that it is well suited to your needs and that its gaps are thoroughly understood.
What do you intend to accomplish with the future system?
Before embarking on your selection project, carefully consider the objectives and resulting scope of your desired system. Well defined objectives will help keep selection criteria focused, and will likely be determined by whatever gap is driving you to a new ETRM system in the first place. Support those objec tives by articulating the scope of the project across commodities, geography, business functions and technology. Consider likely future requirements from planned expansions or acquisitions.
Who will be your company’s business, technology and commercial representatives?
Engaging knowledgeable business representa tives to participate early is imperative. Identify key representatives from each func tion category and from your IT department. Involve a commercial representative as well, either from legal or an executive who will liaise with legal. These representatives will be responsible for approving the requirements lists and later, evaluating portions of the vendor demonstrations.
Who will conduct your selection project?
The selection process, particularly building the Request for Proposal (RFP), is time consuming and requires experience to execute well. A dedicated project manager to lead the selection is essential to a timely and quality execution. Firsthand knowledge of the vendor landscape and implementation experience with candidate vendors is not to be underestimated. Applicable experience will save time and money early on by narrowing your focus to the most suitable candidates, serve as a reasonableness check on vendor claims during the demos, and will help more accurately plan the implementation at the conclusion. An experienced project manager can also help prevent future implementation challenges such as budget overruns and missed deadlines caused by unidentified or insufficiently addressed functionality gaps. If you do not have access to such experience inhouse, consider outside assistance. Seek out consultants with knowledge of the vendor landscape and handson implementation experience, and make certain that the firm is not biased towards a particular software vendor. Conducting reference checks of the proposed project manager is helpful in evaluating the candidate’s objectivity. Additionally, seek someone who is focused on your particular business and will tailor the process to your needs.
Software selection requires a rigorous approach if it is to be executed on time and produce useful evaluation results. A typical workplan for the selection will be broken into roughly three phases: preparing the RFP; vendor demonstrations; and the selection and implementation planning. Each of these phases should then be broken into discrete tasks with realistic deadlines and clear ownership. This plan will also serve to keep your business, IT, and commer cial representatives informed of the tasks and timeline while they continue to perform their regular duties.
An easily overlooked but critical project management component is maintaining a clear line of communication with all business representatives. Keeping them informed and engaged will help ensure the success of your
Marketing materials and sales pitches often gloss over the inherent complexity of such software
system selection and ultimately the project. It is best to start the selection with an allhands meeting, to communicate the objectives, scope, selection process itself, the timeline and everyone’s roles and responsibilities.
Working from your defined scope, identifying target commodities, geography and business functions, begin gathering your detailed functional and technical requirements. Be as thorough as possible, even including likely future requirements, then identify which requirements are imperative and which are nice to have.
These requirements should be documented, and within each business function their importance weighted by the appropriate business representative.
Endtoend scenarios should also be developed to demonstrate each vendor’s func tionality stepbystep. It is best to focus your energy on developing two or three thorough scenarios most central to your business, along with assumptions and expected results. It will be difficult to work through more than a couple of scenarios and the better engineered those scenarios are, the better you’ll be able to evaluate candidate systems.
The RFP document itself will begin with your company’s background and project scope to help each vendor tailor their response to your environment and goals. Next, describe the requirements checklist and scenarios to be attached. The requirements checklist should be formatted to allow vendors to indicate how well they meet each requirement, and include descriptive answers for clarification. The scenarios will be attached for the vendor to prepare their demonstrations. Finally, explain the expected proposal format, RFP submission dates prior to the demonstrations, demonstration expectations and timeframes, guidelines for questions about the RFP, and describe what the evaluation criteria will be. Request a tailored workplan, cost estimates, support structure, and include any questions you may have about their corporate viability. Be sure to attach your confidentiality agreement. It is a good idea to schedule a conference call as a forum, so that vendors can ask followup questions about the RFP and demonstrations.
Schedule your demonstrations far in advance, more than a month if possible, to give yourself and the vendors time to prepare. Preparation should start with reformatting the requirements checklists into demonstration scripts with scoring and comment fields for users.
Request vendor references but also identify other clients of each vendor on your own. Before calling the references, prepare a detailed script of questions to help compare vendors. Be sure to ask what version of the software they use. You might also ask if they had any particular implementation resources worth recommending.
Create a demonstration agenda, allowing at least an hour for the vendor’s introduction at the beginning, then plan time for each script section through the remainder of the demonstration. Working demonstrations can generally be run concurrently with technical and commercial demonstrations, as they will involve different users. Schedule the scenario demonstrations for an entire day or two if possible.
Before conducting the demonstrations, meet your business representatives. Ask them to familiarise themselves with the scripts and keep the demonstration moving. Encourage them to score everything that they can, and write down all their observed concerns. Make sure they are aware of the agenda and when their participation is expected.
The demonstrations by vendors should stick to these scripts and scenarios, allowing you to score each vendor for your particular needs. Quantifying a vendor’s suitability not only allows comparison for decisionmaking, it also identifies any gaps to be addressed in contract negotiations and implementation planning. At the end of each vendor’s demonstration, compile the evaluation team’s scores and notes. After the last demonstration, hold a meeting to discuss the compiled comments and further define perceived gaps.
After analysing the RFP responses, vendor reference calls, and demonstration scores and gaps, you’ll need to shape the results into a recommendation. While the choice is never completely obvious, the results can be distilled into a workable presentation to the steering committee. Start with the quantitative results, comparing the vendors by functional and technical areas. List the key strengths, weaknesses and gaps of each vendor. Compare initial quotes for licensing and maintenance fees. Also consider the culture of the vendors and which of them you would most like to work with, as you will be working closely through the implementation and for years to come.
From this analysis, one or two candidates should clearly stand out. Recommending a first and second place choice is a good idea for contract negotiations and also keeps a second option available, should the first not work out.
Having chosen the most suitable system, the scope can be defined and the implementation planned carefully during contract negotiations. Very specific scope documents must identify the functions to be delivered, and define how gaps will be addressed. Also, timelines and milestones must be realistic and attainable. Software vendors tend to underestimate implementation schedules, frequently incited by licence payments tied to milestones. The most common areas for underestimating work have been interface development, testing, conversion of live data from the current to the new system, and rollout of the new system. An experienced project manager will be a valuable asset in building a more realistic workplan.
The functionality, delivery and budget risks mitigated in your multimillion dollar implementation are worth far more than the effort and cost of a rigorous selection process. The careful planning of your selection and following a rigorous process are essential to choosing the right system for your needs and understanding that particular system well.