Printer Friendly

Creating a Request for Proposal for Software for a NonProfit Organization.


As our society continues to embrace technology to enable more sophisticated means for communication and interaction, people have come to expect every organization to adopt and use increasingly more powerful and feature-rich software tools. This is true for companies who are offering web-based ordering such as grocery stores and restaurants, as well as non-profit organizations who must provide a reasonable user experience for their members. This can be problematic in non-profit organizations, especially smaller organizations, where contributed and earned income are often used to support human resources, physical facilities, and organizational programs, with little remaining money for technology investments. Non-profit organizations often seek ways to leverage their limited resources to achieve their goals. Using technology to help these organizations meet their goals is an effective way to ensure that investments have a positive impact.


The author's motivation to write this case comes from his experience in working with a non-profit organization to incorporate an increasing level of sophistication on the organization's website. When the author joined the organization, they had a website that had been developed in Microsoft's Front Page[R] and was essentially a web-based brochure for the organization. Over time, functionality was added, and the site evolved into a relatively sophisticated set of functions but lacked many of the features that were important to the organization. The author worked with key members of the organization to determine the best and most cost-effective way to add the desired functionality. Once this process concluded, it became the basis for a case used in a junior-level systems analysis class, focused on the classic "build or buy" problem. This case is slightly different from many of the business-oriented cases used in class because it uses a nonprofit organization with very limited resources as the client and introduces several concepts related to how unsophisticated users view system requirements.


This case is centered on Tri-State Flyers Club (TSFC), a club for people in a three-state area who fly remote-controlled airplanes, boats, and drones. The club has been in existence for over 30 years and has recently hosted its largest Fun Fly Day event where there were 160 participants in the drone competition alone and over 300 total participants from the region. The local park service estimated the total attendance at the event to be over 1,000 people, including flyers, their families and friends, and other spectators. The board of directors for TSFC is regrouping and discussing the success of the event, but also working to figure out how to avoid several snags that came up during the day of the event and during the month leading up to the event. As the board reviews how people signed up, how the event was scheduled, and many other details, they realize that most of the issues that proved to be problematic could have been resolved with software designed for the event. This leads to a discussion about other software needs for the organization, and the board concludes that the current website is not adequate for all the organizational needs. The TSFC board of directors decides to form a committee of interested members to determine how to improve their capabilities to manage the event next year and improve the functionality of the website for members while keeping the costs manageable for the organization.


4.1 Organization Profile

Tri-State Flyers Club is an organization that has seen significant growth in membership over the past few years. The club started in 1984 with a few friends who were interested in remote controlled (RC) airplanes, and over the first 10 years of existence grew to about 40 members. The club initially met in an open field of one of the founding members, and members would fly their RC planes, work together on building and fixing planes, and stay abreast of new ideas for equipment and techniques. As the club grew and the membership changed, the consensus of the club members was that they needed to apply for 501(c)(3) non-profit status and establish a board of directors. This allowed TSFC to more accurately reflect the preferences of the members and, because of a rotating board, the work involved in running the organization could be spread out so that one or two people were not responsible for all the activities. As soon as the non-profit status was achieved, the local park district approached the club and asked them if they would like to host a "fun fly day" adjacent to a local park to help draw people to the park and see all that the park had to offer. In exchange, they offered to let TSFC use the adjacent field for club flying activities. This was a major development for the club since they did not have any dedicated place to fly. The next major shift came with the rise in popularity of drones. It seemed like overnight, drones became the most popular Christmas gift, and many of the people who had them were looking for a place to fly them and looking for some advice on how to fly these new toys.

4.2 Website to Date

