How to Champion a Successful Software Purchase

Hello, my name is Dax Farhang. I am the Product Manager, responsible for ElectricCommander. From time to time I will post my thoughts on the software industry, the Software Product Management space, and CloudBees’s software solutions. I might even toss some darts at our competition if the appropriate mood sets in. Given that I am a member of the marketing organization, there are some who that will contend that all of my posts will merely be veiled attempts to lure you to CloudBees products.

There’s no point trying to convince those individuals otherwise. Instead I dedicate my inaugural post on this blog to all of you. Have you ever tried to push a new software tool for your team and failed? Have you ever wanted to drive the purchase and use of a new software application but didn’t feel properly equipped to execute? Anyone on a team is capable of championing this effort with the appropriate approach. It is even more important in a tough economy to present a well-reasoned argument with a reasonable expected ROI fully calculated. Here are a few guidelines that will increase your chance of success.It’s often assumed, that the only person responsible for driving the purchase of an organization-wide software application is the department head or someone with signature authority.

Management of team members or access to the purse strings certainly requires those individuals to drive the purchase software from time to time, but it doesn’t mean that those individuals always champion the overall effort. In fact it’s often someone who is more closely tied to the needs the software will satisfy or someone who will be a primary user of the application that champions the purchase decision. This is especially true in software development organizations, since the lack of employee adoption can completely nullify all the value that a software application might bring to a team. Given these notions, it is certainly feasible for any team member to drive the adoption of a software solution for the entire department. So whether you are a manager focused on purchasing an application or an individual developer that wants to solve a team-wide issue, the ideas presented here should help you in this regard (or at least reinforce what you already know). Prototyping is king – Building a prototype for the proposed solution is the most important factor in championing a successful purchase. Without a successful proof of concept, it’s difficult to utilize any of the subsequent recommendations in this post.

On the other hand, a successful prototype can mitigate weak execution of the other recommendations. There are multiple obvious advantages to prototyping, which have been cataloged here by the wisdom of the crowd. The bottom line is that a prototype is the most effective way to validate that an application can solve your needs. Quantify the ROI – Quantifying the return on investment can be the most difficult task for a champion to execute. However it is extremely important as it translates the value of the software into terms that all the stakeholders can understand – money. Identifying the ROI can also be a healthy exercise to help champions confirm for themselves that the software will have a positive tangible impact. Have you ever been witness to a situation where someone implements a process or tool change only to realize later that the solution doesn’t work because it’s trying to solve the wrong problem? An effective ROI analysis could certainly help to mitigate such circumstances as the returns stem from the problems that are solved. In software organizations the greatest expenses are generally associated with people. Hardware, software, office space and the like are all relatively inexpensive when compared to the cost of salaries, especially since the cost of the equipment can be distributed across the workforce. Subsequently, the greatest ROI drivers in most software development organizations are those that improve employee productivity. Employee productivity is improved when people are enabled to execute tasks quicker, with higher quality, or when the amount of idle time is reduced. So start with the impact to the people that will be using the software when trying to quantify the ROI.

Identify key adopters – Adoption is also critical to success in any software rollout. Everyone is familiar with the acronym, GIGO (OK no more Wikipedia pointers this post), which states that poor input into software will produce poor output. This also effectively states that if a team doesn’t put any value (or effort) into a software application, that team won’t get value out of it. I know this is somewhat elementary, but nonetheless worth stating. When attempting to champion the rollout of a new software application, you need to create a team of supporters. Management is much more likely to entertain an idea if it is endorsed by a group. Other individuals also bring perspectives (both positive and negative) that can help the promotion of a software solution. In short, if you can’t get anyone else on your bandwagon, it’s a good indicator that the solution may not be endorsed by management or successful if it is. Plus this provides the opportunity to turn a vocal detractor into a supporter before presenting your proposal to management.

Beware the risks – It’s very easy to focus on the positives of a particular solution and to overlook the negatives, especially when it’s one’s own solution that is being incubated. Nevertheless it’s important to understand the risks associated with a software solution. Some common pitfalls are listed here.

• Hidden costs – The price tag on a particular application is only part of the cost associated with it. One example of a hidden cost is that of ongoing application maintenance. Other examples of hidden costs include customizations required to traverse a feature gap and support matrix deficiencies.

• Process or behavioral change – A hidden cost as well, process or behavioral change, is worth noting as a significant risk to any software rollout. This is related to the previously referenced need for adoption. Most people don’t like to be told what to do, but this is an unrealistic request for most since it’s a basic premise of being employed. Similarly, people prefer not to be told how to do something. This is especially true in software development, which is seen as an art as much as a science. If a solution requires that people change their process in a way that they don’t want to, it’s unlikely to be adopted and likely to fail.

• Individual resistance – Similar to being wary of requiring unwanted behavioral change and the need for identifying key adopters, it’s also important to identify individuals that are resistant to the adoption. By proactively working with these individuals to understand and address their concerns, you put yourself in a much better position to gain buy-in from the rest of your team.

This is by no means a complete list of all the factors to consider when championing a software purchase nor is it meant to be a step-by-step recipe. However these recommendations should definitely help put you on the path to success. Let me know if you feel that there are other facilitators or inhibitors that I missed here.