As an analytical consulting firm, Pterra regularly uses about half a dozen engineering software, and about the same number on an occasional basis, to be able to conduct its services. The software are necessary to be able to simulate complex physics and market conditions and/or large scale databases. In addition, we try to use the same software that our clients use so that part of our deliverable is an updated system model or database.

Needless to say, the use of engineering software is mission-critical, a situation that is likely repeated in any number of utilities, engineering design firms, system operators, market participants and educational institutions all over the world. The software needs not only to provide accurate engineering results but also to adopt new technologies such as solar PV, wind turbine, high voltage direct current and frequency converters, market structures and new analytical methods as expeditiously as possible.

The key factors that we would look for first and foremost in engineering software are:

  1. Available features
  2. Recommendation/feedback from existing users
  3. Capability of the development team

The first two items are probably the same criteria that anyone would use when buying any mission-critical product, perhaps no different from the appraoch one may take in buying a car or house. The third item is unique to engineering software because of the following desired characteristics for such products:

  • The need to modify and update the software to account for new technologies and structures as noted earlier.
  • As a consulting firm, we encounter many unusual analytical or modeling situations that may require modifications/additions to the algorithm or structure of the software.
  • The long-term commitment of the software development team and owning company to continue to maintain and update their product.

We apply an active approach to ensure the desired characteristics are continuously provided by our software suppliers, including:

  • Attending/participating in users groups, either online or in conferences
  • Communicating directly with the developers to address specific modeling or algorithm issues, and monitoring response time
  • Talking with out clients to get feedback on updates and development plans of the software we use in common

Needless to say, a responsive technical contact helps our vetting process and affords us that warm, fuzzy feeling that our investment in their software is in good hands.

Some of the big warning signs that alert users to potential issues down the road with engineering software include:

  • Very slow response time. Unresponsive technical support is an immediate cancel or discontinue indicator. Slow response can mean all manner of things including disinterest, internal unrest, lack of staff, etc.
  • Lack of vision. Not really looking for the next Bill Gates of engineering software, but some long-term plan that makes sense is important. Most engineering software do not have big development teams, at least not on the level of magnitude of, say, a Microsoft. Usually the role resides in the development manager, so we make sure we know who this person is for each software we acquire, and that we communicate with the manager to know and understand thoughts and ideas for development. For example: Devin Vanzandt – GE PSLF, Sherman Chan – Aspen, Craig Muller – PSCAD/EMTDC.
  • Attitude. Developers who are not willing to listen to new ideas and suggestions should have a really good development guru, like the late Steve Jobs, and even then we don’t have that assurance that new ideas will remain consistent with our own needs. Furthermore, developers that constraint access to their products by specific segments of the user community, specifically, consultants (!) are limiting their options for better feedback and exposure to extreme tests.

Finally, one key warning sign, at least for an analytical consulting firm such as Pterra, is when engineering software tends to focus more on interaction and being visually stunning rather than on improving its analytical engine. Admittedly, this may not be a universal concern, but we like to believe this is important in varying degrees to all users of such products. One of the things this change in focus may imply is that the software is gearing up to sell more licenses to new users rather than caring for its established user base. In our opinion.