Look at “Can” and “How” in Best Software Selection

The RFP stinks when done wrong. Are you doing it wrong?

Software is key to an Association’s success. I believe that every executive should think of their software programs as partners in helping support every facet of their organization. Therefore, from time to time executives should take a step back and ask yourself, how is my software partner doing?  In this article, I cover some thoughts on how to choose a software partner wisely by looking at “how” and “can” in software selection.

The Best Process Leads to the Best Software Selection 

Let’s agree, to start with, that relying on a solid process will get you to the right software decision for your Association—software that meets your Association’s needs now, into the foreseeable future, and fits into your budget.

“There are two possible outcomes: if the result confirms the hypothesis, then you’ve made a measurement. If the result is contrary to the hypothesis, then you’ve made a discovery.” – Enrico Fermi

In other words, start with an open mind and a phased narrowing process: an effective RFI (Request for Information) followed by an efficient RFP (Request for Proposal) & then the demo.

The Role of an RFI—The “Can”

In my opinion, with all the vendors and all the software choices out there, jumping headfirst into an RFP is akin to sending out your wedding invites without dating your mate first. Certainly, you may have a pretty good idea by just looking at their online dating profile. But, it’s a hit or miss proposition at best. Yet, sending out blind RFP’s from no more than a website session still remain the standard procedure for many organizations today.

That is why I am so committed to an RFI, Request for Information, before an RFP. The RFI is a less formal but still systematic and efficient way to narrow the field of choices. It’s a method that enables you to learn which vendors “can” possibly meet your software requirements.

  • First, RFIs require you to be crystal clear about listing all of the functions for which you need integrated software support—such as marketing, membership management, fundraising, event planning, financials, and reporting.
  • Second, RFIs require that you winnow your field of possible vendors. How? Best practice winnowing includes partnering with a specialist experienced in both off-the-shelf and made-to-order software systems. It also pays to reach out to your network and read online reviews of relevant software providers.

An RFI should include:

  • Table of Contents
  • Executive summary, or introduction and purpose of the RFI
  • Describe the business use case of the project
  • Outline the key requirements of the organization and even departments
  • Explanation of scope of the software requirements
  • Glossary of abbreviations and terminology
  • Template for the vendor to complete
  • Details of your next step: an RFP or RFQ.

Why is an RFI a valuable step for both software buyer and the software vendor?

  • The RFI minimizes the costs in the process (both hard costs and soft).
  • The RFI allows the vendor to truly understand what is required.

Think of the RFI (request for information) as the information step of probing. The final product of your successful RFI is a short list of five to seven vendors whom you invite to respond to your RFP.

By the way, if you work with a software consultant, he or she should already have a good knowledge set for the options in your market and be able to avoid time in the software identification area.

The Role of an RFP—The “How” explained

I have a confession. The RFP, Request for Proposal, process stinks! I realize that these are blasphemous words coming from a software consultant. But, I truly believe that most if not all RFP’s received by software vendors are premature, rigged and a guessing exercise for most software searches today.

In my opinion, the traditional software RFP process is a time drain and broken down process. In fact, when it comes to purchasing software as a service solutions, this process never worked properly in the first place. I believe it is the reason stories about software failures regularly appear in the technical press. These stories are only the tip of the iceberg; people don’t talk about most partial or outright failures because they don’t want to be associated with them.

But, no matter how hard you try to avoid them, you can’t. The RFP is the formal procurement process most familiar to executives and likely you too. I admit that the process will not change but for many nonprofits it should.

If you do decide to produce a formal RFP, you should be targeting a select few vendors to send your well crafted proposal. That alone will boost the success of your outcome exponentially. Please don’t waste your time or the software vendors in sending it out to a plethora of options without an RFI already completed.

The Best RFP for Your Software Selection

So, if we have to live with them. Here is what I believe the best RFP’s do:

  • The best RFPs provide a great deal of specific information about your Association—for instance, its mission, its daily work, its internal organizational chart—to invited vendors in order to help them grasp how they can provide the software support you need.
  • The best proposal never lacks specifics: they step you through exactly how that vendor plans to partner with your Association now and into the future to ensure that your new software system offers all the functionality you require in a user-friendly package.

Minimally, an RFP includes:

  • Table of Contents
  • Confidentiality or non-disclosure agreement
  • Information about your nonprofit and the process for selection
  • Detailed extent and scope of the software requirements.
  • Write requirements as closed questions that the vendor can answer with a selection from a drop down list if possible.
  • Ask the vendor to rate how well their products meet your requirements.
  • Priorities of features requested rather than just features requested
  • Proposed time frame for selection
  • Detailed design information and requirements
  • Budget expectations and considerations
  • Outline your availability to discuss the proposal
  • Evaluation process and award criteria
  • Submission instructions

The RFP audit-The Fail-Safe Step

