matslats.net

Software providers and web site developers live in a different world to non-profit types, and they speak a different language. They are used to working with businesses with decision makers and with people with a reasonable knowledge of their field. This page will give you some ideas of what to expect when dealing with a contractor.

Choosing the platform

These days only very unusual web sites are programmed from the ground up. Most start from a platform or framework which is configured by experts and sometimes extended by modules. These are called Content Management Systems (CMS), and here are some examples. The price of CMSs ranges from free to hundreds of thousands. Added to that you have the cost of setting it up for your organisation, training your staff, and the cost of maintenance, or upgrades. Each system has its own approach, and while all systems can do most things, some will be better suited to your needs. Choosing which CMS is a hard decision, and organisations sometimes get stuck deciding, but they shoudn't, because they can never have enough information. The best approach is to decide the most important features, and send them to a range of developers, and then choose from the quality of responses you get.

Mentioning your budget

CMS implementation is so complex that there is little to learn from comparing prices for a project proposal. If you don't state your budget, you risk wasting developer time bidding for a project out of your range, and you also lose an opportunity to show that your expectations are realistic. An unrealistic price could mean you get no responses. If you budget over several years and allow up to 10% of the build cost per year for ongoing improvements, you can command a larger budget, and show the developers you understand that software deserves continuous improvement.

Many smaller companies use their own CMSs, often developed over years of working with their specific client bases. You should be cautious about buying into a bespoke CMS because

• It may have some missing features that you didn't think of, because it was designed for the needs of a small client base
• It relies on a small team for its improvement, but that team's priority will always be implementing systems, not improving the code.
• The quality of the code may be poor, making it hard to extend, bug fix, or give to another programmer
• If the company goes out of business, your CMS will become much less useful and more expensive to maintain.
• If relations should sour during the build, you will not be able to pass on the half-done job to another company - it will have to be restarted from scratch.

The advantage offered by these small companies is that, being local, more face-time is possible, and they are readier to take smaller jobs. They will be less able to to give NGO rates, however.

Drawing up a shortlist

It is helpful if you can get a picture of the kind of company you want to work with, so you can make your list short. Consider the following adjectives, prestigious, philanthropic, prolific, local, specialist, young, experienced, reccommended. It is not within the scope of document to mention developers or systems, but you can find developers on the basis of locality, platform, or indirectly by finding out how similar systems were made. If your shortlist is too short, you might not get enough responses. If it is too long, some recipients may be inappropriate, and you risk wasting developer time. One way to focus your shortlist is to phone or email the recipients individually to ask if they would like to receive your RFP. You might take the opportunity to ask them if they do projects within your budget range.

The Tender process

Until you have chosen a developer, things should be more formal, especially if you are accountable for your spending. While small web shops are used to being approached informally, fairer comparisons and more accountability can be achieved through a formal approach. You will also win respect by engaging at a higher level. It does not mean the project will cost more, conversely, it will increase the chances of success. Just as your approach should be formal, you can learn a lot about contractors from the quality of their responses. It may be worth getting a consultant in to help you gauge and engage the developers properly. A better RFP will interest better developers. Many of the better developers are making lots of money, and drop their usual prices for occasional non-profits who they want to work with. Small web shops live closer to the breadline, they may be cheaper, but are less likely to drop their prices for you.

Their role during the build

Software development always takes longer than planned. However the vast majority of NGOs will require no actual software development at all. Web sites are more like customised assembly these days. The contractor should therefore be able to give a realistic schedule, and to work within budget, as long as you do your bit. Each company has its own way of interacting with clients during the build process. You should try to work according to their method because their time probably costs more than yours.

Your role during the build

The contractor does not just take the brief and come back with a web site. There are many small decisions that cannot sensibly be prepared in advance, and which are best made on the spot by the NGO. So there needs to be someone ready to make decisions. The main work though, is the preparation of content. Clients always underestimate the time this takes, and many web site launches are delayed because of it. Content is more important to most NGOs than to most businesses, and so NGOs should aim to have their content as ready as possible before the build starts, and to have someone on standby full time for further content development during the build. Difficulties come when clients become inspired by half-built sites, or change their minds. This can be very costly and time consuming. Companies have ways of allowing some flexibility during the build, but NGOs should be aware then the build starts, the planning is over, and new ideas should be put into the next phase. (Elsewhere I mention that there should be an annual budget to cover new ideas and incremental development.)