Technology in Marketing: Developing a Law Firm Web Site RFP

Imagine you want to build a new house and have interviewed three contractors to obtain bids for the job. One bid $100,000, another bid $200,000, and the third bid $500,000. How would you decide between them? The answer is you couldn't make an apples-to-apples comparison unless the contractors were basing their bids on a single set of architectural plans specifying size, materials and other construction details.

Yet, when many law firms decide to build a new Web site, they solicit bids from vendors without first developing specifications detailing the desired features and functionality for the site. As a result, such firms receive disparate bids without an adequate basis for comparison. And in many such cases, a firm ends up selecting one of the lower bidders only to experience frustration when disputes arise with the selected vendor over increased costs and delays as the scope of work changes over the course of the project.

What law firms embarking on a Web site development project need to understand is that building a new Web site is similar to building a new house. Just as the number of bedrooms and bathrooms, the quality of the kitchen countertops, and the absence or presence of an in-ground swimming pool, need to be determined upfront to accurately estimate the cost of construction, so too the number of sections on the Web site (e.g., attorney bios, practice area descriptions, publications), and the nature and complexity of the site's navigation, design and database need to be specified upfront to obtain accurate bids.

The purpose of this article is to explain how to prepare a functional requirements specification for a law firm Web site (often delivered to vendors as a Request for Proposal, or RFP) that can be used to solicit bids from vendors, to compare bids on an apples-to-apples basis, and to fix the scope of the Web site development project.

Part I: Objectives and Audiences

The first section of a Web site RFP should identify the audiences that will be using the law firm's Web site. Such a list might include prospective clients, existing clients, law school students and the media. One important category of site user often omitted from such lists is the 'site administrator,' i.e., the staff at the firm that will maintain and manage the Web site. The reason it is important to address the role of the site administrator in the RFP is that the degree of control over the Web site given to internal site administrators in terms of adding, editing and deleting site text, graphics and other content will affect the cost of the development.

Once the target audiences for the site are identified, the objectives for each audience should be specified. For prospective clients, the obvious objective is to generate new leads. Other objectives might include encouraging new business from existing clients, selling the firm to law students as a great place to work, and pitching the media on the firm's expertise. By documenting its goals for each audience, a firm can ensure that it doesn't inadvertently overlook any functionality that it might want for the Web site.

Part II: Essential Tasks