If an RFI is effective, you should request vendor proposals only from quality vendors who provide what they say they will. But how do you know for sure? The answer is an RFP audit.

  • After reviewing the proposals, ask the vendors follow-up questions, being sure to note down what the vendor responded and how (phone or email, for example).
  • Require each vendor to provide evidence that their software does what they claim in their proposals. Evidence can be in the form of documentation, videos, or a test account online.
  • Go back to your rating sheets and review (or change as needed) your scores according to the responses in the audit process. Annotate your changed or verified scores with audit-related comments.

The Role of the Demonstration-The How Displayed 

I could write a book on the value of demonstrations in terms of winning the mind share of my clients. In addition, I could also write about the pain associated with sitting through ones that sucked too. But, demonstrations are critical in finding out the “how”. Demonstrations, or demos, will let you see how the software explained comes to life. There are several different types of demos:

Self-running demos:

Most companies will provide a self-running demo on a CD or Web site. These demos often show basic functions and let you examine the look and feel of the software. They can be useful for a preliminary evaluation during your RFI process, but they generally cannot cover functionality in great depth. You may find these of value in the “can” during your RFI process.

Live demos:

A live vendor demo lets you see more features, and ask questions while you are reviewing the product. Prepare questions in advance that relate to your organization’s needs, such as those on your checklist, or ask for some hands-on time with a fully functioning system.

I always suggest that the initial demo is about an hour and should be focused on the key priorities outlined in your RFI and RFP. An agenda with each area requested should be provided to the vendor for preparation. If warranted, the second and subsequent live demonstrations are built on the findings of the first and further exploring more specifics.

Demonstrations are so important in a software selection project. As with all steps in software procurement, a good process matters in getting the best results out of a demonstration.

The Role of the Hands On Experience-The How Revealed

I know that this is going to kill a lot of vendors to hear. But, I believe that today it’s important for an individual evaluating software to get their hands on the product. When we are asked to consider making a decision on thousands of dollars and the stakes are so high, I believe it’s paramount.

Granted, their needs to be some parameters in place. For example, a vendor should insist on spending time with the client before handing over the keys. Further, I suggest putting a time frame on the experience too.

I can’t tell you how many times this has eliminated the sales cycle time. And, I believe the challenge of not knowing until after the purchase has been made.

So many software vendors, so Little Time

Market leaders or challengers? Cloud or data center? Evaluating enterprise software is difficult because there can be thousands of requirements and thousands of options too. Ultimately the selection comes down to this: how do you measure the gap between your particular requirements and potential software products?

For many, this can be answered by taking the time up front to step through the right process focused on what can be done but also how it is done too.

Do you have any questions or comments on the software selection process?  Please let us know how we can assist you.

Until next time, keep SmartThoughts in mind.

Free Software Advice for nonprofits

Do Groups Make Better Software Decisions?

Software decisions are challenging. And, Group Dynamics play a big role in finding the right software for your nonprofit.

It is no surprise to many that organizations rely on groups,teams, or committees to come up with a decision on software. In fact, it’s rare today to rely on a single person to make the software decision. In this short article, I wanted to shed some light on how group dynamics can be good and bad in making that very important software decision.

How to Address Group Dynamics in Making Software Decisions

Why are teams formed to make software decisions? I believe the thought process behind this is that while one person bases decisions on their own experiences and biases, a group applies their collective experiences and differing perspectives to come up with a better solution. In our opinion, it’s important to form a group to perform the software selection task, however, the leader of the group should realize that there are some negative consequences that may arise due to group dynamics in making software decisions. And, in order to provide the best overall outcome, various dynamics must be addressed before they become detrimental to the decision-making process.

The following are some of the most common negative dynamics based on psychological principles that can result in poor group decision-making, and a few smart thoughts on how to address them:

Lack of Strong Leadership

Weak leadership within a group often leads to one person dominating the process. This often leads to a lack of direction, shifting of focus away from the actual issue, or infighting within the team. The best way to address this is to designate a group leader or facilitator. This person should have great communication abilities, and have the skills and knowledge necessary to guide the group without becoming domineering. If domination occurs, it may require coaching of the leader to point out what is needed from the group as a whole. For example, in a recent software selection review at a nonprofit, it was clear that the Membership Director was the dominant player on the team. And, no doubt was going to do their best to persuade the group towards their departmental needs rather than that of the organization even if it meant giving up in other lessor known and “sizzling areas” like Accounting. In this particular case, we addressed it early on and avoided the derailment thank goodness!

Groupthink 

Groupthink occurs when members are more focused on everyone agreeing than they are with making the best decision. This dynamic often leads to a lack of exploration of possible solutions. The best way to deal with this dynamic is to ensure that emphasis is not placed on group harmony. Instead, the members need to understand that personal insights are needed in order to reach the best decision, and that dissent is an acceptable part of the process. This is an interesting psychological principal. It’s not common, for the “leading options” which are perceived to be the “easiest path of resistance” aren’t always best choice for the company. In other words, just because a software option has been around for a long time, doesn’t mean it’s always a fit for everyone.

Authority Deference 