In about 1998, one of the members offered to create a website for the club using Microsoft's FrontPage[R] so the club could share photos of their planes and advertise special events. The website was popular and provided TSFC with more public exposure than it had previously enjoyed. The initial site had some contact information and some pictures of members' airplanes. It was updated every few months or when someone finished building a new plane. As the membership expanded, the club realized that several of the established members did not know most of the new members, and it seemed appropriate to add a directory feature to the website. The directory included members' names and contact information, as well as the types and models of their model planes and boats. After a few years, some of the members complained that they did not want their information on a public website, so a password and registration feature was added to the directory so that only members of the club could access the directory. From its inception until about three years ago, one club member was responsible for maintenance on the website and did the work at no charge as a service to the club. The member who originally designed the site retired from his job and moved to another state and subsequently is no longer able or willing to keep the site up to date. This presents a problem for TSFC since none of the current members has the expertise to actually work on the code for the site.

4.3 Fun Fly Day

The partnership with the local park district that provided a fulltime place for members to fly in exchange for hosting the Fun Fly Day was a turning point for the club. The event generated the first earned revenue for the non-profit organization. Prior to that event, all revenue was contributed revenue based on member dues and a few corporate sponsors. For the first few years of the event, the revenue was used to pay a part-time employee who helped with coordinating the event. For the past two years, the event has been increasing in size because of the rising interest in drones and drone capabilities. The event evolved from being mostly a demonstration of RC airplanes to several competitive events for fixed wing models and for drones. The competition provided some much needed motivation for participants to attend and vie for the recognition of first or even second place finishers. The park district was pleased to have large crowds for the event and used it to raise revenue for the park by renting spaces for food vendors and other vendors. This created even more traffic and raised the profile of the venue, making it profitable for the park district, TSFC, and numerous vendors from the area. There was also an influx of people staying in local hotels, eating in restaurants, and spending money in the area.

The challenges in putting on the event are related to registration, scheduling, and organization. The process for registering was set up when the maximum expected attendance was less than 50 participants. Most of the participants were club members, and they signed up to fly at one of the regular meetings before the event. Non-members would fill out a form that indicated what type of plane they would be flying and mail it to the club to get on the flying schedule. The schedule was published a few weeks before the event, and flyers would show up a few hours before their flying slot to watch others and get their planes ready. As the levels of participation grew and different types of competitive events were added, the complexity of the event outgrew the capability of the paper-based process. This year there were several times when participants did not know when their event was scheduled, or in some cases showed up at the wrong end of the flying field. It was not chaos, but it could have been much smoother. These glitches were the tipping point for the board to begin considering some more sophisticated event management software.

4.4 The Project Team

In the debriefing session following the Fun Fly Day, the TSFC board of directors met to discuss how successful the event was and what could be improved for next year. The discussion quickly moved into how the current software, a web-based membership directory with a few other features, did not allow the organization to manage an event like the Fun Fly Day. There were other processes identified such as how dues were collected and how member photos were shared that were less than ideal. The consensus was that the board needed to appoint a team to look into what to do about these needs and make a recommendation. After discussion, the board formed a three-person team to figure out how to proceed and provide the board with some options to consider.

The obvious choice to lead the team was Susan Rogers. Susan was an engineer with a nearby manufacturing plant and her aptitude with mechanical devices had guided her in her interest in using drones for various industrial and recreational purposes. She had become an active member of the club just as drones started becoming popular and had been very helpful in working to make the Fun Fly Day a success. She understood the challenges of the event, was as committed to club success as anyone, and had a significant amount of technical expertise. Susan agreed to lead the team and eventually called the first meeting.

Another person who was expected to work with the team was Bart Livingston. Bart had been with the club for more than 10 years and spent a lot of time volunteering to do organizational tasks such as mail outs, tracking member dues payments, and keeping the banking records. Bart understood what needed to happen in the office to make the organization run, and he was looking forward to getting some help to automate some of the tasks that he was doing on spreadsheets and on paper.

Mark Garcia joined the team because he was one of the most respected flyers in the club. He was always on hand to help new pilots learn the best flying techniques, and he had helped lots of flyers avoid crashes by coaching them and sometimes taking the controls at a point where all seemed lost. The board wanted Mark on the team to make sure that the everyday flyers' point of view was considered in the decision making process.

The board also discussed what type of budget to earmark for software. There was a consensus that this was a very important step for the organization, and after considering the range of possible costs, the board agreed that about $4,000 per year seemed like a good starting budget figure. Most of the board members hoped that it would be less and to spend that much the software would have to be very good.

