Back to Resources page
	Planning Projects for a Shoestring Defining Software to Account for Limited Resources Software projects, such as websites, databases, and applications, should be designed to accommodate the money, time, people and other resources available. This article outlines ways that organizations and technologists can define their functional needs, understand their resource limitations, and creatively plan the best possible system given the available resources.   Introduction More and more nonprofit organizations are hoping to address serious needs through technology solutions, but have only limited time, money, and other resources to use in this type of project. This difficult situation can sometimes prompt unfortunate results. Some organizations assume that technology simply isn’t an option for them. Others - worse - rush to the cheapest solution they can find in an attempt to save time and money. This “price first” mentality can result in systems that are worse than nothing – that don’t fulfill the organization’s needs, and take vast resources to use and maintain. The problem is compounded by technology professionals who aren’t well equipped to account for resource limitations. A technology-centric focus on bulletproof reliability, efficiency of design, and cutting edge technologies can result in systems that are more expensive than they need to be. It is very tempting, as a technologist, to jump to a “right solution” based on the organization’s general needs and technology best practices. But this “right solution” is the wrong solution if the organization can’t afford to build and support it. Certain questions need to be asked to ensure the solution is really appropriate: What specifically is the need? What resources are available? And can we creatively define a way to meet the need with these resources? This article focuses on the steps that organizations and technologists can take to plan the best system possible given the available resources. It encourages a creative process to think through various options, rather than starting the project with a rigid definition of the technology solution. Because the article focuses on projects with reasonably narrow goals and audiences, it applies more to software projects – such as websites, databases, or software applications – rather than hardware projects or full technology plans. Understanding Your Needs Before deciding on any technology solution, it is critical to carefully define what the technology is needed for. How does it support your mission? Who will it help? What key business level tasks should it accomplish? It is tempting to start with a technical solution in mind (“We need to build an Access database to track who we are serving”). This approach, however, puts the cart before the horse. Perhaps a different approach – say, a packaged tool, or a database backed intranet site, a spreadsheet, or even an index card file – will serve your goals as well or better for considerably less cost. If you start by defining your needs, you can brainstorm many options that fill these needs in different ways. Defining your needs, however, is easier said than done. It is important to outline your needs with requirements that are both specific enough to exclude ill-suited options, but also flexible enough to include options that use technologies that you’ve never considered. I’ve had success in defining requirements through a sequence of simple steps: Define high-level goals. Think through what the system is intended to accomplish. Should it increase the number of donations? Decrease the costs of communicating with constituents? Reinforce the public’s opinion of your organization as professional and cutting edge? You will likely have a number of goals – which goals are the most important, should they be in conflict? Define the audiences for the system. List the people who will use the system. Will the system support internal staff? Be a resource for donors? Provide information to the public, or to the press? Again, prioritize your audiences to determine which should get the most attention. Talk to people who will use the system. Take a couple of hours to talk to people in your most important audiences. I find that talking to at least two or three people invariably provides valuable insight. Ask them how they currently accomplish the tasks that you intend to support, and find out their top priorities are for the system. Their priorities will likely be quite different than your organizational goals – for instance, while an organization may want to raise money, a donor is more likely to want to find information about worthwhile organizations than to actually give money. Talk through functionality as a group. Armed with key information about goals and audiences, pull together a group of people – both technology and program staff, ideally including some people who will use the system – and brainstorm possible system functionalities. Try to focus on system results rather than implementation methods. For instance, a result would be "to allow kids to research detailed information about dinosaurs", rather than "to provide a searchable database of dinosaur information" (which is the implementation method). Talk through security and reliability as a group. In addition to user functionality, talk about security and reliability needs for the system. Does it need to be up 24/7 without fail, and be invulnerable to sophisticated hacker attacks? Or is it sufficient if the system is available 95% of the time during working hours, and casual browser will not stumble into it by accident? How serious are the impacts of security breaches and availability failures? Is there sensitive or controversial information in your system that would make you a target for attacks? Very reliable and secure solutions are usually also very costly. Write up your requirements without reference to technology. Create a one- or two-page document with your results-focused list of requirements. Perhaps in addition to researching dinosaurs, kids should be able to create a page describing their favorite dinosaur, and be able to take home a copy of this page. Perhaps the system needs to be up 99% of the time on three specific days a week. If you have included non-critical requirements, prioritize the list to determine which are Core requirements (i.e. no point in creating the system without) and which are High, Medium, or Low priority requirements. There are books specifically about defining technology requirements, and people who make their careers in this field. It can be helpful to bring in an external consultant to lend an outsider’s perspective and help facilitate your requirements definition process (perhaps allowing low-cost solutions that save more than the cost of the services). But at the end of the day, this process isn’t brain surgery. Whatever you can do to define your needs will be a significant improvement over simply starting with a technical solution in mind. Understanding your limitations As some great philosopher should have said, understanding your limitations is the key to designing for them. If you take the time to think through the available resources, you can design and prioritize accordingly. This sounds obvious, but it is frequently difficult to get a handle on just what is possible and what is not. It’s worth the effort to list out and define the project limitations before doing any substantive project planning. There isn’t much money? Okay, exactly how much is there? Your people aren’t skilled in technology? Okay, what can they do? Can you supplement skills with additional people? Documenting limitations makes it much easier to see where there is room to explore, and where there is no wiggle room at all. Carefully considering your resources also lets you find places where trade-offs are possible. Often, resources in one area can make up for limited resources in others. For instance, money can be used to buy people’s time or infrastructure. On the other hand, committed and skilled volunteers can help considerably when money or internal resources are tight. As you think through your resources, be sure to consider these possible developmental limitations: Time and Money. The old favorites. Although difficult, it is worth trying to quantity what is meant by “no budget” or “as little as possible.” These phrases are used to mean anything from tens of thousands of dollars to literally no money at all. Existing Technology. It is rare for a project to have free reign with technical choices. Organizations may have existing hardware and software, or hardware and software standards, that constrain what can be used. Determine what these limitations mean, if anything, from a functional perspective. Development Team. Significant budget restrictions can mean building a system with semi-qualified resources – people learning on-the-job, “accidental” technologists, or volunteers. If you understand the skills available to the project, you can tailor the design and level of complexity to the strengths of your team. Hardware and Software. Some designs dictate specific hardware or software decisions. If there is no budget for new purchases, you may need to tailor the design to the products already on hand. Politics. Unfortunately, political limitations are often a reality. What will your organization approve? What are you able to fund? These developmental limitations will affect the core decisions for the project. For instance, what should the scope of the project be? Can you include functionalities that rely on a specific technology? But these limitations are only half of the equation – perhaps the less important half. It is also critical to consider the cost, in time and money, of long-term use and support of the system. It is easy to overlook these costs, as they tend to be farther down the road from the planning process. The costs incurred from development through the life of the software are frequently called the Total Cost of Ownership. Think through the long-term costs that you will be able to support in these areas: Time and Expertise to Administrate. All systems will need to be monitored and many will need constant updates. It is critical to consider the ease of administration when designing, and the cost of administration down the road. The development costs for administrative tools (content management tools or administrative reports, for instance) and the time required to maintain systems can easily rival the development costs for the entire front end. Training and User Support Costs. The system will not be effective unless everyone involved – both administrators and front-end users – know how to use it. Training and user support can be a significant portion of the development effort, and should be weighed against resources needed to create easier-to-use functionalities. Hardware Support and Limitations. The methods used to host and support your system can impose significant costs and limitations. For instance, hosting a website on a shared public server can be cheap, but often limits your software options (as many software can’t easily be installed onto a shared server). Maintaining servers and databases in-house allows more flexibility, but requires skilled staff for setup and maintenance. Deployment Costs. Deploying the system to user desktops – to ensure everyone has access to the application - may require an additional investment. It is important to weigh this investment against the time and cost required to make the system easier to deploy. Other Ongoing Costs. Many services that decrease development or administration costs (such as application service providers, licensed content, or the like) incur monthly or other ongoing costs that should be factored into the budget. These long-term limitations can have as significant an impact on your planning as the developmental limitations. For instance, it may infeasible to train hundreds of end-users – which would then necessitate an extremely self-explanatory or less complicated system. Or the necessity of hosting a site cheaply may rule out the use of a sophisticated packaged content management system. Weighing your options The next step in the planning process is to brainstorm overall structure and technology options at a high level. The options can then be evaluated against the project requirements and resources. The overall structure and technology options are the type of options - frequently assumed rather than discussed - that define what the project is. Does it have to be a website? Could it be an Excel spreadsheet? A mailing list? What is the core structure? Can we buy something rather than build from scratch? I find it very valuable to brainstorm these high-level options with a group (with at least a few people with significant technology experience). The options worth looking at will obviously depend on the project, but it is usually worth considering these high-level questions: What technologies could be used to achieve the goals? For an organization with little money or technical expertise, goals might be met as well or better with unsophisticated (but practical) tools like email, Excel, or paper. For instance, monthly updates could be provided via an email mailing list rather than requiring a website to be frequently maintained. If an organization needs to consolidate monthly numbers for many locations, perhaps they could be emailed and uploaded by a central resource rather than entered into some kind of (more costly) decentralized system. Carefully consider your needs and the actual benefits provided by cutting edge technologies. Can we use a packaged tool? In my opinion, the most common nonprofit technology mistake is to build from scratch when a suitable tool is already built and available. Nearly all my clients assume that their needs are unique and can’t be supported by packaged tools– and only very few are right. For common functionalities (like searching, registration, or contact management, for example), using packaged tools for at least pieces of the system can utilize resources better than building from scratch. For instance, web-based search tools like Atomz or SpiderLine, or contact management tools like eBase provide advanced features at an infinitesimal fraction of what it would take to build this functionality. Can we template it? Systems where many page are structured identically can support a lot of content while minimizing development work. This is particularly valuable when designing websites. For instance, if you need to provide contact information for hundreds of organizations, you can create a single “Organization Page” template that defines the information displayed for each. The information for each organization can then be pulled from a database, to create hundreds, or even millions, of organization pages with no additional technical effort (someone would have to enter and administrate this data, however). This template model can support large and powerful application at a relatively low cost. Can we make use of standard designs? It is possible to pull detailed designs and even open-source code for common functionalities, if you are willing to work within generally accepted standards. For contact databases or shopping carts, for instance, you can leverage many readily available resources if you refrain from re-inventing the wheel. Can we build something useful with the resources we have? At the end of the day, do your resources allow you to build something that meets at least some of your needs, without causing more problems than it solves? Maybe it would make more sense to try to raise more money. It’s important not to throw away your resources on something that can’t be achieved. Once you have generated a list of possible options, you can weigh them against each other. Put them into a spreadsheet, and rate them on their support for your key requirements, and on all the important limitation considerations for your project (i.e., cost, ease of administration, ease of training, etc.). As you consider them side by side, one will likely pop out as the right answer for your particular situation. The main advantage of this approach is that you can rationally weigh the tradeoffs of each option. For instance, you might consider saving development time and cost by asking your (quite savvy) administrative team to do site updates in FrontPage instead of using a content management system (CMS). This will require more time from your administrators, and more skilled administration resources, but might make sense on the right project. Creative tradeoff management can be the key to designing a system that can be built on a shoestring, but careless ones can often lead to disaster (i.e. We’ll recruit my neighbor’s son’s girlfriend to build and host the contact management tool in her basement – and then it’s free!). In Defense of Planning All this planning can seem intimidating, time consuming, and costly. “If I could go through this whole procedure,” you may be saying, “I’d have the time and money to just build what I want, without worrying about my limited resources.” And it does take time. This whole process, as I’ve outlined, requires about three two-hour meetings for a mid-sized project, plus the time to talk to users and research potential solutions. But this investment of time is paid back many times over as you build, use and maintain your system. Because you understand your needs, you can brainstorm an option that is much cheaper than you would otherwise build. As you’ve thought through your limitations and long-term costs, you can be sure that you have a solid handle on the Total Cost of Ownership for your system. And the work you have done gives you a head start on the detailed design of your system. At the end of the day, the resources required for the planning process need to be weighed against cost of not planning. What is the cost of building and maintaining a system that does not provide any benefit to your organization? For More Information So What's the Real Cost of Technology? (www.summitcollaborative.com/NPQ_Cost_Technology.html) A good overview of the Total Cost of Ownership concept by Summit Collaborative. Designing for Limited Resources (www.boxesandarrows.com/archives/designing_for_limited_resources.php) An more detailed version of this article, written for an audience of professional software designers Exploring Requirements: Quality Before Design, by Donald Gause and Gerald Weinberg (View this book at Amazon) An easy-to-read book that gives a great overview of the traditional requirements definition process, including working through resource limitations. Contextual Design, by Hugh Beyer and Karen Holtzblatt (View this book at Amazon) A more detailed book with an excellent process for user-centered planning. These methods ensure that you define something that will be valuable to the users. About Alder Consulting: Alder creates powerful websites and databases for prices that nonprofits can afford. For more information, see www.alderconsulting.com, email us at laura@alderconsulting.com, or contact us at 718-208-8172.