Chapter 5

Technology Project Planning and Management

Once you’ve explored your goals and the potential for using technology in your tech strategy, you are ready to start looking at the nuts and bolts of integrating technology into your transparency and accountability work. While technologies can change quickly, your strategies are likely to remain much more constant. Your plan will need to be agile in addressing the implementation of new technologies, and yet built on the solid foundations of your strategy. You can’t have good project management without good project planning. Adaptable and flexible planning is the key to managing technology projects successfully. Don’t gamble that your project will come exactly in on time and on budget: build in some cushion.

We’ve broken down the project planning process into 6 steps that ends with implementation and best practices on project management.

Step One:

Assessment – What is your current technology use?


Before you make concrete plans, its best to examine your own current capacities by conducting an assessment of your existing technology. This can be compiled into a working document that will lay the foundation for your future technology plans.

To assess your current use of technology, answer the following questions:

  • What works well about your current technology setup?
  • What doesn’t work well with your current technology setup?
  • When you have problems with your tech, how do you solve them?
  • Do you have reliable support?
  • Is your broadband supply adequate for your current needs?
  • Does your staff have access to the appropriate devices, such as laptops, mobile phones, etc.?
  • How much of your operating budget is devoted to technology?
  • What sort of external expertise do you use? Do you have relationships with consultants and/or software developers?
  • Do you have social media accounts for your organisation, such as Facebook or Twitter?
  • Does your organisation have its own website? Do you have a domain name that is also used with staff email?
  • Do you back up important data regularly? Are the backups stored securely?
  • Do you routinely discuss the technology solutions your organisation has implemented during staff meetings?

The idea is to examine your weak and strong points when it comes to tech use. An assessment should help you think objectively about your limitations.

If you are to undertake any new technology projects, you should feel that the majority of your answers to the questions above are positive in nature. You should sort out any problem areas, particularly in regard to support, BEFORE undertaking any new tech projects – are you able to handle existing problems effectively?

Look at areas that will be important for supporting your tech strategy. How well are you currently doing with communications? Are you able to handle data effectively?

Step two:

Assure your tech project goals are aligned with your tech vision and your strategic plan


Revisit the work you did in creating a tech strategy and state a goal for the project that relates to your Tech Vision; for example, “this website will connect citizens to data we are collecting about government expenditure”. Establish how this project will move you forward in your strategic plan

Step three:

Identify users and get them involved


  • Test your assumptions about potential users. List the different types of users you expect, and how you think they will use the technology. Then find actual users that fit those profiles and interview them about how they will interact with the technology plan that you are thinking of implementing.
  • Create user profiles and scenarios that show what users will be able to accomplish by using the technology (See appendix Ensuring that your Tech Project Is Usable).

Step Four:

Develop a project plan


  • Reach out to peers and see if they have already implemented similar projects; find out what’s worked and what hasn’t. Your peers will provide better advice than any tech
    expert. Tap into existing networks that are connected to the work you are doing, such as TA Bridge.
  • Identify the critical and indespensible features you need and get them addressed first. Save the “wouldn’t it be nice” features for later.
  • Look for Pilot opportunities. Can you deploy a version of your project with a few individuals on your staff first, to test it before a wider deployment? When you do deploy it throughout your organisation, these individuals can help guide other users in how to use the new software.
  • Build in ways to do monitoring and learning throughout your project plan. Determine evaluation metrics and identify opportunities to monitor progress (See chapter on Integrating “Evaluation” and Learning)
  • Get external expertise early. Your technologies should work optimally straight out of the box – but you might need to hire someone to help with the initial setup or make some minor tweaks to get it right.
  • Examine your organisation’s calendar and identify quiet times where problems encountered during installation and identified in testing will have minimum impact.
  • Make realistic timelines: Tech projects ALWAYS take longer than you imagined. Map out a time line and then quadruple the amount of time projected for implementation.
  • Build in lots of opportunities for user feedback (See Appendix: Ensuring that your Tech Project is Usable). Make sure you stay on top of what works and what doesn’t once you’ve deployed your tech project.
  • Create a healthy budget. Make sure you have enough resources for implementation. Remember, with technology, costs typically begin AFTER you install it.
  • Make sure you have a plan to maintain the technology after it’s implemented.

Step Five:

Create a budget


  • Ask other organisations about their costs for implementing similar technology projects.
  • You’ll probably need twice as much money, time and human resources as you initially think. This includes the amount of time needed to set your project up and configure it.
  • A large proportion of your budget, say around 70%, should be set aside for user testing and training.
  • Always refer to the budgets and actual final expenditure of past projects when creating new budgets.
  • If you are using a FOSS Content Management System (CMS) to support your website, your costs should be in the range of zero to 10,000 USD. If you are edging closer to 20,000, there’s something wrong with your costings.
  • Spending money on software is not a bad thing, and it’s important to realise that everyone involved in software development projects needs to make a living!
  • Build in an unforseen budget item and be aware of how much cushion you have on your budget lines. Don’t forget to get approval if you are going over- or under- budget. Some funders may also allow for a 10% over- or under-spend without the need to get specific approval.
  • Communicate with donors about other changes in the budget during implementation.
  • Don’t forget to budget for long term maintenance and support

Step Six:

Implement your project plan


The key to successful implementation is to develop and nurture the team of individuals involved in the project. Strive for transparency in decision making and keep everyone focused on success and include them in your progress on acheiving it. Model for federated ownership, striving for clear domains of accountability within the team. If the project manager holds too much and has not properly distributed responsibilities, the chances for success greatly diminish. And remember, the project managers most important role is to be a good communicator.

The next step?

