For a typical development project which involves a software application that will be released in multiple languages, and with user guides, the schedule for the software development has certain milestones with respect to the UI. In addition to needing to freeze the UI for purposes of ensuring that there is enough time for the QE team to be able to review and test the entire completed application, there are other needs. When a software needs to be released in multiple applications, the normal model is to create the software in English and then get it translated in multiple languages. However, when you are selling to a global customer base, a lot of your non-English customers are not really going to be happy if you make a German or a Japanese language version of the software available weeks or months after the release of the English language version. As a result, a number of software application makers have modified their process to incorporate a simultaneous release of their software in different languages.
To accommodate this, there needs to be a point in the schedule where the translations for the various languages needs to happen, and the English language strings are finalized so that the translation activities are not impeded by changing strings. This can happen on a regular basis where English language strings are sent for translation as and when they are finalized on a regular basis; however, it must be remembered that changing such strings after they are finalized has a cost (of translation and re-testing of the translation). Hence, there needs to be a specific time in the schedule when all such changes are frozen, and any further changes can happen only after due deliberation and after accepting the incremental costs of such changes (one example would be if there is a spelling mistake or bad grammar in the application at any specific location – such examples are typically seen as problematic and evidence of sloppy work by the user community, and can lead to much exposure and reduction of the feeling of professional competence of the makers of the application).
In addition, there is another set of people who need to ensure that the UI of the application is frozen. These are the people who prepare the user documentation and help manuals. When you look at help manuals, you will see that a large many of these manuals have a lot of dialogs and controls visible inside these manuals (the old adage of ‘a picture is worth a thousand words’ is very true in the case of user manuals since it helps the user understand the functionality much easier). Now, to make it to the user manuals, the UI elements need to be frozen, and remain frozen. If the UI elements are modified after they are incorporated into the user documents (and their equivalent language versions are also incorporated), then these changes can become very expensive, since these will have to be re-worked. Now, if there are major or critical requirements, then these changes can be made, but it is critical to get an estimate of the cost of this re-work, get all the stakeholders to be part of this discussion, and then make the decision.
|Managing Software Development Projects||Professional Software Development||Software Project Survival Guide|