| Common Mistakes: Specifiying Fucntional Web Specification |
|
|
Page 2 of 3 Future site enhancement not identified or not communicated: 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. Planned functionality not aligned with internal resources: 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:
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. Wish lists versus actual needs and business requirements: 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. |
| < Prev |
|---|