In the initial project team meeting, Susan began by suggesting that each person investigate an area of concern, then report back to compare notes and get an idea about what the organization needed, then move forward from there. Each person selected a group to work with to find out all the tasks and features that the club might need. Susan's area was the Fun Fly Day. She expected to talk to some participants and the park district employees, then review some documentation on the registration and scheduling process. Bart's emphasis would be the everyday activities of membership management. He would take a look at the office-type operations and identify processes that could benefit from automation or use software to make the process easier on him and/or easier on the members. Mark's task was to discuss possible functionality that the members would like to see in a new website. While that was an open-ended question, the team felt it was important to hear from several members about how they wanted to see the organization move forward in this area. With these assignments, the team set out to discover just how big expectations could be for a new website.

4.5 Unexpected Assistance

It was not unusual for Mark to work in his shop on Saturday morning, tinkering with one of his planes or getting ready to head to the park for a day of flying with his fellow club members. One of the new members, Pete Waters, had gotten Mark's number from the directory and, because Mark had a reputation as an expert and a willing tutor, Pete called Mark up this particular Saturday morning to see if he could get some help with a plane he was trying to build. Mark headed over to Pete's garage to see if he could help solve the problem. After an hour or so of looking at the instructional drawings and measuring the balsa wood in the plane's frame, they both agreed that the drawing must be wrong. The servo that controlled the ailerons could not be attached using normal pushrods with the current configuration. Mark suggested using a balsa wood shim to move the servo mounting point up, so that it would clear the fuselage. It took about 30 minutes to put the fix in place, and while the glue was drying, Mark began getting to know Pete. Mark found out that Pete worked as a business analyst for one of the big financial services firms. Pete explained that his job often involved moving clients to sophisticated accounting or financial software from smaller systems. The projects often took several months to complete and he had been doing this type of work for nearly five years. Mark explained the software project for TSFC to Pete and asked if he might be willing to offer some advice to the team working on the project. Pete was grateful for Mark's help in solving his model building problem and jumped at the chance to return the favor. Pete knew that a group of well-meaning volunteers could probably use a little help from someone who implements software systems every day.

4.6 Needs and Wants

After a few weeks for the team to gather information, Susan called a meeting. With Pete on board, everyone felt a lot better about their chances for success. Susan suggested that each person give a report on the needs and wants they identified and Pete offered to take notes for the group since he had not really done any investigation.

Bart began with, "I'd like to share my finding first if you don't mind. There are a few features that would really help us in the back office, and I also have some things that would be nice but are not absolutely necessary." Bart explained that one of the biggest hassles with the event and with annual dues is getting checks or cash to the bank. Keeping up with the money had become a fairly big time commitment, and it seemed that including the ability to process payments online would go a long way toward solving that problem. Everyone agreed that automated payment processing should be among the high priority items for the new website. In a related area, Bart explained that if the new system could manage the membership dues invoices by automatically sending out an invoice or notice when the dues were due, it would take another big chunk of the work off of Bart and other volunteers. Bart explained that after reviewing the paperwork required to track dues, any automation would probably make the process much more accurate. The other functionality that fell under "would be nice to have" included the ability to email members with announcements or newsletters and the ability to create groups, such as the board of directors, drone flyers, fixed wing flyers, and watercraft members. Bart also suggested that having a calendar posted on the site with upcoming events would help.

Next, Mark reported on his conversations with several members. He said, "When I told people that we were looking at upgrading our website, every single person said something positive. Our site is really out of date and lacks functionality." Mark reinforced Bart's idea of online payment processing, saying that members want to pay online and even sign up for automatic deductions so that they do not have to initiate the transaction each year. Mark also talked about a couple of people asking about a mobile app for the club. They want to use an app to upload pictures and even videos that would show up in some kind of social media format or feed. One of the members suggested using an existing social media platform and creating a page for the club as an alternative to including it as a special feature.

