Better Practice Checklist
Briefing and selecting the Web developer
About this checklist
This checklist will explain how to brief the website development team when building a new website or re-developing an existing website. No matter whether the development team is in-house or external, making sure it is built by the right people according to the right plan is essential to the success of the website.
The aims of this checklist are to:
• increase the effectiveness and efficiency of the website development process; • reduce the risk of developing a website that does not meet the requirements or
expectations of the user;
• save time in briefing developers;
• improve the likelihood of selecting the most appropriate website development team; and • improve management of the development process by having an appropriate contractual
arrangement in place.
Audience for this checklist
This checklist is for Australian Government employees who are responsible for managing the development or redevelopment of a Government website.
Overview
Checkpoints ... 3
Step 1 Research ... 3
□ Ask your users what they want to see and do on your website ... 3
□ Determine your business needs, the aims of the website and the intended audiences ... 3
□ Research what similar agencies are doing online - both nationally and internationally ... 3
□ Check with Government lawyers to see what terms and conditions should be included in the contract ... 3
Step 2: Write the brief ... 3
□ About the department or organisation ... 3
□ Aims of the website ... 3
□ Intended audiences ... 3
□ Content scope ... 3
□ Content maintenance ... 4
□ Features and functions ... 4
□ Graphic design and usability principles ... 4
□ Accessibility requirements ... 4
□ e-Commerce ... 4
□ General technical issues ... 5
□ Testing ... 5
□ Training ... 5
□ Project management arrangements ... 5
□ Instructions to tenderers ... 5
Step 3: Develop the contract ... 5
Step 4: Finding potential developers ... 5
Step 5: Review the proposals ... 6
Step 6: Negotiate and sign the contract... 6
About the Better practice checklists ... 6
Checkpoints
Step 1 Research
Undertaking research is important in
establishing the principles on which the new website will be based. Consult with
colleagues and users during the research phase to improve the validity of the process.
□
Ask your users what they want
to see and do on your website
Find out what users like and dislike about your current site and test out some of your preliminary thinking about the content, features and layout of the new site. Refer to the checklist: Testing Websites with Users.
□
Determine your business needs,
the aims of the website and the
intended audiences
Find out what new information, products and services you want to provide and promote, and to whom and why.
□
Research what similar agencies
are doing online - both nationally
and internationally
□
Check with Government lawyers
to see what terms and conditions
should be included in the contract
Consulting early with your lawyers allows time to prepare a development contract. Lawyers will need to see the development brief once it is completed in order to finalise the contract.
Step 2: Write the brief
Websites are not easily quantifiable
products, therefore making websites difficult to tender for. Despite all research, you may still be unsure of the website’s requirements and expectations. Engaging the web
developer can help with this issue through exchanging ideas and working prototypes.
The rationale for producing a brief is to minimise the guesswork and to provide the web developer with sufficient information on which to base a valid quotation.
The brief may not be precise, but the exercise of putting it together will help to crystallize what is required in the site, how it should behave and what is expected of the web developer.
Below is an outline of a brief that provides a structure for communicating your information and ideas to potential website developers. Each heading represents a section that should be in the brief.
□
About the department or
organisation
Provide details relating to:
• portfolio, roles and responsibilities; • information services/products you
provide;
• history of the organisation; and • history of the current website.
□
Aims of the website
Provide details relating to the aims of the website and how you intend to measure its success.
□
Intended audiences
State the categories of intended users e.g. public, citizens, government, businesses, tourists.
Provide as accurate a breakdown of their characteristics as possible e.g. age, location (state, national, international, rural, city), their level of experience using the internet and likely connection speed.
□
Content scope
Provide details relating to the nature and scope of content e.g. approximately how many pages, documents, images, maps, minutes of video, audio, etc.
Provide a list of all the intended headings and sub-headings within the site – this may
be presented as a tree-diagram or simply listed as a hierarchy of the headings.
□
Content maintenance
Possibly the most important aspect of managing a website is managing and updating its contents.
Inefficient content management takes time away from the activity of improving the quality of the content and services offered online.
The following two checklists provide information on content management systems and should be read prior to
composing this section of the brief: Selecting
a Content Management System and Implementing a Content Management System.
Provide details relating to:
• desired process for updating and managing the contents after launch; • extent to which the developer will be
required to assist;
• number of staff required to undertake these activities; and
• training that may be required.
□
Features and functions
Identify what features and functions you want available to users on the web site. For each identified feature and function, explain how it should work for users and how it should work for you.
Examples of features and functions: • website search facility
• contact us
• query a database or data set • sitemap
• password protected section
• a blog for feedback and comments • e-newsletter
• CUE
• interactive maps and diagrams
As this is the brief and you are not a Web expert, you do not have to know how everything will work on the web site. However, outlining to the developer the
elements you would like on the web site enables the selection of the optimum overall solution for your web site and will help determine a realistic quotation.
□
Graphic design and usability
principles
Provide details relating to:
• desirable characteristics of the web site e.g. easy-to-use and easy-to-find information;
• your design criteria and principles, for example it must comply with your logo and brand, font size, and layout; • usability – specify the principles for the
navigation elements and how users should be able to use features of the web site. You may choose to frame this as a list of do’s and don’ts;
• Web addresses of websites you regard as good examples of what you are seeking so that the developer can see the type of site layout and design you envisage; and • relevant industry standards and Web
conventions.
□
Accessibility requirements
Specify that the site is to comply with
relevant industry standards and accessibility guidelines. Refer to:
• accessibility guidelines issued by the World Wide Web Consortium - www.w3c.org
• Better practice checklist: Access and
equity issues for websites.
□
e-Commerce
If you want users to be able to purchase products and/or services you need to describe:
• the nature and number of products and services that are to be offered online; • how the products/services and
corresponding prices are to be displayed; and
• the selection (shopping cart) and payment processes e.g. secure credit card
□
General technical issues
Provide details relating to:
• the technical environment in which the maintenance solution will be operating e.g. state what type of computers and Internet connection those updating the site will be using;
• preferred website hosting arrangements; • security requirements of the website and
data; and
• website traffic usage monitoring and reporting requirements.
□
Testing
Testing with users and staff involved in updating the site should be undertaken throughout the development of the site and before signing-off on the design, usability and content management solution. It is preferable for website testing to be
conducted by an experienced third party as they are likely to be more objective and have the skills to elicit and detect problems with the website.
Provide details relating to:
• what is to be tested and under what conditions;
• who will do the testing and when; • change control plan as a result of
feedback from the testing; and
• sign-off procedure to accept changes and move to next stage of development.
□
Training
Ask the developer to state what training will be required and how many staff will need to be trained.
□
Project management
arrangements
Explain the management structure – who are the decision-makers? List their respective roles and internal decision making
procedures.
Project schedule: specify the deliverables and milestones, timeframe, and any stages
you specifically require in the development process.
□
Instructions to tenderers
This section of the brief is only required if seeking proposals from private web developers.
Each department and agency will have its own procurement policies and practices. No matter what they might be, it is useful when selecting a web developer to provide tenderers with the following range of information:
• response format e.g. hard copy, email, or PDF;
• when responses must be submitted, where and to whom;
• what responses must contain e.g. methodology, experience, reference websites, the team members cited for the projects they have developed, and referees;
• itemised quotation including hourly rates e.g. project management, design, programming functionality, testing, training, editing software or content management solution, and hosting; • the criteria for selection; and
• the process and timeframe for evaluating the responses.
Step 3: Develop the contract
Work with your in-house lawyers or
approved and experienced lawyers to draw up a contract for the developers.
The contract is vital as it helps protect the department or agency and provides the ground-rules for how the developer and you will work together.
Step 4: Finding potential
developers
Many Government website development projects will be advertised through the tenders.gov.au website. However, if you need to identify web developers and other related suppliers to whom the brief and
contract might be sent, here are some sources of information:
• the ICT Multi Use List managed by the Department of Finance and Deregulation: www.finance.gov.au
• a search engine – try the term: website developers
• the website industry association websites list their members: www.aimia.com.au and www.iia.net.au
• Yellow pages and online business directories
• colleagues in other government departments
• Government websites that you like and are similar in scope to yours, find out who developed them – sites often have
credits, or just email the site owner.
Step 5: Review the proposals
Once you have received the proposals review them according to your procurement policies and the process stated in the brief.
If you have trouble understanding the proposal, warning bells should ring because it usually means they cannot communicate effectively, which, in turn, means working with them may be difficult and frustrating. If your procurement policies allow, invite a short-list of developers to come in to your office and present their proposal in person. This helps you understand the proposal more clearly and helps you determine who will be easiest to deal with.
Step 6: Negotiate and sign the
contract
Once the preferred developer has been identified negotiate the contract.
If the developer wishes to alter any aspect of the contract, check with the lawyer who drafted the contract before accepting or rejecting the alteration.
If the developer requires you to sign anything, have your lawyer check it before agreeing verbally, or signing it.
About the Better practice checklists
Comments about this checklist and suggestions for additional checkpoints can be directed to: Better Practice
Australian Government Information Management Office Email: [email protected]
Copies of this and other checklists are available at:
http://www.finance.gov.au/e-government/better-practice-and-collaboration/better-practice-checklists/index.html
Better Practice Checklists
Managing websites
1. Use of Metadata for Web Resources 2. Online Policy Consultation
3. Knowledge Management 4. ICT Support for Telework 5. ICT Asset Management
6. Managing the Environmental Impact of ICT
7. Assistive Technology for Employees of the Australian Government
Planning websites
8. Providing Forms Online
9. Providing an Online Sales Facility
10. Selecting a Content Management System 11. Information Architecture for Websites 12. Website Navigation
13. Digitisation of Records
14. Access and Equity Issues for Websites 15. Marketing e-Government
16. Designing and Managing an Intranet
Building websites
17. Writing for the Web
18. Briefing and Selecting the Web Developer 19. Use of Cookies in Online Services
20. Implementing a Content Management System 21. Implementing an Effective Website Search Facility 22. Spatial Data on the Internet
Maintaining websites
23. Managing Online Content 24. Archiving Web Resources
25. Decommissioning Government Websites
Evaluating websites
26. Testing Websites with Users
27. Website Usage Monitoring and Evaluation
Acknowledgments
This checklist was developed by AGIMO and Website Criteria Pty Ltd.
With the exception of the Commonwealth Coat of Arms all material presented in this document is provided under a Creative Commons Attribution 3.0 Australia (http://creativecommons.org/licenses/by/2.5/au/) licence.
The details of the relevant licence conditions are available on the Creative Commons website (accessible using the links provided) as is the full legal code for the CC BY 3.0 AU licence
(http://creativecommons.org/licenses/by/3.0/au/legalcode).
The document should be attributed as the ‘Australian Government Better Practice Checklist 27 – Briefing and selecting the Web developer’
