Project Management |
||||||||||||||||||
 |
What steps are involved in the development process?Our development methodology is designed to be fast, practical, scalable and highly effective in achieving all project goals at minimal cost. We use a customised version of the rapid application development (RAD) methodology, involving early prototypes that are reviewed and developed into the final system.
Some of these steps are optional. The process is tailored to the client's needs at the estimation stage, so that the client gets the level of detail they require. Instead of a formal sign-off, we rely on a two-way agreement that the system is ready for use in production. This "Practical Completion" step triggers the invoice for the final payment and recognises that both parties take some responsibility that the new system is complete, within the agreed scope. How much training will we need?A quick look at some examples of our standard interface features will make it clear why no user manuals are needed with our systems. The standard user dialog is consistent and obvious to most clerical staff. Because your key staff members are involved in the development, by the time the system is implemented, they are usually able to train others. If a process has special complexity, the details are explained on the screen in the correct context. If required, we can arrange training for our custom applications, but it is rarely needed. There is often a training component included in the package price for our products since the operators don't have the benefit of being involved in the development. Where's the user manual?Like we said above, give your shelves a break! We find that the only documentation that gets used is the documentation that automatically appears in front of the user as they use the system. We try to ensure that any operator who knows the business processes will be supported through each process at an appropriate level of detail. We include explanatory static or pop-up messages on the forms, to highlight any non-obvious issues to consider. Our error messages describe the facts about the problem, without misleading the operator with speculation over the real cause. Because the system is custom-built, we can use terminology that makes sense to the business throughout the system. We can even include a slower dialog with additional controls for critical business processes that have been a problem in the past. The operator guides for our packaged products are structured around business procedures rather than system components. Click here to see examples
of our standard user-interface features.
|
|
||||||||||||||||
   |
