Common_Mistakes__Functional_Web_Specification by eddy86


Common Mistakes: Functional Web Specification

Word Count:

Streamline your functional Web specification phase and avoid these common
mistakes during the design cycle to deliver your Web projects on time and
on budget.

Functional Specification, Web specification, design specification,
prototyping, stripped pages

Article Body:
Ineffective functional specification for Web projects such as Web sites,
Intranets or Portals contribute largely to delays, higher costs or in
applications that do not match the expectations. Independent if the Web
site, Intranet or Portal is custom developed or built on packaged
software such as Web-, enterprise content management or portal software,
the functional specification sets the foundation for project delays and
higher costs. To limit delays and unexpected investments during the
development process, the following pitfalls should be avoided:

<b>Too vague or incomplete functional specification:</b> This is the most
common mistake that companies do. Everything that is ambiguously or not
specified at all, developers do not implement or implement in a different
way of what site owners want. This relates primarily to Web features that
are considered as common user expectations. For example, HTML title tags,
which are used to bookmark Web pages. The Web steering committee may
specify that each page contains a page title, but does not specify that
HTML Title tags needs to be implemented as well. Web developers therefore
may do not implement HTML Title tags or implement them in a way, which
differs from site owners' visions. There are other examples such as error
handling on online forms or the definition of ALT texts for images to
comply with the disability act section 508. These examples look like
details but in practice, if developers need to modify hundreds or even
thousands of pages, it amounts to several man-days or even man-weeks.
Especially, the corrections for images as business owners need first to
define the image names prior that Web developers can implement the ATL
texts. Ambiguous functional specification can result due to the lack of
internal or external missing usability skills. In this case, a one-day
usability best practice workshop transfers the necessary or at least
basic usability skills to the Web team. It is recommended, even for
companies that have usability skills or rely on the subcontractor's skill
set, that an external and neutral consultant reviews the functional
specification. Especially, as such reviews relate to marginal spending as
compared to the total Web investments (e.g. about $10 K - $15 K dollars
for a review).
<b>Future site enhancement not identified or not communicated:</b> It is
crucial that the Web committee identifies at least the major future site
enhancements and communicates them to the development team. In the best
case, the development team knows the roadmap for the coming three years.
Such an approach allows the development team to anticipate implementation
choices to host future site enhancements. It is more cost effective on
mid- or long-term to invest more in the beginning and to build a flexible
solution. If Web teams do not know or even ignore future enhancements,
the risk for higher investment increases (e.g. adding new functionality
in the future results in partially or at worst in totally rebuilding
existing functionality). Looking at the financial delta for a flexible
solution versus a solution just satisfying the current requirements, the
flexible solution has proven to be more cost-effective in practice from a
mid- and long-term perspective. </p>

<b>Planned functionality not aligned with internal resources:</b> Many
companies look at site functionality only from a site visitor perspective
(e.g. facilitation of searching information or performing transaction)
and corporate benefits (e.g. financial benefits of self-service
features). However, there is a third dimension the impact of site
functionality on internal resources. Site functionality that can heavily
impact internal resources are for example:
- Web sites: providing news, online recruitment, online support, etc.
- Intranets / portals: providing content maintenance functionality for
business managers

It is crucial for the success of site functionality that the Web
committee analyzes the impact and takes actions to ensure operations of
the planned functionality. For example, providing the content maintenance
functionality to business owners and product mangers with an associated
workflow. This functionality is effective and can generate business
benefits such as reduced time to market. However, in practice, business
owners and product managers will need to write, validate, review, approve
and retire content. This results in additional workload. If the Web
committee has not defined in the Web governance (processes, policies,
ownership and potentially enforcement), it may happen that this
functionality is not used and hence becomes useless.

<b>Wish lists versus actual needs and business requirements:</b> The
functional specification is not aligned with user's needs or business
requirements. This is more common for internal applications such as
Intranets or portals. In many cases, the project committee neglects to
perform a sound internal survey and defines functionality by generalizing
individual employees' wishes without any sound proves. Capturing the
feedback of internal users across the organization allows determining the
critical functionality. To effectively perform a survey a representative
set of employees need to be questioned. Further these employees need to
be categorized into profiles. The profiles need to be characterized by
for example, frequency of usage of the Intranet, estimated duration by
visit, usage of the Intranet to facilitate their daily tasks,
contribution to the business, etc. Based on this information the Web team
can then prioritize the functionality and choose the most effective and
relevant functionality for the next release. Less critical or less
important functionality may be part of future releases (roadmap) or
dropped. If such a sound decision process is not performed, it may happen
that functionality is developed but only used by few users and the return
of investment is not achieved.

<b>Not enough visual supports or purely text based:</b> Textual
description of Web applications can be interpreted subjectively and hence
leading to wrong expectations. To avoid setting wrong expectations, which
may are only discovered during development or at worst at launch time,
functional specification need to be complemented by visual supports (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 allows
reducing subjective interpretation and taking into account the users'
feedback prior development. Such an approach helps setting the right
expectations and to avoid any disappointments at the end once the new
application is online.</p>

We have observed these common mistakes, independently if companies have
developed their Web applications internally or subcontracted them to an
external service provider.

To top