Introduction
As more people get connected to the global ICT networks (Internet, social networks, mobiles, etc.), especially in the developing world, the need to share information and knowledge through such networks increases. UNDP is not immune to these trends. As a result, the demand for IT services from programmes and units is on the rise. This is also happening in BDP, which has a global mandate when it comes to policy and programming and thus probably has greater need to make use of the latest ICT tools and communication channels to get the message out to clients, partners and stakeholders.
In BDP, the average request for procuring IT services targets the creation of web sites or portals that can capture and display in user-friendly fashion all content and information that a programme, unit, division or partnership wants to disseminate to the general public.
Components of IT services
Units soliciting IT services for the establishment of content-oriented web sites should be aware that such requests comprise four distinct elements which are usually conflated into a single one in most UNDP RFPs and procurement processes. They are:
1. Hosting and applications
2. Design and software development
3. Content management
4. Maintenance and user support
Not all units require to procure all of the above to successfully run a public web/portal site. For example, user support is usually not required as state of the art web sites are simple to use and users should not require training to effectively use them. Social networks such as Facebook, Google+ and Twitter are examples. Also, if the content is to be generated by the unit itself and/or by external users, there is no need to procure content management services. In addition, most state-of-the-art web applications provide user-friendly interfaces that will allow non-technical people to easily upload and manage content.
Hosting
With the advent of could computing, there is no need any more to purchase hardware (servers, routers, digital modems, leased lines, etc.) or directly pay for network usage costs. Cloud computing companies offer a wide variety of options which basically take care of most if not all hardware and network requirements. There is also plenty of competition for cloud computing. BDP units should thus plan on having their web sites in such locations – thus outsourcing this component to professional service providers.
The two main options for hosting on a cloud provider are: 1) a dedicated server which only runs the web site being developed; and 2) a shared server where other (non-UNDP included) clients also host their sites. The latter is much less expensive than the former. Units should thus have a rough idea of the volume of both content and traffic the site might demand. On average, most UNDP sites are not content intensive nor do they attract a tremendous amount of traffic.
BDP units should also be aware that cloud companies offer, as part of hosting packages, hardware support, security (firewalls), spam filters, domain names, daily backups and user support. There is thus no need to contract another company to provide such services.
Cloud hosting costs can range from 10 to 250 USD per month in the USA, depending on the options selected by units involved in procurement.
BDP units need to be aware that any web site that they want to launch requires the purchase of a domain name (the name of the site, for example, www.undp.org). This is usually part of the cloud provider package. What is key here is that such domains should be owned and managed by UNDP staff and not external parties for security and reputational risk reasons.
Most cloud providers also offer as part of their hardware and bandwidth packages, software options including operating systems (Windows/Linux), web servers (Apache server) and content management systems (CMSs, such as WordPress, Drupal, etc.). In addition, they also offer server management tools that will allow clients to directly manage the technical aspects of the site.
Choosing Free/Open Source Software (FOSS) solutions such as Linux, Apache and Drupal for example is cost effective as not only it does not require the payment of any license fees but also facilitates the reuse by third parties of any software development that is financed and undertaken by the project.
Site design and software development
With could computing, clients get vanilla versions of software packages which must then be customized for the specific needs of the project in question. This will require the procurement of web site design and/or software development services. Although some cloud providers furnish such services, it is usually better to get dedicated companies that also support the platforms, applications and CMSs chosen.
BDP units should be aware that web site design and software development are not the same thing. As a rule, software developers are lousy web site designers and vice-versa -web designers usually know little about software development. Although some larger companies provide both services professionally, small companies might not. Units should ensure the bidding companies include at least one web designer (usually an artist or graphic designer) in their offer for services.
Web design relates to the “look and feel” of the site. Units should have a rough idea of how they want the site to look and seek companies to help them modify, improve and finalize design. This is not a technical issue and thus require no technical expertise. Taste and personal experience play a key role here. Design companies should develop “wireframes” (http://en.wikipedia.org/wiki/Website_wireframe) for the whole web site and engage with units to finalize web site design.
Units should also be able to plan on how they want the content organized based on their own area of work and thematic area expertise. This will then determine the structure of the site (menus, number of core pages, use of multimedia, etc.) and thus the overall scope (and costs) of the project. Again, this is not a technical issue but rather a substantive one. Without this knowledge, units will be at the mercy of designers and software developers who will probably do their own thing in terms of structure and overcharge UNDP for the services provided.
Software development involves both customizing an existing CMSs and developing new features and modules that might not be available in vanilla versions of the packages. At any rate, software development is best implemented if the parties agree on specific Software Requirement Specification (SRS, http://en.wikipedia.org/wiki/Software_requirements_specification which in a nutshell identifies the scope of work and the number of person/days required for the delivery of the various outputs.
Design and software development are usually priced based on both daily rates and the number of persons involved in the process. In this light, fast delivery will be a function of the number of people involved in the project. Units should thus ask bidders to submit their daily fees and the number of people that will be directly involved in the project. This will the optimal way to evaluate proposals from both the technical and financial side – and increase UNDP’s value for money procurement.
Content management
Once a CMSs has been fully configured and customized to cater to the needs of the project, the actual management of the content does not need to be outsourced to an external party. This also includes social media managements (Twitter, etc.) as well as communication and PR strategies. Unit should be able to ask companies to provide the required tools, which are usually part of most CMSs, to upload and customize their own content. If this is properly done then content management should not be a burden. As a rule, it is best to avoid the separation between the production and distribution of content, especially if UNDP is furnishing most of the content and wants to keep control of the overall thematic direction of the site.
In the age of social networks, most content is user-provided. If the site in question is aiming at capturing external content in this fashion then adequate planning needs to be completed to manage external users and their inputs. This will require the development of code of conduct, privacy and intellectual property policies among others to handle user-provided content. Most of this functionality can be automatize but oversight might still be needed to ensure information gaps are well covered.
Units should be aware of this additional requirement -although most UNDP project web sites usually do not include this feature. This is not a full-time task so units should be careful about outsourcing this component. It could be more cost effective to assign this chore to existing staff or consultants who can then easily interact with supervisors and/or policy advisors.
Maintenance and user support
All cloud providers include technical maintenance and support for web sites. There is thus no need to add this element in new contracts.
The same does not apply for software development and web design. Bids for contracts should include free support and maintenance for a period of time (3 – 6 months) to address bugs and glitches. Companies should not charge for this initially. Having additional maintenance and support contracts for software and design might not make good economic sense as companies will not consider any request for adding n ew features to the sites. It is here where the confusion between bug and (missing) features comes into play. The former is the responsibility of the software developer. The latter is due to the lack of planning from the contractor.
In most cases, contracts for user support do not make sense. As mentioned before, sites should be very user-friendly, require only a web browser and have almost no glitches. There is this no real need to contracting companies to support and/or train users.
RFP processes
One of the most daunting challenges most BDP units face when procuring IT services relates to the elaboration of adequate and professional ToRs for RFPs or RFQs. Most units do not have the capacity or time to develop such documents. Some even go as far as recruiting ICT experts to help them prepare and finalize related ToRs. On the other hand, there is no doubt that elaborating such documents is not a simple task and does require some level of expertise.
To address this gap, the following solutions could be explored.
1. Create a roster of and/or have LTAs with independent ICT experts who can provide their expertise in completing RFP ToRs. Essentially, the experts will help translate the overall requirements of the unit into more technical language that is properly understood by specialized companies. Experts can also help BDP create standardized templates for RFP ToRs to facilitate and streamline the process
2. Create a dedicated virtual space to share RFP ToRs within BDP using either TWs or the Intranet. There are only so many ways one can build a web site or portal so in the medium-term units will be able to reuse ToRs with little customization and learn about processes and costs along the way
3. Create a list with details of all web sites and portals that BDP is developing, supporting and maintaining. This will allow to explore joint use of cloud services and reuse of some of the software development and customization that BDP owns and has already paid for
4. Create a list of vendors and providers who have work with BDP and include inputs and assessments of contracting units. BDP’s Deputy Director, PSU, and CAP chair should also have direct access to past and ongoing contracts and be able to compare prices and contract details.
Vendor lock-in
From the very start, units should take into account the need to avoid vendor lock-in, specially when it comes to software development and customization and web design. There seems to be the overall view that in the field of IT, vendor lock-in (or switching vendors) is more common than in other areas. Although this make sense given the high-level of sophistication of this sector (which by the way is similar to others; think Montreal Protocol vendors and consultants), this does not need to be the case.
Units should thus include in initial RFPs and contracts the following:
- Delivery of all source code to UNDP which in principle should own it. The same goes for all CMSs customization and wireframes
- Full documentation of all software development, specially for any source code
- Full documentation (admin manual) for the administration and management of the web platform and the CMS being used.
- Full documentation (user’s manual) for site end users
These additional outputs, all of which UNDP owns, can then be used as inputs for additional contracts for the platform. In this fashion, vendors who were not initially involved in the process have access to all adequate information on the platform and can thus submit competitive bids vis-a-vis incumbents.