Finally, Susan described her findings from discussions with the park service and Fun Fly Day participants. She began with,
   The park service is most interested in making sure that
   everyone knows when their events are scheduled and
   that participants know where the event will take place.
   They even offered to include something in next year's
   budget to support the event.

Susan also shared that a couple of the participants worked for companies who might be interested in sponsoring the event next year. Bart interrupted with,
   I wonder if there would be some way to organize our
   efforts at getting donor and sponsor support with some
   kind of software. I know that other non-profits rely on
   fundraising and use programs to track giving, maybe
   we could add that to our list of "nice to have" features.

Everyone agreed that if TSFC was going to effectively handle sponsorships and donations, some type of resource development software would be very helpful. Susan concluded by saying that people asked about using a mobile app or responsive website that would be accessible from their smartphones during the Fun Fly Day.

4.7 Putting it all Together

Once the team had finished sharing the input from everyone, Pete stepped in to fill in a few blanks. He summarized the list of features and then said,
   You have all done a great job in listing the specific
   features that you want, but there are a few ideas that you
   should consider as you move forward. I'd like to offer
   to put all these requirements into a document called a
   request for proposal or RFP. What we do in our
   company is that we write up all the things we want into
   an RFP, then send it out to several potential vendors and
   ask them to send us a proposal that describes how well
   their software or services will fit the needs we have
   described. This process will help us narrow down the
   possible vendors to those who have a reasonably close
   fit, and we can move on to demonstrations and
   comparing only those products that are a good match
   for us.

Of course, the team immediately accepted Pete's offer. Pete wanted to cover a few other ideas that the team had not yet discussed, so he gave the group a high-level description of why they might want their new software to be hosted in a cloud-based environment. He said,
   If we use a cloud-based hosting service, we can run on
   a minimal amount of computing power for most of the
   year with no more than 15 or 20 concurrent users at any
   time. This is fine, but on Fun Fly Day, we could have
   several hundred people accessing our website via a
   webpage or through a mobile app, which could slow it
   down too much or even cause it to crash. With a cloud-based
   service, we can add computing power just for the
   day, or for the few weeks before the event, and make
   sure that we have a fast response time and plenty of
   bandwidth during the event. Then after it is over, we
   can easily go back to our minimal configuration and
   only pay for the computing power we need.

None of the team knew that this was an option, but all agreed that a cloud-based platform seemed like the best way to go. Pete also described the importance of a secured, encrypted administration portal, and that a feature to back up the data was a must. The last thing Pete suggested was a content management system or CMS. This would allow someone to add content items like advertising for the Fun Fly Day or pictures from other events to the site without any special programming. He also emphasized how important it is to get a system that is easy for Bart (who did most of the hands-on record keeping) and other volunteers and members to use.


5.1 Summary

The situation described in this case provides sufficient material for students to create an RFP designed to reflect the needs of TSFC. The author's goal was to outline needs common to many non-profit membership organizations in a way that reflects how non-technical people perceive and communicate their needs for software functionality. The task for the systems analyst is to translate these needs into specific software requirements in a way that will be clear to potential vendors. This case study allows students to explore several areas of functionality for the case organization and learn how to best combine and describe the requirements for an external vendor.

5.2 RFP Best Practices

RFPs are used in many industries. While the case above focuses on software for a nonprofit organization, any organization who is considering purchasing software from a vendor may use an RFP to help make the best decision among competing vendors. RFPs are also used for non-software items such as specialized equipment, customized services, and many other big-ticket items. Regardless of whether the RFP is directed toward a software project, an equipment purchase, or any other service, there are some important best practices that tend to make the process much more likely to achieve the desired results.

Before starting the RFP process, Hayhurst (2017) recommends assessing whether the RFP is an appropriate tool for the procurement process. Software purchases that will be significantly expensive when considering the total cost of ownership and will have numerous specific requirements are more likely to benefit from the RFP than those with standardized features available from many vendors. The RFP process itself can become expensive due to the time investment by qualified evaluators who are familiar with the requirements, so the RFP may not be the best tool in every purchase decision. Once the decision to use the RFP is made, a key early element is to determine the timeline for the process so that it can be communicated to candidate vendors (Baruch, 2012; Hayhurst, 2017). The timeline is important for internal workers as they generate the RFP and evaluate responses, and it is important for candidate vendors so that they can respond prior to the deadline if they want to submit a proposal.

