When Websites are badly designed, don't work or don't do the things that you expect, it's natural to feel let-down and it would be reasonable for you to consider taking your business elsewhere.
It always surprises me that there are so many websites that just aren’t adequate for their purpose. Many are so beyond redemption they will never work unless they’re re-developed from the ground up. Although there are other reasons why a Web strategy can disappoint, in a great many cases the failure could have been avoided or mitigated by good pre-development ground work.
So what can you do to plan a successful Web strategy? The fundamentals boil down to the following:
There needs to be clarity on what is to be delivered. Setting a mission statement or key objective for the project will help to keep everyone on track. This should be clear and unambiguous to allow you to test all functional and design issues against.
With the broad objective in place the next step is to try and identify what users want. The best way to find this out is to ask them.
The right questions are as fundamental as asking the right people. Each stakeholder group will have its own views about key requirements and the trick is to get the right mix of opinion. Depending on budget you can use focus groups, user modelling, surveys, think-tanking and Q and A panels, along with international and local competitors offering analysis. If the service is to be client-facing then sitting down with a couple of key clients and asking them what they would like will set a good agenda. Similarly, internal users need to be involved if the system is to help them deliver their services more effectively.
Sifting the data to create a wish list of features will hone requirements further. Categorising them into essential, desired and wishful items will go some way towards identifying what must be delivered within a hierarchy of needs.
From a technical standpoint, if the application needs to integrate with existing legacy systems or other third party applications then any technologies employed need to be highlighted. If the IT department insist that any solution be written for a particular platform then this will have a funnelling affect on the options available.
If there is a great sense of urgency this will limit the options and may increase the costs. As urgency increases there is a greater trade-off between features and deadlines. If urgent, a project should go live in a slimmer state, with no reduction in testing, and with a roll-out plan for further service enhancements after the site has gone live.
Flexibility and common sense at all stages should be encouraged. Often a business perceives their requirements in one way but the reality of how it should be delivered is altogether different. 'Blue-sky' thinking can lead to unachievable results and disappointment at first release and businesses should focus on a pragmatic set of deliverables.
Finance, combined with uniqueness of requirements, legacy issues and urgency of deployment will determine if a project should use a packaged solution or custom application.
Typically if packaged software is selected then there is a belief that the cost of developing the solution would have been far more that the price of custom development. However, a packaged solution often provides less flexibility than required because it has not been built with customisation options. The end result is that often applications fail to meet requirements or, if customised, can lead to a situation where you are unable to upgrade the package without incurring great expense.
Getting custom software developed is sometimes the only option for businesses that have unique requirements and a long term strategy needing a flexible solution. Typically the costs are similar to the larger packaged/customised solutions that are available, although the increasing use of Open Source solutions can means lower costs and faster development.
Finally, success measurement criteria should be established. Targets should be realistic and flexible, dependant upon other project factors. Not only the eventual success of the application delivered but the project process itself should be measured against specific criteria.
Good pre-development planning will help deliver better results, at lower overall cost. Much of the work takes time and use can be made of consultants to gather the information and compile it into a 'requirements' or 'request for tender' document (RFT). Similarly, your agency should become actively engaged in gathering data and testing assumptions as they produce the project specification. Pre-planning may be seen as an onerous task that uses vital resources but it should account for at least 10% of the development budget.
Inevitably a successful project combines the best blend of research, documentation, finance, management, and technical/design skills to hit the right note; if the mix is not well balanced then the risks of failure increase.
Feedback from our clients
“A true expert in their field. iZAP was prompt in communication and providing service. They went out of their way to make sure this was done quickly and correctly. Even took it upon themselves to contact and work with our system administrator to get the proper gems installed for the Ruby on Rails application. I look forward to working with this provider in the future and highly recommend them!”