Technology projects must function in the environment(s) in which the party plans to use them: for example, an internal communications tool will not do much good if it requires an online connection unavailable to many users. Additionally, if a party is in a country with spotty electricity and lacks a generator for backup, relying on technology may not be cost or time effective. Likewise, technology needs to match the security environment that a party operates in; if the government in power is spying on the party’s work or is actively trying to undermine it, application security will be a central concern. For more information, please see the understanding your tech environment section. For a list of different tools that can help parties enhance internal communication, please see the Common Internal Communications Channels worksheet.
Technology projects rely on another kind of infrastructure: human skills. People design, build, configure and maintain software and hardware, and the types of projects a party can successfully undertake depends significantly on the strength of the technologists upon whom it can call. If a party chooses to enlist a type of technology that only a handful of people in the country have expertise with, the party would not be able to maintain the technology over time if those people become unavailable. A party should carefully match the technologies it chooses to the talent available to build and maintain them. For more information on understanding different environments and the challenges therein, please see the section on common tech environments.
In many cases, even when technology tools and personnel are available, the cost of employing them can be prohibitive. Parties need to consider the hidden costs of a given tool, from hiring vendors and purchasing the product to the cost of employees utilizing the tool over the long term. These costs can detract from other party efforts, and are often overlooked during busy campaign periods. To better understand the short- and long-term costs involved in hiring a tech firm, please see this worksheet; to better understand the hidden costs involved in using custom-built tools versus open-source technologies, please see this worksheet.
Another important consideration is whether technology reaches and is available to women. For example, in some cases women can not go into public internet cafes, do not have control of the use of a mobile phone or simply are not taught how to use computers. Assuming equal access to technology in any environment may mean the party’s message is not reaching much of the population. For more information on women and technology, see NDI’s report on Women, Technology and Democracy.
Levels of access
What levels of access will the system require? A party must assess if the program will be a staff-only application, used exclusively on desktop computers in the party’s headquarters, or an online application that many different users can access remotely. Additionally, depending on the tool’s purpose, a party may consider giving members of the public access, as well. Some tools have different levels of user access, with basic users able to use some features but not the full power of the tool. Many data management systems, for instance, allow lower-level staff to access information but not edit it. These questions have obvious security implications.
Once a party has identified the specific goals of a technology project, it should work with technologists to develop a clear list of features to be included in the project. For example, a mobile phone app for party members might include mechanisms for viewing the party’s policies or platforms, watching videos of party events, voting on party initiatives, obtaining talking points for outreach and persuasion, and accessing a GOTV training curriculum.
Details matter. If each main feature has several sub-features, the lower-tier attributes should also be defined carefully. Disagreements over expectations are a common source of problems between technology vendors and their clients, and beginning by clearly defining the features the party expects to receive as part of a particular technology project can help avoid confusion and conflict as the project proceeds.
One reason specifications are important is the problem of “scope creep,” in which a project designed to solve one set of problems gradually and almost unconsciously morphs into something much larger. For instance, the party might ask to add features one-by-one during the development process, and while individually, none require much additional time or resources for the technologists to implement, collectively they might change the direction of the project significantly. Parties should therefore be aware of each little addition and make sure that over time, these small additions and delays do not cause significant changes to the project’s budget and timeline.
While scope creep is obviously a problem for technology vendors, who wind up performing additional work without a prior discussion on costs, it is also a problem for the political party: scope creep is a major cause of missed deadlines and late projects. Having a clear specification document at the beginning can keep projects on time and within budget. Further, having clearly delineated goals will also help prevent a party from making changes that do not contribute to the predetermined strategy.