As you move into the more advanced stages of presenting your work, you may find yourself in a situation where your project turns into something that involves coders, designing databases, and web sites. It is important that you take a step back and realise that you are now running not just a research project but also an IT project.
There are many difficulties which CSOs and other researchers face when developing software. Some common issues include:
It is always going to be more costly and riskier to develop something from scratch than to customise something that already exists. That's not to say you should never develop something new – just ask around first, and make sure that what you are asking is technically feasible.
You should make the software behind your project is open source. If many other organizations do the same, this allows code to be reused across jurisdictions. Not only does this ease the financial burden, but it helps create an expectation in countries around the globe for the high-quality engagement tools that their neighbouring country has access to.
Purchasing software is more like having a piece of clothing made than like buying a chair. You can give the designer a basic vision of what you would like, but you will always need to come back to make sure it really fits, and your thoughts may change when you see things in practice. If you have an arrangement with your tailor which allows you to first specify the general idea and a couple of other appointments for fittings and trials, you'll probably end up with a better and more creative result than if you tried to design the whole thing and it was simply unveiled to you at the end. You'll also feel more in control, and it may even be quicker to do design and implementation in parallel.
Define the basic components of your project and prioritise them by their importance. As the developers start working on one of these chunks, you can then break it up into more specific tasks based on your evolving understanding of the project.
A popular technique for this purpose is the user story, a small narrative piece that describes a problem, e.g.: "As a [web site visitor] I want to [be able to see a supplier's contracts] so that I can [understand what services they provided to government]". The key to these stories is that they describe the actual user need, not the details of the solutions that you have envisaged. While you should of course discuss those with the developers as well, defining solutions is mainly the job of the developers, not the project manager.
A saying among developers goes: "Walking on water and developing software from a specification are easy if both are frozen." As your software project is progressing, you will likely realise that the specifications you have given need to be revised or extended. But by modifying the requirements, you are essentially shifting the ground on which developers are working – meaning they will have to stop their work to adjust. To prevent such changes from freezing all development, the process of introducing changes and additional requirements needs to be structured.
Iterations are periods of a defined length, often two or four weeks, during which developers are tasked to execute a set of previously selected user stories or requirements. Before the iteration starts, developers have to pull in the work from a list of tasks (a so-called backlog) prepared by the project manager, committing themselves to delivering those tasks within the agreed period. Crucially, project managers are not allowed to extend or revise the scope of an iteration while it is ongoing (unless they want to declare it failed). This method ensures that changes are introduced in bulk and understood by the team. This approach mandates the opposite of the more common unstructured communication between managers and developers, e.g. emails with unsorted lists of change requests which tend to be ignored and lead to confusion.
Whenever you consider an additional requirement, be sure to consider if it is realistic within the resources you have available. "Scope creep", the progressive extension of a project during its development, is a common cause of project failure. By becoming more and more ambitious, the project finally ends up with no usable product at all. To avoid scope creep, make sure to have a storage area for long-term ideas. Also make sure that developers accept additional tasks through a pull process and not by having them pushed into their workflow.
Make sure to budget for ongoing maintenance after the end of your project. Who is going to guarantee that the servers stay online? Who is going to fix a typo? It is unlikely that your project will remain entirely static after its initial development, so you should have an explicit agreement with the developers regarding future support. It is also useful to collect feedback after the project's release and to commission a small number of additional days when enough additional work has accumulated.
The key ingredient to a successful software development project is having the right people on staff or as contractors. Depending on the scope and type of your project, you may need a variety of skills. These are some of the common developer roles.
The easiest way to meet developers is through community meetups such as hackdays. During such events, coders meet up to cooperatively develop prototypes of new software. To meet volunteer developers who can help you make sense of and unleash the power of government spending and budgets, it's worthwhile to investigate events such as Random Hacks of Kindness, Data Kind, and TechCamps.
There are a few ways you can discover if there is a hackday in your area. One way is to search on Lanyrd or set up an account on that system and request to be alerted when there is a hackday in your area. Another approach is join mailing lists of organisations that can help you find developers, e.g. the Open Knowledge Foundation lists or the Sunlight Labs mailing list.
It's impossible to give concrete guidelines on how much a project should cost. Developers' salaries are generally quite high for a country's average, but they vary strongly from country to country. If you're worried about your project spiraling out of control, we would recommend agreeing on a price per iteration. It may also be a good idea to draw up a contract which allows you to break it off if you are not happy with the work at the end of an iteration. You can generally also find a friendly developer to glance over a quote from a company for a sanity check.
There has been error in communication with Booktype server. Not sure right now where is the problem.
You should refresh this page.