|
Server : Apache/2.4.62 System : FreeBSD fbsdweb2.web.rcn.net 14.1-RELEASE FreeBSD 14.1-RELEASE releng/14.1-n267679-10e31f0946d8 GENERIC amd64 User : www ( 80) PHP Version : 8.3.8 Disable Function : NONE Directory : /domains/enrgy/techcor/ |
Upload File : |
<html>
<head>
<title>The Software Acquisition Process</title>
</head>
<body style="font-family: Arial" vlink="#808080">
<div align="center"><center>
<table border="0" cellpadding="8" cellspacing="0" width="98%" bgcolor="#000000">
<tr>
<td width="100%" valign="middle"><a name="top"></a><img src="../images/pmamagsm.gif" alt="PMA Online Magazine" border="0" align="right" WIDTH="229" HEIGHT="100"></td>
</tr>
</table>
</center></div><div align="center"><center>
<table border="0" cellpadding="8" width="98%">
<tr>
<td width="28%" valign="top" align="center"><!--webbot bot="ImageMap" rectangle="(14,297) (97,322) http://www.powermarketers.com/adrates.html" rectangle="(11,230) (95,257) http://www.powermarketers.com/pmajobs.htm" rectangle="(12,163) (96,189) http://www.powermarketers.com/main.htm##_parent" rectangle="(12,95) (96,121) http://www.powermarketers.com/power2.htm##_blank" rectangle="(11,29) (96,54) ../pmamag.htm" src="../images/magmenu.gif" alt="PMA OnLine Magazine Menu" border="0" align="center" startspan --><MAP NAME="FrontPageMap"><AREA SHAPE="RECT" COORDS="14, 297, 97, 322" HREF="http://www.powermarketers.com/adrates.html"><AREA SHAPE="RECT" COORDS="11, 230, 95, 257" HREF="http://www.powermarketers.com/pmajobs.htm"><AREA SHAPE="RECT" COORDS="12, 163, 96, 189" HREF="http://www.powermarketers.com/main.htm" TARGET="_parent"><AREA SHAPE="RECT" COORDS="12, 95, 96, 121" HREF="http://www.powermarketers.com/power2.htm" TARGET="_blank"><AREA SHAPE="RECT" COORDS="11, 29, 96, 54" HREF="../pmamag.htm"></MAP><a href="../_vti_bin/shtml.dll/techcor/9903frst.htm/map"><img src="../images/magmenu.gif" alt="PMA OnLine Magazine Menu" border="0" align="center" ismap width="110" height="350" usemap="#FrontPageMap"></a><!--webbot bot="ImageMap" endspan i-checksum="21856" --><p><a href="../searchpma.htm"><img src="../images/archives.gif" alt="Archives Search" border="0" align="center" WIDTH="70" HEIGHT="40"></a></p>
<p align="left"><font face="Arial"><strong><small>About The Author:</small></strong></font></p>
<font size="3"><p align="left"></font><font size="2">Jeffrey Frost, a PMTC Senior Partner,
has years of experience as a banking treasury executive, trading room technology
innovator, and Internet electronic commerce pioneer. </font></p>
<p align="left"><font size="2">While Jeffrey's prior executive and entrepreneurial roles
have demanded numerous skills, much of his career has revolved around one simple theme:
The use of new computing technologies applied to existing information to create profitable
new business alternatives. </font></p>
<p align="left"><font size="2"><a href="http://www.pmtcweb.com/" target="_blank">The Power
Marketing Technology Consortium</a> is an IT and electronic commerce power marketing
consulting organization which integrates and supports technologies related to energy
trading and marketing.</font></p>
<p> </p>
<p> </p>
<p> </p>
<p> </p>
<p> </p>
<p> </p>
<p> </p>
<p> </p>
<p> </p>
<p> </p>
<p> </p>
<p> </p>
<p> </p>
<p> </p>
<p> </p>
<p> </p>
<p> </p>
<p> </p>
<p> </p>
<p> </p>
<p> </p>
<p> </p>
<p> </p>
<p> </p>
<p> </p>
<p> </p>
<p> </p>
<p> </p>
<p> </p>
<p> </p>
<p> </p>
<p> </p>
<p> </p>
<p> </p>
<p> </p>
<p> </p>
<p> </p>
<p> </p>
<p> </p>
<p> </p>
<p> </p>
<p><a href="9903frst.htm#top"><img src="../images/b-t-top.gif" alt="Back To Top" border="0" WIDTH="71" HEIGHT="35"></a></td>
<td width="75%" valign="top"><img src="..\images/techcor2.gif" alt="Technology Corner" align="top" border="0"><p> </p>
<p><b><u>March 1999</u><br>
</b><font size="6"><strong>THE SOFTWARE ACQUISITION PROCESS</strong></font></p>
<p><strong>by Jeffrey Frost -- Power Marketing Technology Consortium<br>
</strong><font face="Arial" size="2">(<em>originally published by PMA OnLine Magazine:
99/03</em>)</font></p>
<blockquote>
</blockquote>
<p align="left"><font size="3"><br>
</font><font FACE="Arial Rounded MT Bold" SIZE="5"> </font></p>
<b><font FACE="Arial" SIZE="5"><p>I. Requirements For Change</p>
<i><p></i></font><font FACE="Arial" size="4">Change Drivers</font></b><font FACE="Arial Rounded MT Bold" SIZE="5"></p>
</font><p><font face="Arial">The need for new or improved software solutions is a near
constant in the merchant energy world, with deregulation in its many guises as the driver
for change. Three examples of deregulation driven major change requirements quickly to
mind: better risk management software, better generation asset optimization software, and
better trading operational automation.</font></p>
<p><font face="Arial">Whatever the source of the requirement, it is certain that the
demand for new software will arise. This month's column is about the process by which new
software capabilities are acquired. If the process by which software solutions are
acquired is flawed, the outcome will be flawed too. Here is an observed example.</font></p>
<p><font face="Arial">The merchant arm at Utility A acquired and installed one of the Risk
Management and Trade Processing (RMTP) unified suite products, understanding that this
product would not meet all of their needs. After installation, new IT management was hired
for unrelated reasons. The new manager, a developer with no prior industry background,
upon hearing of the weaknesses of this commercial product, set out to fix the problem by
building an entirely new replacement system from scratch.</font></p>
<p><font face="Arial">The main driver of change that the new manager responded to was the
fact that the just acquired commercial RMTP system did not accomplish various tasks in the
same fashion as the old pre-deregulation manual process and spreadsheet driven way of
doing business. This is a highly simplified description. But basically an aging manual
process and spreadsheet based system was replaced by a third party RMTP suite. The RMTP
third party suite was then to be replaced by a new in-house, client server application
developed to replicate the pre-deregulation manual and spreadsheet driven way of doing
business. Yikes!</font></p>
<p><font face="Arial">A more commonly observed outcome is the sales person driven
solution. Everyone at Utility X recognizes that better risk management and trade
processing tools are required for an increasingly deregulated world. When an aggressive
RMTP (Risk Management and Trade Processing) vendor makes contact there is a willing
audience to hear the story. In short order everyone at Utility X sees that they owe it to
themselves to hear the story of competing RMTP vendors before making a decision. So a
group of vendors call upon X and eventually one of them makes the sale. The first problem
is that the whole process is driven by the most aggressive RMTP marketing organizations.
Many times less aggressive companies with technically superior RMTP alternatives are never
even considered. Perhaps worse still, in-depth selection criteria on which to base a
decision are never properly developed, recorded, and rigorously applied to the decision
process.</font></p>
<p><font face="Arial">With fierce competition and razor thin merchant transaction margins
already appearing, the cost of sub-optimal software selection decisions has become quite
substantial. It is easy for financial engineers to identify ways in which many utilities
have not yet come to terms with the future they face. It is equally easy for applications
specialists to demonstrate how it is nearly impossible to implement more profitable
merchant activities without the right applications architecture and associate modules.
This article provides a blueprint for conducting the software selection process in a
beneficial manner. Before beginning, here is an aside about the buy vs. build choice.</font></p>
<font FACE="Arial"><b><i><p></i>Buy Vs. Build Bias</b></font></p>
<p><font face="Arial">This is not going to be a logical extended discussion of the pros
and cons of the two alternatives: build or buy. Instead it is just a statement of strong
opinion.</font></p>
<p><font face="Arial">Commercial merchant energy software vendors have spent tens of
millions of dollars and hundreds of man-years developing solutions for industry
participants. Many, including this author, have been critical of the pace of advancement
and the quality of applications which have resulted. But the twelve or fifteen better
development companies have by this time developed some very sophisticated and impressive
modules.</font></p>
<p><font face="Arial">The chances are almost nil that a single utility today could
conceptualize, design, and code a superior set of modules at an acceptable cost within an
acceptable time frame. Unless your organization has an incredibly unique vision and a
powerful proprietary business operational model, there are no valid reasons to be building
major merchant software capabilities from scratch for yourself today.</font></p>
<b><font FACE="Arial"><p></font><font face="Arial" size="5">II.
Software Acquisition Process Steps</font><font FACE="Arial"></p>
<i><p></i></font><font face="Arial" size="4">The Software Infrastructure Examination</font></b></p>
<p>Your overall applications architecture planning should be in place before any major
revamping of your merchant energy applications mix. That architecture will have many
components such as identifying operating systems, development environments, distributed
computing models, a middleware strategy, directory standards, security policies, and more.</p>
<p>As you strive to create a "straight through processing" (sidebar) merchant
energy environment, it will be necessary to integrate a variety of packaged, custom, and
legacy applications. For example, if you are acquiring a new, company-wide risk management
application it is important to understand how that application's internal architecture
will lend itself to integration into your multi-vendor, multi-platform, ever changing
environment.</p>
<p>For many merchant energy groups it has proven necessary to acquire best of breed
applications from a number of different third party vendors and then to integrate them
in-house. All of your application acquisition work should occur after your Software
Infrastructure Examination and with the assumption that it will be necessary to integrate
each application with others over time.</p>
<p>You choice of a middleware strategy and tools is the single most important part of this
software architecture. If you have not previously addressed this key issue, use the
following process template for this purpose, just as you would use it to drive any other
key software acquisition requirement. The process below has proven itself in middleware
searches as well as in other contexts.</p>
<div align="center"><center><table border="2" cellpadding="5" cellspacing="5" width="80%" bgcolor="#C0C0C0">
<tr>
<td width="100%"><font SIZE="5"><b><p ALIGN="CENTER">STRAIGHT THROUGH PROCESSING</b></font><font SIZE="2"></p>
<p ALIGN="left"></font>Straight Through Processing (STP) is a descriptive which conveys
the ideal of being fully automated. Information is captured at its source and
automatically transmitted to the next processing point at each successive step in an
energy merchant organization's standard sequence of events. STP might start with a
generation modeling system (1) which transmits data to a bid optimization and submission
model for the California PX Market (2). The CA PX applications return accepted bid data to
a generation scheduling program (3) and a trade capture application (4). The trade capture
application updates both the risk management model (5) and the settlements and billing
applications (6). Last in line, the invoicing and accounting systems finish the cycle(7)
and reporting systems (8) insure that management has the data it needs.</p>
<p ALIGN="left">This is a single simplified example. There are many other types of
transactions: e.g. PJM, Nymex, transmission reservations, or bilateral forward fixed price
and quantity agreements. In each case the sequence of events and applications might be
different. But for all major types of transactions the goal is the same. Information is
captured at the source and automatically passed through the systems with human
intervention limited to decision making and exception handling.<font SIZE="2"></font></td>
</tr>
</table>
</center></div><p> </p>
<b><font FACE="Arial"><i><p></i></font><font face="Arial" size="4">Team Selection Plus
Five Key Process Steps</font></b></p>
<p>First a software selection team needs to be formed. It is important to keep the
membership at 2 to 5 individuals. It is important to have a team leader. It is important
to combine persons of different talents on the team. A process facilitator is required,
technical talent is required, business process expertise is required, and future vision is
required. The entire team is expected to participate in all of the following process
steps.</p>
<font SIZE="2"><blockquote>
</font><ul>
<li>Discovery</li>
<li>Functional Requirements Specification</li>
<li>Solutions Selection</li>
<li>Implementation</li>
<li>Operational Management</li>
</ul>
</blockquote>
<p>This article addresses Discovery through Solutions Selection only. It does not address
Implementation and Operational Management issues, both important, just not covered here.</p>
<blockquote>
<font FACE="Arial"><b><p>Discovery - Wide and Fast</b></font></p>
</blockquote>
<p><font face="Arial">The Discovery step is an interview process lasting just a couple of
days. Team members create an interview format design to elicit a wide ranging set of
inputs from technical groups, user groups, planning groups, and senior management.</font></p>
<p><font face="Arial">Since various planning activities are inevitably on-going at all
organizations, there is often a tendency to decree that "this Discovery step is not
necessary." Don't succumb to this logic. The Discovery process ALWAYS leads all
parties involved (internal, and external consultants if engaged) to a uniquely integrated
view combining the best technical, business unit, managerial, and visionary thinking. One
of the major dangers in software selection is to just define all of the on-going processes
and then select the package which best fits the need. The greater challenge is to define
the vision of where the organization and the industry will be in 12 to 24 months and to
deliver a result equal to the demands of the inevitably fuzzy set of definitions about
this better tomorrow.</font></p>
<p><font face="Arial">The Discovery step is the only real opportunity to identify this
potential for a superior software solution. A superior solution is one meeting known
current and unplanned future technical, business, and visionary needs. It is also a
solution which integrates well into an evolving organizational applications architecture.</font></p>
<font SIZE="2"><blockquote>
</font><b><font FACE="Arial" SIZE="2"><p></font><font FACE="Arial">Functional Requirements
Specification - Detailed</font></b><font SIZE="2"></p>
</font>
</blockquote>
<p><font face="Arial">If the key objective of the Discovery step is to be quick and wide
ranging, the goal of the Functional Requirements Specification (FRS) is to be as detailed
as possible. This is the step where team members revisit the business units to map
information flows in detail. It is a difficult challenge to capture the current way of
doing things without introducing a rigidity which precludes flexible evolution into an
unknown future.</font></p>
<p><font face="Arial">The FRS is also the place where new or improved processes are
specified in as much detail as possible. One simple example. Many merchant organizations
are implementing organization-wide risk management changes which require quantum increases
in the functionality of their risk management application and vast changes in the way it
interacts with load/generation modeling modules, analytic pricing modules, trade
processing modules, etc. This single example would result in dozens of detailed
requirements statements.</font></p>
<p><font face="Arial">The future flexibility which is sought along many continuums will
come primarily from the technical details defined and developed throughout the process.
What open standards are sought? What is the internal architecture of any vendor system
under consideration? How will that internal architecture lend itself to integration within
the organization's applications architecture? How modular in design is a package? Is it
two-tier or is it designed from the start for n-tier distributed computing? These obvious
examples and all of the rest must be included in the FRS in full detail.</font></p>
<p><font face="Arial">The specifications should be fully comprehensive and well organized.
Here are the seven top-level criteria that PMTC, the author's employer, utilizes to impose
structure on the process. Within this schema, hundreds of details are ordered across a
four level deep hierarchical structure.</font></p>
<blockquote>
<ul>
<li>Scope of Offering</li>
<li>Features</li>
<li>Technical Architecture & Tools</li>
<li>Performance</li>
<li>Customer Support</li>
<li>Vendor Rating</li>
<li>Pricing and Contracts</li>
</ul>
</blockquote>
<p>Any logical, comprehensive, structure will work. The team simply needs to have it well
defined in advance of the beginning of the entire software selection process.</p>
<font SIZE="2"><blockquote>
</font><b><font FACE="Arial" SIZE="2"><p></font><font FACE="Arial">Solutions Selection -
Rigorous</font></b><font SIZE="2"></p>
</font>
</blockquote>
<p><font face="Arial">The watchword for the Solutions Selection step is rigorous. This
rigor is enforced primarily by the structured process itself, but also by the use of a
strong rank-weighting methodology</font>.</p>
<blockquote>
<font FACE="Arial"><i><b><p>RFP (Request for Proposal)</b></i></font></p>
</blockquote>
<p><font face="Arial">Writing a strong RFP is largely a matter of attention to detail. The
RFP must convey the full FRS from above plus all process conditions. For example is there
a bidder's conference? Is there an intention to start with five or six vendors and drop
down to two finalists at a certain stage? By the way, if you need to send your RFP to more
than five or six companies, stop and do yourself a favor by preceding the RFP with an RFI
(Request for Information) stage. Since much has been written about generating good RFP's
nothing more will be offered here on this subject.</font></p>
<font SIZE="2"><blockquote>
</font><b><i><font FACE="Arial" SIZE="2"><p></font></i><font FACE="Arial">Vendor Responses</font></b><font SIZE="2"></p>
</font>
</blockquote>
<p><font face="Arial">Demand full written responses from each vendor of interest. Have
firm deadlines and adhere to them. This author believes that it is usually advantageous to
allow only two or three (maximum) finalists to come on-site for a full presentation, often
followed by team member site visits.</font></p>
<p><font face="Arial">Treat all vendors with respect and be appreciative of the demands
you place upon them. You are starting a long and mutually beneficial relationship with at
least one of them. Avoid any unprofessional treatment of even the most irritating sales
person. (Apologies for the preaching, but experience has shown that many persons could use
a little advice on this issue. We are all just doing our jobs the best way we know how.)</font></p>
<font SIZE="2"><blockquote>
</font><b><i><font FACE="Arial" SIZE="2"><p></font></i><font FACE="Arial">Rank-Weighted
Tabulations</font></b><font SIZE="2"></p>
</font>
</blockquote>
<p><font face="Arial">It is important to impose rigor throughout the software acquisition
process. It is too easy to become inordinately influenced by a flashy GUI and clever
navigation aids. It is easy to make decisions which feel strongly right but are not
defensible and thus leave others (spell that "the check writer") uncertain or
unconvinced.</font></p>
<p><font face="Arial">The best means to impose rigor is via a well designed rank-weighting
process. This approach has three elements. First, each evaluation team member Weights the
importance of each item within the full evaluation criteria list which has been created
previously in order to produce the RFP. Second, each team member Ranks each vendor who
responds to the RFP.</font></p>
<p><font face="Arial">The third step, after all of the Weighting and Ranking has been
completed, is to tabulate the results. A single Rank-Weighted Score is the final result
for each vendor. In general, the expectation is that these scores will accurately reflect
the relative attractiveness of each software alternative. The numeric detail which
accompanies this approach "explains" why each vendor has scored as it did and
provides the basis for detailed discussion within the final vendor selection decision
making context. Creating a good quantitative rank-weighting methodology can be a bit
arduous, but there is no single "right way".</font></p>
<blockquote>
<p> <font FACE="Arial"><b>Decision Meeting</b></font></p>
</blockquote>
<p><font face="Arial">The selection team should complete its analysis and produce a well
written set of recommendations. These should be distributed to stakeholders and be used as
a basis for a formal decision meeting which includes all stakeholders. The final decision
my not be unanimous, but at least all parties have a voice and the reasons for the
recommendations are subsequent decision can be clearly articulated.</font></p>
<p><font face="Arial">That�s it. The process is a challenge and it is invigorating. Enjoy
it and make it work for your needs!</font></p>
<p> <font FACE="Arial" SIZE="4"><b>Summary</b></font></p>
<p><font face="Arial">Software selection is an art requiring a balance between many needs.
This article has attempted to map some means to improve the process. Along the way, at
least four main issues relating to the Software Acquisition Process are highlighted:</font></p>
<blockquote>
<ul>
<li>Buy don't build.</li>
<li>Establish a software infrastructure plan.</li>
<li>Mesh technology, business process, and vision.</li>
<li>Be detailed and rigorous.</li>
</ul>
</blockquote>
<p><font face="Arial">When you get the right team together and cover these bases you
improve your odds of creating the profit enhancing analytic power and operational
efficiencies possible through the selection and integration of the best merchant energy
applications.</font></p>
<hr>
<blockquote>
<p><font size="3"><em><strong>Disclaimer</strong></em></font></p>
<blockquote>
<p><font size="3"><a href="http://www.pmtcweb.com/" target="_blank">The Power Marketing
Technology Consortium</a> (PMTC) consults on applications, but has none of its own. Nor
does PMTC have any financial interest in the recommendations it makes to its clients
regarding particular vendors. PMTC funded and performed this research solely as a means to
better serve its target market.</font></p>
</blockquote>
</blockquote>
<hr color="#FFFF00">
<blockquote>
<font size="3"><p>Jeffrey Frost, a PMTC Senior Partner, has years of experience as a
banking treasury executive, trading room technology innovator, and Internet electronic
commerce pioneer. While Jeffrey's prior executive and entrepreneurial roles have demanded
numerous skills, much of his career has revolved around one simple theme: The use of new
computing technologies applied to existing information to create profitable new business
alternatives. </font></p>
<p><a href="http://www.pmtcweb.com/" target="_blank">The Power Marketing Technology
Consortium</a> is an IT and electronic commerce power marketing consulting organization
which integrates and supports technologies related to energy trading and marketing.</p>
<p align="left">Jeffrey C. Frost may be contacted at (802) 864-9903; e-mail: <a href="mailto:[email protected]">[email protected]</a></p>
</blockquote>
<hr color="#FFFF00">
</td>
</tr>
</table>
</center></div>
<p align="center"><a href="9903frst.htm#top"><img src="../images/b-t-top.gif" alt="Back To Top" border="0" WIDTH="71" HEIGHT="35"></a></p>
</body>
</html>