You are probably not going to find the role 'Software Advocate' on any org chart. The role is assumed by anyone assigned the task of finding new or replacement software. It may also be a 'volunteer' role if an individual is passionate about a topic. Data science projects are a common example of this type of volunteer pursuit in many organizations.
What is a Software Advocate?
Software Advocates typically take the role of finding new or replacement software and have tacit or explicit approval and support. Volunteers must recruit an executive sponsor. In either case, the Software Advocate's real job is finding good candidate software solutions and 'selling' them inside the organization.
The idea of selling a solution inside your organization might seem a bit strange. After all, isn't that a software vendor's job? Truth is, if a purchase decision is needed, the decision-makers must understand the options. The Software Advocate presents or 'sells' the options.
The Software Advocate needs to be aware that in the process of advocating for software, stakeholders will fall into one of three groups:
- Consumers: the users of the software, often including Software Advocates
- Buyers: have budgetary control
- Deniers: typically have technical or other requirements for the software to meet.
Candidate software up for review must win over all three groups. Anyone in these three groups has the power of 'No', which leads to the first piece of advice.
Avoid starting with a solution if possible
Even if you have a mandate to find a software solution, name the problem first and then sell the solution. Something like, we need X to solve Y. After getting a general agreement that a problem needs to be solved and you know the general solution, then you can introduce your candidate solutions and recommendations.
Where does a Software Advocate start? I wouldn't recommend spending a lot of time initially looking for solutions. You may not know what the real problem is yet. Instead, begin collecting requirements from each of the three stakeholder groups. If you understand the parable of the 10 blind men and the elephant, the requirements draw the picture of the elephant (the need) and will connect the stakeholders to the range of those needs.
Identify what is good software
Good software fits a need and provides recognized value that exceeds its costs over time. There are two important concepts here: (1) good software fits the purpose it was intended and (2) it has value over the time it is in use. While software may become obsolete and even die over time, it doesn’t make the original selection bad.
How do you find good software?
The general wisdom says to search for software to solve a problem or fulfill requirements. However, you may come across solutions at conferences, via online ads, or white papers that seem like they might be a good fit for your business. Your organization may want to explore some new technology to see if it would be of value to the organization such as Lead & Copper Rule Management software.
There is also the 'cool factor', which might look like joining the crowd of rising companies using the same software or having access to innovative product features that no one else is using. Recognize it when you see it along with the desire to explore interesting solutions. All are legitimate but you must consider your organization's needs, wants, budget, and tolerance limits for exploration and 'the cool'.
Weigh the different software options best fit for your organization
The choice is important. Too few choices of qualified software or too many will be a problem for decision-makers. Ideally, you should provide three to five choices that meet or beat the requirements. If more than five candidates exist, identify the top five and list the additional ones in an appendix with a brief statement highlighting the rationale that disqualified them.
On-Premises
For on-premises, mission-critical enterprise software, development, test, and production environments should exist to migrate and test patches in advance of committing to systemic updates. Changes could impact process or data sets. Help desk scripts and training may be required when these types of changes are made. Most vendors will not charge for non-production licenses.
Buy or Build
‘Buy or build’ should also be considered. If you aren't a software development shop, think very carefully about building it yourself. Maintaining and documenting it can be expensive and time-consuming. If it must be built, consider engaging a contractor to build and maintain the product.
Shadow Systems
Shadow Systems (process, data, and applications) exist because they must exist. Make sure you know where these are and their purpose. Good process and data maps will usually expose them. If you are replacing applications or making a significant upgrade, you could disturb these systems and cause significant problems.
Cloud
The Cloud is commonly seen as less expensive than on premise operations. For most organizations, this isn't entirely true. Comparisons may be a bit hard as you move from costs that were a mix of capital, expense, and labor to expense and labor. The value you get is scalability and not having to deal with physical assets.
Some types of software are better to have on-premises (e.g., mission-critical operations software), often including mission-critical operations software. Local control of service level agreements or SLAs and resources to support them can be provisioned. Third-party outages or lags can't be controlled or fixed directly by you.
>>YOU MIGHT LIKE: Understanding the Differences Between a Digital Journey and Digital Strategy
13 tips for evaluating good candidate software
These observations serve as a guide during the software evaluation process.
- Security: Make sure you understand how the software's security works and administration requirements. For widely used applications, single secure login is a must.
- On Premise software costs: In addition to the software costs, a periodic (commonly annual) maintenance cost is often tied to the current product price. Make sure you budget for it and that you understand what happens if you don't pay the fee. You don't want to find that an important piece of software suddenly doesn't work.
- SaaS (Cloud) costs: While some SaaS products have annual maintenance fees, most will have monthly fees that may vary by usage type. Arrangements like this must be carefully watched to prevent unpleasant surprises. In addition, fees may escalate over time usually as the price of the software increases.
- Licenses: If some individual licenses are named, make sure they can be transferred to another individual. You should not receive a penalty for reducing license count.
- Vendor background: Consider the vendor’s background. What kind of company are you buying from: a C or S Corporation, Mom & Pop, Startup, or one which is outside of your country or legal jurisdiction? Do they have significant expertise in the area of focus for the software?
- Stickiness: Assess the 'stickiness' of the software. Software is sticky if, once installed and used, it cannot be easily replaced. A QR code reader on your phone is not sticky. An organizational accounting application is very sticky. This should guide the depth of your requirements, the need for signoffs, and the identification of qualified candidate software.
- Contract terms and conditions: Make sure there aren't any unpleasant surprises. Understand your SLA options and if access to incident reporting is restricted, identify who can instantiate an incident. The vendor should always allow at least one backup person for this role. Contracts aren't one-sided. Negotiate a contract before you sign it or make any payment.
- Capital and expense: Consider the capital and expense tax ramifications of your purchase. In addition, recurring costs related to SaaS applications of unanticipated amounts might create budgetary problems. Make sure to talk to your budget and tax team during your requirement gathering.
- Data: You should always be able to recover data from transactional systems to compile for the organization’s use. This may be through connecting directly to the software's database, via API, and or through a downloadable report. Ideally, you should be able to push data into that transactional system as well. Most modern systems allow this. If you run into a system that identifies itself as having a proprietary structure that does not at least allow for the export of data, cross it off your list and move on.
- On-Premises maintenance: Software agreements usually include the availability of patches and upgrades (these are different) during the maintenance period. The vendor should provide this list well in advance of any scheduled update. Read the upgrade and patch lists before making changes. You might not want to change certain aspects of the system. If there is any custom work, run regression testing in your development-test environment first. Changes may mean adjustments to your training and helpdesk scripts.
- SaaS maintenance: Maintenance of the cloud SaaS environment is not always announced. You get upgrades and patches usually without notice. If something major changes, you may get notified but you will rarely have options to say yes or no to the changes. This may drive an occasional need for process changes and impromptu training exercises.
- Maintenance (both environment types): Changes to the environment may have profound effects on any system pulling data from the software to be entrained in a data warehouse or other system used to compile data. Change lists from the vendor should always be forwarded to the group responsible for maintaining these types of systems.
- Opportunity costs: Free software doesn’t exist, as in, even trial or Open-Source software still requires someone to install it, maintain it, and use it. The organization will endure some type of cost even if it's just time. If you use it on anything but test data, the application may also become sticky.
Making a final selection
A good vendor can assist by providing facts, talking points, and support for the Software Advocate's selling process. Take advantage of this introductory workshop where I will walk you through an interactive discussion to provide context and direction for the next steps in your digital journey.
