As a grantmaking organization, do your grantees sometimes ask you to fund software development, but you are unsure how to evaluate the scope, budget, or potential impact of these types of projects? You are not alone with this concern; at Azavea we’ve worked with both implementing organizations and funders, and we know that this information asymmetry can be difficult for funders. We therefore created this list of the key questions to ask when evaluating a software development proposal.
Organizations with a plan for implementing their vision, have the best chances for success. This includes the skills, experience, equipment, staffing, and partners to complete the project. A few questions to ask are: Has the organization ordered custom software before? Do they have a technology partner lined up as part of the proposal? Have they carved out staff time to work with the software vendor? If you can answer affirmatively to these questions, it is more likely that your grantee has a realistic expectation of cost and effort needed to execute this project.
Does the proposal clearly identify the expected users of the new software? Does it include those users in the development process? In line with design-centered thinking, it is important that end-users are consulted in the creation of new software. This should explicitly take place during the discovery and user testing states of the software development process.
Many organizations believe that they know exactly what their planned application should do, but this rarely turns out to be correct once real users begin interacting with the application. An overly detailed scope can lock the organization into implementing features that users don’t want or need. It’s important that the scope of work contains enough flexibility to accommodate changes to priorities based on user feedback.
If too much flexibility would make it harder to move the grant through the approval process, you can always suggest starting with a smaller discovery, design, and planning project whose outcome will be an implementation scope and plan. The implementation plan will still need some degree of flexibility, but the design phase will provide clarity around users’ needs, which will allow the implementation scope to be more concrete.
Many organizations have ambitious goals for their software projects. Being ambitious can be healthy in impact-driven organizations, but attempting to include too many features in a new project is inviting disaster. Every new feature included in a project adds complexity, which increases risk and maintenance costs. A limited scope that focuses on solving one or two problems for a core group of users is most likely to be successful. You can always suggest a phased approach where you start with a focused scope to fund the highest priority features and provide funding for future enhancements through additional phases.
The factors above deal with a software project’s planning and implementation. However, the way a project is treated after it is released is also crucial to whether it has its intended impact. Here are some indications that a grantee organization is thinking about the long-term sustainability of their project:
With software, if you build it, there are no guarantees they will come. To ensure a project will have its intended impact, there must be a plan to get it in front of users. Are there line items for a marketing plan, execution of that plan, and any associated costs?¬†
Key performance indicators should be identified before custom software is developed, so that everyone understands how success will be measured. Once defined, these KPIs should be tracked through a tool like Google Tag Manager. When the tool is live, be sure the grantee has a plan to react to the insights learned via the tracking tool.¬†
As with physical infrastructure, custom software has capital costs and maintenance costs. As a rough guide, a software project under active development (that is, new features are being added) requires roughly 10-20% of effort be devoted toward maintenance in order to be successful. In other words, if a product’s initial build budget is $100,000, then something like $20,000 of that should be expected to be used to address maintenance costs.
It’s important to emphasize that software projects begin incurring maintenance costs from the time development starts; if maintenance costs are ignored early on due to budget or time pressures, the project can incur “technical debt,” which is essentially deficiencies in the structure of the software.
Asking these questions should bring you clarity when evaluating software development proposals. Grantees who request funds for software development and have ticked off the above boxes are the most likely to implement successful and impactful software and ensure that your money is being put to good use.
If you‚Äôre looking for a technology partner on a project, or want to talk more about evaluating software development proposals, reach out!