In developing the detailed requirements, it is important to consider issues beyond simple functionality. In many situations, the system under consideration may need to be integrated with existing software or operate in conjunction with other software. The interoperability aspect of an RFP should be stated if it needs to be considered in the purchase decision. The ability of new software to work with existing software also highlights the potential for problems with internal business processes which may cross software package boundaries. In parallel with documenting software requirements for an RFP, those involved should consider how new software might streamline or confound existing business processes. The exercise of evaluating the impact of new software on business processes has the potential to draw attention to potential changes in desired employee skill sets and in roles and responsibilities. When appropriate, these issues should be discussed and considered when drafting the RFP (Hale and Deutsch, 2017).

With respect to the RFP document, Baruch (2012) suggests that it should be constructed using concise, bulleted lists in the detailed requirements area, with graphic images and relevant visuals to provide an inviting feel to the document. Templates are available from a variety of sources that provide a good starting point for RFP documents. If a template is used, the writer should customize it for the particular purpose of the RFP.

In addition to providing information about the organization requesting the proposal, questions about potential vendors may be important to the decision process, but may not necessarily fall into the category of detailed specifications. Examples of this type of information might be the location of the vendor's headquarters, how large their customer base is, how many people work in their support department, or other information about the vendor. These vendor related items can help in evaluating proposals that may be similar in their functionality but where one respondent is clearly better than another because of an important aspect of their company (Hayhurst, 2017).

5.3 Evaluation

The case was drafted and distributed to students in a junior level systems analysis and design class at a public, regional university in the United States. This case has been used in 3 semesters with an average of 18 students in each class. In the second and third iterations of the case, assignments were modified based on student performance in the first and second iterations. For example, in the first semester, several students asked questions about facts in the case, so in subsequent semesters the case included additional facts that clarified certain aspects of the case. In the most recent iteration of the case, students were assigned the case after receiving instructional materials on how to develop a request for proposal (RFP) and taking a quiz on the elements of an RFP. Students generally performed well in the most recent semester with 81% earning an A on the RFP assignment, 16% earning a B, and 3% earning a C. The assignment was scored using a rubric that evaluated the various aspects of the RFP including the functionality, level of detail, structure, and completeness of the deliverable.


Baruch, T. (2012). Crafting a Request for Proposal. Multilingual, 23(5), 36-38.

Hale, A. & Deutsch, J. (2017). Best Practices in Tax Compliance Outsourcing, Start the Journey with a Well-Designed RFP. Tax Executive, 69(5), 32-37.

Hayhurst, C. (2017). How to Develop an RFP: A Request for Proposal, or RFP, is a Tool Practices can Use to Make Informed Purchasing Decisions. PT in Motion, 9(7).


David Reavis is a professor of MIS and Management at Texas A&M University-Texarkana. He earned his BBA from Southern Arkansas University, his MBA from Texas A&M University-Texarkana, and his Doctorate in Information Systems from Nova Southeastern University.

David Reavis

Department of Management Information Systems

Texas A&M University-Texarkana

Texarkana, TX 75503, USA
COPYRIGHT 2019 Journal of Information Systems Education
No portion of this article can be reproduced without the express written permission from the copyright holder.
Copyright 2019 Gale, Cengage Learning. All rights reserved.

Article Details
Printer friendly Cite/link Email Feedback
Title Annotation:Teaching Case
Author:Reavis, David
Publication:Journal of Information Systems Education
Geographic Code:1U7TX
Date:Mar 22, 2019
Previous Article:Strategic Actions in a Platform Context: What Should Facebook Do Next?
Next Article:Why do Students not Major in MIS? An Application of the Theory of Planned Behavior.

Terms of use | Privacy policy | Copyright © 2019 Farlex, Inc. | Feedback | For webmasters