Common Errors: Web Functional Specification

Ineffective functional specification for Web projects, such as Web sites, Intranets, and Portals, is a major contributor to delays, increased costs, and applications that do not meet expectations. The functional specification lays the groundwork for project delays and higher costs, regardless of whether the Web site, Intranet, or Portal is custom-built or constructed using packaged software such as Web-, enterprise content management-, or portal software.

The following pitfalls should be avoided to limit delays and unanticipated expenditures during the development process:

 

Insufficiently precise or vague functional specification:

This is the most common error made by businesses. Everything that is ambiguously or insufficiently specified is not implemented or is implemented differently than what site owners desire. This primarily relates to Web features that are regarded as standard user expectations. For instance, HTML title tags, which are used to bookmark Web pages, are a case in point. The Web steering committee may require that each page contain a page title, but does not mandate that HTML Title tags be utilized. Therefore, web developers may not implement HTML Title tags or may implement them in a manner that differs from site owners’ expectations. Other examples include error handling on online forms and the definition of ALT texts for images to comply with Section 508 of the Americans with Disabilities Act. In practice, if developers need to modify hundreds or thousands of pages, it can take several days or even weeks of labor. In particular, the corrections for images, as business owners must define the image names before Web developers can implement ATL texts. Due to the absence of internal or external usability skills, ambiguous functional specifications may result. A one-day workshop on usability best practices provides the Web team with the necessary or at least fundamental usability skills. Even for companies with usability expertise or that rely on the subcontractor’s skill set, it is recommended that a neutral and external consultant review the functional specification. Especially since such reviews involve marginal expenditures relative to total Web investments (e.g., $10K to $15K for a review).

Future site enhancements that have not been identified or communicated:

It is essential that the Web committee identify and communicate to the development team at least the major future site enhancements. In an ideal scenario, the development team is aware of the roadmap for the next three years. This strategy permits the development team to anticipate implementation options for hosting future site enhancements. On the mid- to long-term, it is more cost-effective to invest more initially and develop a flexible solution. If Web teams are unaware of or choose to ignore future enhancements, the potential for increased expenditures increases (e.g. adding new functionality in the future results in partially or at worst in totally rebuilding existing functionality). Comparing the financial difference between a flexible solution and a solution that merely meets the current requirements, the flexible solution has proven to be more cost-effective in the medium and long term.

Functionality that is not aligned with internal resources:

Many businesses consider site functionality solely from the perspective of site visitors (e.g., ease of searching for information or completing transactions) and corporate benefits (e.g. financial benefits of self-service features). Nevertheless, there is a third factor to consider: the influence of site functionality on internal resources. Examples of site functionality that can have a significant impact on internal resources include:
– Websites offering news, online recruitment, online assistance, etc.
– Intranets / portals: providing business managers with content maintenance functionality

It is crucial for the success of the site’s functionality that the Web committee analyzes the repercussions and takes action to ensure the planned functionality’s operation. For instance, providing business owners and product managers with content maintenance functionality and an associated workflow. This functionality is efficient and has the potential to generate business benefits such as a decreased time to market. In practice, however, business owners and product managers will be responsible for writing, validating, reviewing, approving, and retiring content. This causes additional work to be performed. If the Web committee has not defined Web governance (processes, policies, ownership, and possibly enforcement), it is possible that this functionality will not be utilized and will therefore be rendered useless.

Wish lists versus actual requirements and business needs:

The functional specification does not correspond to user or business requirements. This is more typical for intranets and portals. In many instances, the project committee fails to conduct an accurate internal survey and defines functionality by generalizing the desires of individual employees without solid evidence. Capturing the feedback of an organization’s internal users enables the identification of essential features. To conduct an effective survey, a representative sample of employees must be questioned. These employees must also be classified into profiles. The profiles must include characteristics such as frequency of Intranet usage, estimated duration per visit, use of the Intranet to facilitate daily tasks, contribution to the business, etc. The Web team can then prioritize the functionality and select the most effective and relevant functionality for the next release based on this data. Functionality that is less critical or less important may be included in future releases (roadmap) or eliminated. If a sound decision-making process is not implemented, it is possible that functionality will be developed but utilized by a small number of users, resulting in a negative return on investment.

 

Insufficient visual aids or solely text-based: Textual descriptions of Web applications can be subjectively interpreted, resulting in incorrect expectations. To avoid setting incorrect expectations, which may not be discovered until development or even after launch, functional specifications must be supplemented with visual aids (e.g. screenshots or at best HTML prototypes for home pages or any major navigation pages like sub-home pages for the major sections of the site such as for human resources, business units, finance, etc.). This enables the reduction of subjective interpretation and the incorporation of user feedback prior to development. This method aids in establishing realistic expectations and avoiding disappointments once the new application goes live.

We have observed these common errors regardless of whether Web applications were developed internally or outsourced to an external service provider.

Leave a Comment

Your email address will not be published.