It’s likely that after you’ve successfully completed all six steps you’ll be ready to take on a new tech project and you’ll go back to step one – assessment. However you’ll be starting step one with a lot more wisdom about what it takes to run a tech project. Particularly if you’ve given some focus to the next chapter, evaluation and feedback loops.

More Project Management best practices

  • Be clear on the differences between projects and tasks. A task is short and takes minimal effort, while projects should be broken down into tasks. When you are treating a task as a project, it will go much slower.
  • Be clear about what is essential and what is optional
  • Near term deliverables should have greater detail while you will have less detail in long term deliverables
  • Keep people conditioned for communication. Have routine communication and communicate as much and as often as possible with team members. It’s better to have a meeting and say there is nothing to report than to not have the meeting.
  • Gauge how well team members are doing, those who face a greater amount of challenges should have more check ins and communication. Those who are having greater success should have more autonomy and freedom.
  • Increase the frequency of team meetings as you approach your launch dates – think about meeting every two weeks, then every week and, finally, every day,as your deadline approaches.
  • Extend the deadline for a project if necessary, rather than launching a tech project that isn’t ready.
  • Remember that people don’t like to give bad news, so create space where it’s safe to admit failures. The sooner you know something has gone wrong, the better.
  • Communicate routinely with all stakeholders involved in the project, including funders.
  • High risk projects should have greater documentation to assure accountability and also capture learnings.
  • Establish a shared dashboard that has realtime updates on progress and shows individual task lists.
  • Have shorter debriefs more often rather than longer ones less often.
  • Create checklist templates and revise them as needed.

How to identify the right technology


Start by asking: what else is out there? What software/tech solutions already exist that might help you address your challenges?

When you are researching solutions here are some key questions to ask:

  • What is the problem we want the technology to solve? Do not rush to answer this question, and make sure it’s answered BEFORE you start looking at possible technological solutions.
  • Will it meet all of our needs right out of the box? If the software won’t do this, then it’s probably best to look elsewhere.
  • What will it cost to support and maintain? You may need to employ a computer professional who can make the needed changes and provide periodical maintenance.
  • Will your stakeholders find it useable? Productivity is key: you don’t want people wasting time because they can’t access the functions they need.
  • How much training will it take? Training
    on any technology is always advisable. Whether you conduct the training in-house or bring in a specialised trainer, training gives you an opportunity to ensure that everyone has the expertise they need. It also allows you to discover any problems that people may have.
  • Will the software run on the hardware you have? Always check the system requirements. It’s not going to be cost effective to have to replace computers just in order to run software.
  • Is it secure? If your work is highly sensitive, is this software that has been ‘hardened’ to provide extra layers of security?
  • Can it be shared/deployed with your partners and collaborators? Are any of our partners/colleagues/allies already using it?
  • Will you be able to get technical support for it? If you have a problem, will you be able to find a local consultant to fix it for you?
  • Does it have a healthy support community? Are there other non-profits who use the software and with whom you can exchange tips and solutions?
  • Is it still being developed? Have there been recent releases? Are new releases in the works? Are periodic updates issued, ensuring there are patches for bugs and security holes?
  • How will you support and maintain the solution over the long run? If you are using a consultant or developer to configure the solution for you, how will you maintain it after they are gone?
  • Is it open source? Any software solution that will limit your organisations options to modify it or use other platforms, and put a lock on how you can store your data is undesireable.

Once the software solution is installed, make sure you have documentation about it that your staff and your stakeholders can understand. Make sure you also have a guide to troubleshooting if something goes wrong.

How to hire a consultant/developer


Your first step in your technology project is likely to be bringing in a consultant or developer who is experienced with the technologies you wish to implement and can help you work through the numerous steps and avoid the pitfalls.

If you are using a consultant to help you identify solutions, then you need to make sure they are neutral to which technology you will use and/or have a deep understanding of open- source software. You want a consultant that will help you choose software that’s right for you, not what will benefit them.

It’s also likely that you will need to hire someone to help you set up and configure the software and/or hardware, and for long- term support. In some instances you may need to hire a developer to customise and modify the software so that it works better
for the needs of your organisation. Whoever you hire, you will be best served if they are part of the development community for that package. Here are some good reasons for this:

  • Your experience with the software can serve
    as feedback to the developer community, and
    they will learn from your impressions of the package, both good and bad.
  • If there are features that the package lacks, having contact with the development community means that you can be informed as to whether they plan to address those features in a future release or if they can consider addressing them.
  • Be very wary of any customisations of software being done outside the development community. This might be presented to you as a cheaper option, but in the long run it will cost you more money, as any custom code that is not fed back to the developers will mean you are prevented from upgrading to new releases.

Along with strong engagement with the development community, some other good ideas when hiring a consultant are:

  • Initially use a short term discovery/scoping contract where the contractor spells out costs and time for a second longer term contract.
  • Assure their values are in line with the mission/goals of the organisation. The more that they understand and support what you are trying to do, the better.
  • Make sure you understand exactly what you are paying for – how much time and how that time is being spent. If you are paying for long-term support, make sure you clearly understand the parameters of that support.
  • Keep part of your budget for a consultant in reserve – only reveal two thirds of your budget to the consultant!
  • Use contracts written in a way that both you and the consultant can understand. Make sure you clearly
    lay out timelines, deliverables, expectations and any parameters, such as licensing, that will have an impact on the outcome of the project.

It’s well worth finding a developer or consultant
who believes in the work you are doing. You may be
in a situation where you can’t judge the quality of
a developer’s work until after it’s completed, so it’s important to trust the developer and their motives for working with you. If you aren’t certain of their motivations and can’t gauge the quality of their work, it might be worth pulling in someone who can.

See also: Aspiration’s RFP Template: