Planning and Rollout

4465649986_e9c7b6ea1c_zOnce a party has developed its goals and determined which ICTs can help it meet them, it must devise an implementation plan, which is essentially a roadmap for what needs to occur for a goal to be met.

Well-designed goals are specific, measurable and time-bound. If a party has been diligent in its goal-setting process, it should already have an endpoint in mind for its implementation plan. Consider a party whose goal is to centralize its member database and transfer it to a cloud-based system within two years. After setting that goal, the party would develop an implementation timeline. First, the party would create a list of the steps required to reach its goal; each step would be a discrete task on the path to the overall goal. Those steps might include:

  • Purchasing the software package;
  • Completing any required customizations;
  • Training branch office staff on how to use the system;
  • Training system administrators on how to manage and update the system; and
  • Loading member data from the national headquarters and all 20 field offices into the system.

Once it has listed the necessary steps, a party can work backwards from the endpoint to determine which steps need to be completed by what time. In the above example, in order to centralize all data in 24 months, the party would need to know when the software must be purchased, how long the customizations would take and their deadline. Using this information, the party would be able to create an implementation timeline. For more information on implementation timelines, click here.

A good implementation plan details who is responsible for each element of the plan. It is relatively unusual that one person would have the sole responsibility for implementing the entire plan. More commonly, an individual or small group is responsible for each discrete step. It is critical to ensure that the people assigned to each task have the skills, expertise and experience to accomplish it. In some cases, it is necessary to bring in outside experts or provide training for staff. For example, it is unlikely that a political party would have a staff member with the expertise to customize a database software package. However, once the customization is complete, staff members could learn to train members on how to use the system.

The final element of the plan is the budget. Budgets outline the financial commitments required to implement a new project. A party must remember that the up-front cost or monthly service charges of a new software program are seldom the only expenses associated with a project. Staff time, training, maintenance and upgrades are just a few of the additional costs that a party should consider. This worksheet asks parties questions to help them think through all possible expenditures, in order to ensure they have as reliable a budget as possible. A typical budget might include the following elements:

  • 13538577304_8f8e6106e7_zHardware costs;
  • Software development/acquisition costs;
  • Internal staff time, both immediately and over the long term;
  • Training;
  • Long-term maintenance; and
  • Future upgrades.

For a more detailed list of expenditures, please see this worksheet.

Unfortunately, many technology projects exceed their budgets. An old rule of thumb is to take the initial budget, double it, and then add 20 percent to arrive at the real cost. To avoid this, it’s absolutely vital to set clear goals, specifications and timelines. Even when the system is installed and the party reaches its goal, it will have to continue investing in the technology; there might be ongoing maintenance fees, for example, and the party will have to train new staff on how to use the system. Successful technology projects don’t “just happen”: they are the product of good planning, good management and clear goals.

Interim goals, iterative projects and phased rollouts

Some technology projects are built all at once, but it often makes sense to build them in stages. For instance, a comprehensive party data management system might start with a single piece — perhaps a party membership database. With the initial segment in place, the project might progress to building other pieces of the party’s data infrastructure; each section will have its own specifications, timeline and budget.

Please see the following worksheets for more details about coming up with a specifications (specs) document, a timeline and a budget.

  • Specifications documents (“Specs”): This outlines what should be included in a specs document and gives tips for ensuring that the document is a comprehensive, useful tool for the party.
  • Project timeline: This worksheet includes considerations to ensure that the project is not delivered too late or missing an important event, such as an election day. It also includes a very simple sample timeline and tips for creating a real one.
  • Budget: This is a list of questions to help parties think through all of the long- and short-term costs associated with adopting a new tech tool.

A project might roll out in stages, with more capable iterations replacing early versions. Many website projects roll out iteratively, with more complete versions of the site replacing the simple initial version, which may be just a single page. Iterative projects are not complete “out of the box”: they evolve. This renders them easier to put on hold if necessary and allows for the entire effort to change direction as needed. Again, each stage in the process should have clear specifications, a timeline and a defined budget.

Another approach is to roll out technology to different audiences in sequence. For example, a party might apply a branch office management system to a single province or region first so that it can identify and fix bugs, and so staff can gain experience before the entire party moves to the system. In this case, the first users serve as a test case for the technology before the party commits to a full-scale rollout. This approach is also useful if a party is unsure the technology is appropriate; it allows the party to test a particular technology on a smaller scale.

Beginning with a test case can be a good way to ease senior leadership into new technologies; the leadership might resist party-wide change but welcome smaller, more exploratory projects. After testing the technologies on a small scale, the party can decide whether to invest in them for the broader organization.