Laypersons Guide To Purchase A Demand-Side Management Tracking Solution

Over my career, I have been both a user and a buyer of DSM tracking systems. A significant amount of time and money was spent reviewing procedures before deciding to move it in-house, but our internal IT partners began to realize that they had neither the time nor expertise to develop and operate a system that met our business needs. So, then we outsourced after the insourcing. With all that history as background, register here to read the ideal steps involved in efficiently purchasing a DSM tracking system.

When I moved into the corporate DSM office, one of my first jobs was to review potential replacements for that legacy system. A significant amount of time and money was spent reviewing systems that had even less functionality or would require significant customization. In the end, we undertook a major redevelopment project of the legacy system.

However, as the deregulation wave spread across the United States in the 1990s, the project was put on hold and was never revived. A few years later, as regulatory policies changed, we started over and bought a third-party built system that met our business requirements. Life was good for a while until it was decided to move all third-party systems in-house. Over the next few years, our internal IT partners began to realize that they had neither the time nor expertise to develop and operate a system that met our business needs. So, then we outsourced after the insourcing.

With all that history as background, the following are some of my thoughts on purchasing a DSM tracking system.

 

Identifying Your Organization’s Needs
To paraphrase Stephen Covey, “Begin with the end in mind.” What are the essential functions that you want the system to perform? Are you looking for a solution to manage the intake of customer applications? Do you want to process payments through the system? Does the new solution need to interface with other systems? Work with future users and other internal groups such as information technology, regulatory, and accounting.

Each of these teams will have a different perspective on what type of system you purchase. Outline these into business requirements. Use this opportunity to write the criteria for workflows that streamline and simplify operations.

The more specific, the better. As you move into the development stage, this will be invaluable for both you and the vendor you select. Also, do not assume that your vendor understands every nuance of your business. Write your requirements clearly and concisely.

Develop the Business Case
Are you purchasing a system for the first time or replacing an existing system? Either way, a business case should be developed. Identify your current costs in IT systems or FTEs in how you manage and track your DSM programs. Review your Company’s IT investment business case policy and document your needs before starting the procurement process. Typically, the approval process includes a review using investment cost-benefit analysis to identify pros and cons.

Create Vendor List
As you have started this process, hopefully, you have identified potential vendors. You can accomplish this through a simple internet search, contacting counterparts at other utilities, or visiting with potential suppliers at trade shows. As you perform this initial review, get an idea of the capabilities of each of them. Whom their current clients are and what services are they providing?.

Sole Source vs. Request For Proposal/Qualifications (RFP/RFQ)
Whether you have described to award the project to a single vendor or send it out for bids, you should have a very detailed set of business and functionality requirements. This is not an easy step. You should have a complete understanding of your business processes and create a document that the responding vendor can read, then begin designing the system. Let potential vendors know upfront about desired Smart Targeted KPIs and other commercial requirements.

If proceeding with the RFP/RPQ, the bid documents should include a description of how the procurement will work along with timelines, how bids will be evaluated, pricing, and the business terms and conditions. The RFP/RPQ should also contain detailed business requirements. Pre-bid conferences work well. While you may or may not get questions from potential bidders, all will hear directly from your expectations. The more details you provide, the better responses you will receive.

Evaluate Proposals
The approach I have found successful is to have a multidisciplinary proposal review team. A smaller group works more efficiently. By having DSM program subject matter experts working with procurement and IT specialists, the proposals can be reviewed and evaluated consistently. While the price is a significant concern, include other non-price criteria such as technical solution proposed, vendor track record, quality assurance/control protocols, and capacity to deliver.

Oral presentations are also helpful for those proposals that you will be moving to the best and final offer round. In this step, you will be able to drill deeper into the solution proposed and ensure the vendor has a full and complete understanding of all requirements.

Selecting Your Vendor
By this time, you should have a good feel for which proposal best fits your needs. As I have mentioned earlier, price is not everything. Through your research and conversations during oral presentations, you should have an idea of who not only provides the best technical solution; but who will be the best business fit for your organization. Hiring a vendor that is responsive and is easy to work with often is as important as the financial aspects. Start negotiating with your preferred vendor, but have the other vendors waiting in the wings if you cannot reach an agreement.

Contract Negotiations
Negotiations can either be led by the DSM subject matter expert or the procurement professional. I have negotiated contracts both ways. My preference would be to let the procurement professional take the lead. You will be there to answer questions about deliverables and other items specific to the tracking solution but keeps you out of the discussions around business terms and conditions. The procurement professional can act as a buffer between you and the vendor if negotiations do not go well.

Project Kick-off
After the contract has been signed, the project kick-off meeting is traditionally held with all parties. I would suggest that an internal kick-off meeting occurs before one with the larger group. In the internal meeting you will outline roles and responsibilities for each of your team members. Use this meeting to run through different potential scenarios that may arise when meeting with your vendor for the first time.

There are many different meeting planning tools that can be used to set up this first meeting; as with all meetings, the “who, what, where, when, and how” should be covered. At a minimum, the agenda should include introductions of team members from both sides with descriptions of their role in the process, the meeting expectations, and a review of the project’s objectives. Detailed notes of the meeting should be taken along with the assignment of action items.

Go Live
At the completion of the development stage, you will move to user acceptance testing. In my opinion, this is the second most difficult part of the process for the buyer. Nobody likes to do user acceptance testing, but it must be done and done well. If your system has external users, like service providers, it is also a good idea to test the system as well. As the system is being developed, another suggestion is to have different levels of the environment, i.e., development, testing, live. This keeps live program data safe and provides areas to work on the systems without impacting operations. In a perfect scenario, you will go live when all development is complete and all bugs and defects have been cleared up. The reality is, you will probably go live with a list of to-do items. This usually occurs because business requirements change, program launch deadlines are moved up, or other related issues. The key is to monitor and ensure the plan to complete this list is executed as quickly as possible.

Performance Metrics
In the last stage of the buying process, your will need to monitor the specified benchmarks in order to ensure the system is operating according to the agreement. Frequent meetings with the vendor and your team are important. I would recommend at least two levels of meetings. One, a more day to day operations meeting where operational activities are discussed; such as bugs and system performance. This where program and project managers from both sides will discuss operational activities. The second higher-level meeting occurs on a monthly basis, where business owners or managers review performance metrics and resolve areas of uncertainty.

Key Takeaways
The end goal of this process is to achieve your business objectives. Here are a few key takeaways:

 

Buying a DSM tracking system can be a daunting task. There will be times during this process where you wonder what you have gotten yourself into. Keep focused on the overarching business objective of implementing this system that will enhance your program operations. You will encounter problems along the way.

As long as humans are involved in the design and operation of the system, mistakes will be made. How you respond to these situations will set the stage for success.

For the past ten years, I have been associated with ANB systems and am familiar with their products and services.

I have found that the eTRACK+ platform to be an extremely flexible and powerful tool in the management of demand-side management portfolios. Additionally, their team is committed to the success of their clients.