When the leader of the group is a highly influential member of an organization or department, it can lead to team members agreeing, regardless of their own feelings, in order to be seen in a favorable light. This can be avoided in some cases by choosing a leader with a lower or less esteemed status within the organization with varying degrees of success. However, if this isn’t possible or a good idea, it may be worth employing a specialist in software selection to help here as well. In software decisions, there are usually many (siloed) initiatives in the works and it’s important to know that going into the process and during it.

Blocking

This occurs when there are members of the team that block decision-making by interrupting the flow of information. Common behaviors include aggression, withdrawal, negativity, & possibly unwarranted humor. This typically transpires at the start of the software selection process, however, can creep up at the tail end when a member perceives the decision going a different direction than they desire. When these behaviors are present in the group, strong leadership and coaching will be required to challenge the behavior. And, providing feedback to the member on how his or her actions are affecting others will be necessary, and often eliminates the problem. Across organization sizes, it’s important to have Executive Sponsorship and oversight. And, at the end of the day, be held accountable to the decision making process.

Groups can and do make good decisions. However, each of these dynamics pose a threat to the common goal of finding a software “fit”. But, they can be overcome if they are addressed quickly in group decision making. Monitoring behaviors in the group will ensure that these problems are identified before they result in negative dynamics. This will lead to improved information sharing, improved group dynamics in the software selection decision-making process, and a better software decision outcome.

If you may need help in determining the best software solutions for your organization, SmartThoughts would like to be apart of your group. Contact us today.

Until then, keep SmartThoughts in mind.

Nonprofit Software Dynamics play a role in the decisions for your organization. Be smart.

 

 

Playing Tug of War in your Software Search?

Nonprofit Software searches are dynamic. We explore the dynamics of groups here.

Benjamin Franklin said, “By failing to prepare, you are preparing to fail.” In my experience, nowhere is this truer than when working with a group in software selection. In this article, I explore the facets that “group dynamics” play in the search for nonprofit software.

“A review of the impact of group dynamics in software searches”

Years ago, I read an article in Moneywatch on group dynamics which suggests these tips for a productive group which seemed to resonate with me. Here are the major tips:

1. Set clear goals for the group.
2. Express your confidence in the value of group work.
3. Encourage each participant’s contribution.
4. Always remember to say thank you.

Further, according to one publication, each group member’s behavior can serve as a trigger to another’s behavior. No doubt that groups are a practical way for accomplishing tasks and solving problems. However, before you embark on “The Search” for software you need to know that your group assembled will require preparation and leadership to be successful. Below you will find five tips for minimizing the “Tug of War” aspect of software selection from my vantage point.

Know what must be accomplished

This topic was covered previously in another article but is worthy of a repeat. The group needs to know what the desired goals are in the pursuit of new automation. Without a shared goal, the group will get lost in the search. The group must collaborate to agree on the metrics which they will determine is success. And, then get realistic with your expectations, you won’t get everything.  Sorry!

Know your group

The culture of an organization influences the attitude of the group members. And depending on the role each participant plays in the group, it can be difficult to foster compromise and reach consensus. Group members can become competitive and territorial. It is important to observe body language and understand silences.

Know your audiences specific needs

These needs affect every member of the group. For example, the non-profit with an ineffective process for tracking memberships and conference enrollments will be looking for software that solves those problems–problems that affect the workday of each member of the group. Focus on these issues and work for buy-in from group members.

Know how to encourage common ground 

Demonstrate how each need can be met and encourage discussion and questions. It’s important that everyone knows that they won’t get every need met. Expectations need to be set that the organization is the most important aspect of the journey. It’s not one department which is going to use the enterprise software systems in place today. In other words, Membership, Events/Meetings, Development, IT, Executives, and your customers all are stakeholders.

Know how to make a decision 

Strong leadership supported by management will help group dynamics in making decisions. Also important to understand is workers who perform repetitive tasks in their jobs are averse to change. And, yes, the Executive Director and CEO of the organization need to play a big role in the decisions and software selection process! I am not a big fan of “voting” by consensus for the decision. Rather, I believe that boards place Executive Directors and CEO’s in charge for a reason, and they should with good counsel be prepared to make the final decision. They are the leader in pushing the objectives forward for the organization.

Finally, at the start and along the way a carrot needs to placed before the group. In other words, every participant needs to know why your going to change software systems and what are the metrics the organization and the key stakeholders (staff, constituents, board) hope to achieve. Knowing the specifics of how new software will make your lives easier will motivate everyone to participate constructively and enhance their willingness to buy in. And, know that the carrot needs to stay present throughout the selection, implementation, and usage of software. Therefore, during your “group pre-planning”, decide early on how your going to keep the momentum during the project and plan for it!

If you are searching for new technology or would like to explore how to improve your organizational efficiency in software selections, please contact us. We would enjoy helping.

Until then, keep SmartThoughts in mind.Nonprofit Software Dynamics play a role in the decisions for your organization.  Be smart.