Once the firm's target audiences and goals for the Web site are defined, the next step is to identify what are known as essential tasks. These tasks (sometimes called 'Use Cases' by vendors) are actions that each audience should be able to perform with respect to the site. For example, the firm may want clients to be able to access not only attorney bios, but when viewing an attorney bio to also see links to all of the attorney's articles, practice areas and success stories. The firm may also want visiting journalists to see a list of topics on which attorneys at the firm have previously written or spoken (thereby reinforcing those attorneys' expertise), and law students to have access to videos of current associates speaking about their experiences at the firm.

Each essential task should have a title, the name of the audience that would need to perform this task, and a paragraph or two describing the nature of the task. Good task descriptions identify the steps a user takes to perform the task. If you can't describe a certain task in a paragraph or two, break it out into a number of smaller tasks.

Here are two sample task descriptions:

View Attorney Information: Clients

Go to attorney search page. Search for attorneys by clicking a letter in the alphabet or by first name, last name, practice area or industry. From list of search results click an attorney name to view attorney's bio. On attorney bio page, view color photo, contact information, representative work, practice areas and articles. Click practice area link to learn more about the attorney's practice areas. Click article link to read a particular article written by the attorney. Click success story link to read more about a particular past successful representation.

Add New Attorney: Site Administrator

Log into admin system. Select 'manage attorneys' and then 'add new attorney.' Upload new attorney's color photo. Add new attorney's contact information, law school and representative work. Check off attorney's practice areas from list of existing firm practice areas. Preview attorney bio page. Click 'Save.' New bio page added to site (or e-mail sent to attorney to review draft and approve for publication to site).

The more detailed the descriptions of your essential tasks, the better. The reason is that, if thoroughly prepared, essential task descriptions can be used as acceptance tests to determine whether a vendor has delivered the functionality promised. In other words, if the site prototype developed by a vendor can perform all of the essential tasks identified in your RFP, then the project will be deemed complete. If certain essential tasks are not complete, then the vendor has not fully delivered what the firm has requested. That is why the process of developing essential tasks is so critical.

Part III: Screens

The next step after identifying essential tasks is to describe all of the pages (also known as 'screens') displayed to site users, and the actions that can be taken with respect to each screen.

For every essential task, make a list of all of the screens that a user might see in performing a certain essential task. Using the 'View Attorney Information' sample task noted above, a very high level screen description might be as follows:

Attorney Search Page: display all letters of alphabet (clickable); drop down menu of available practice areas and industries; text box to enter last name or first name. Because a description of essential tasks in an RFP may be sufficient to obtain accurate bids, and screen descriptions can often become quite technical, screen descriptions are not essential to an RFP. However, once a vendor is selected, a comprehensive list of screens should be developed as part of the scope of work to ensure that the firm and the vendor agree on the deliverables for the project. If a site will be particularly complicated, a good preliminary step might be to create a simple 'wireframe' or HTML prototype of the site to make sure the firm and the vendor are on the same page before proceeding to the full site deployment.

Part IV: Object Model

Once you've fully documented the essential tasks (and possibly screen descriptions), you should have all of the information required to describe what is known as your object model.

The object model identifies all of the categories of data that need to be tracked and managed by the system running your Web site. Attorneys, practice areas, articles, press releases, and success stories are all business objects. These objects are usually inter-related, that is, individual attorneys are usually associated with specific practice areas and articles.

Each business object will have one or more properties. For example, an attorney will have a first name, last name, phone, fax, e-mail address, and short description. It is important to list all of the properties for each business object.

Conclusion

While preparing a detailed RFP before soliciting bids seems like a lot of work, it is an important step towards ensuring that your firm can compare vendor bids on an apples-to-apples basis and then obtain the Web site it wants within an affordable budget and acceptable timeframe. If needed, your firm can work with an outside vendor with RFP preparation expertise to facilitate the process.

Joshua Fruchter, a member of this newsletter's Board of Editors, is president and co-founder of eLawMarketing, a leading provider of online marketing services to law firms and other professional service providers. He can be contacted at 866-833-6245 or at [email protected]. The firm's Web site is at www.elawmarketing.com. Peter Bell is a senior applications programmer with eLawMarketing.

Imagine you want to build a new house and have interviewed three contractors to obtain bids for the job. One bid $100,000, another bid $200,000, and the third bid $500,000. How would you decide between them? The answer is you couldn't make an apples-to-apples comparison unless the contractors were basing their bids on a single set of architectural plans specifying size, materials and other construction details.

Yet, when many law firms decide to build a new Web site, they solicit bids from vendors without first developing specifications detailing the desired features and functionality for the site. As a result, such firms receive disparate bids without an adequate basis for comparison. And in many such cases, a firm ends up selecting one of the lower bidders only to experience frustration when disputes arise with the selected vendor over increased costs and delays as the scope of work changes over the course of the project.

What law firms embarking on a Web site development project need to understand is that building a new Web site is similar to building a new house. Just as the number of bedrooms and bathrooms, the quality of the kitchen countertops, and the absence or presence of an in-ground swimming pool, need to be determined upfront to accurately estimate the cost of construction, so too the number of sections on the Web site (e.g., attorney bios, practice area descriptions, publications), and the nature and complexity of the site's navigation, design and database need to be specified upfront to obtain accurate bids.

The purpose of this article is to explain how to prepare a functional requirements specification for a law firm Web site (often delivered to vendors as a Request for Proposal, or RFP) that can be used to solicit bids from vendors, to compare bids on an apples-to-apples basis, and to fix the scope of the Web site development project.

Part I: Objectives and Audiences

The first section of a Web site RFP should identify the audiences that will be using the law firm's Web site. Such a list might include prospective clients, existing clients, law school students and the media. One important category of site user often omitted from such lists is the 'site administrator,' i.e., the staff at the firm that will maintain and manage the Web site. The reason it is important to address the role of the site administrator in the RFP is that the degree of control over the Web site given to internal site administrators in terms of adding, editing and deleting site text, graphics and other content will affect the cost of the development.

Once the target audiences for the site are identified, the objectives for each audience should be specified. For prospective clients, the obvious objective is to generate new leads. Other objectives might include encouraging new business from existing clients, selling the firm to law students as a great place to work, and pitching the media on the firm's expertise. By documenting its goals for each audience, a firm can ensure that it doesn't inadvertently overlook any functionality that it might want for the Web site.

Part II: Essential Tasks

Once the firm's target audiences and goals for the Web site are defined, the next step is to identify what are known as essential tasks. These tasks (sometimes called 'Use Cases' by vendors) are actions that each audience should be able to perform with respect to the site. For example, the firm may want clients to be able to access not only attorney bios, but when viewing an attorney bio to also see links to all of the attorney's articles, practice areas and success stories. The firm may also want visiting journalists to see a list of topics on which attorneys at the firm have previously written or spoken (thereby reinforcing those attorneys' expertise), and law students to have access to videos of current associates speaking about their experiences at the firm.

Each essential task should have a title, the name of the audience that would need to perform this task, and a paragraph or two describing the nature of the task. Good task descriptions identify the steps a user takes to perform the task. If you can't describe a certain task in a paragraph or two, break it out into a number of smaller tasks.

Here are two sample task descriptions:

View Attorney Information: Clients

Go to attorney search page. Search for attorneys by clicking a letter in the alphabet or by first name, last name, practice area or industry. From list of search results click an attorney name to view attorney's bio. On attorney bio page, view color photo, contact information, representative work, practice areas and articles. Click practice area link to learn more about the attorney's practice areas. Click article link to read a particular article written by the attorney. Click success story link to read more about a particular past successful representation.

Add New Attorney: Site Administrator

Log into admin system. Select 'manage attorneys' and then 'add new attorney.' Upload new attorney's color photo. Add new attorney's contact information, law school and representative work. Check off attorney's practice areas from list of existing firm practice areas. Preview attorney bio page. Click 'Save.' New bio page added to site (or e-mail sent to attorney to review draft and approve for publication to site).

The more detailed the descriptions of your essential tasks, the better. The reason is that, if thoroughly prepared, essential task descriptions can be used as acceptance tests to determine whether a vendor has delivered the functionality promised. In other words, if the site prototype developed by a vendor can perform all of the essential tasks identified in your RFP, then the project will be deemed complete. If certain essential tasks are not complete, then the vendor has not fully delivered what the firm has requested. That is why the process of developing essential tasks is so critical.

Part III: Screens

The next step after identifying essential tasks is to describe all of the pages (also known as 'screens') displayed to site users, and the actions that can be taken with respect to each screen.

For every essential task, make a list of all of the screens that a user might see in performing a certain essential task. Using the 'View Attorney Information' sample task noted above, a very high level screen description might be as follows:

Attorney Search Page: display all letters of alphabet (clickable); drop down menu of available practice areas and industries; text box to enter last name or first name. Because a description of essential tasks in an RFP may be sufficient to obtain accurate bids, and screen descriptions can often become quite technical, screen descriptions are not essential to an RFP. However, once a vendor is selected, a comprehensive list of screens should be developed as part of the scope of work to ensure that the firm and the vendor agree on the deliverables for the project. If a site will be particularly complicated, a good preliminary step might be to create a simple 'wireframe' or HTML prototype of the site to make sure the firm and the vendor are on the same page before proceeding to the full site deployment.

Part IV: Object Model

Once you've fully documented the essential tasks (and possibly screen descriptions), you should have all of the information required to describe what is known as your object model.

The object model identifies all of the categories of data that need to be tracked and managed by the system running your Web site. Attorneys, practice areas, articles, press releases, and success stories are all business objects. These objects are usually inter-related, that is, individual attorneys are usually associated with specific practice areas and articles.

Each business object will have one or more properties. For example, an attorney will have a first name, last name, phone, fax, e-mail address, and short description. It is important to list all of the properties for each business object.

Conclusion

While preparing a detailed RFP before soliciting bids seems like a lot of work, it is an important step towards ensuring that your firm can compare vendor bids on an apples-to-apples basis and then obtain the Web site it wants within an affordable budget and acceptable timeframe. If needed, your firm can work with an outside vendor with RFP preparation expertise to facilitate the process.

Joshua Fruchter, a member of this newsletter's Board of Editors, is president and co-founder of eLawMarketing, a leading provider of online marketing services to law firms and other professional service providers. He can be contacted at 866-833-6245 or at [email protected]. The firm's Web site is at www.elawmarketing.com. Peter Bell is a senior applications programmer with eLawMarketing.