Do what's needed for meeting the descriptions that are written down in the Users Requirements Statement.

Repeat the Application Development and Coding Process and the Testing with the Users Process until all the requirements specified in the Users Requirements Statement have been met.

Well documented application requirements help to minimize the number of development and user testing cycles that are needed.

Take notes in preparation for the application's next, upgraded version.

The project planning process that is used by this company builds into the development process certain time reserves. The project manager must ensure that these reserves are used only when doing so is really necessary.

Up to a certain (statistical) limit, the bigger the user group that tests the application, the better. However, the project manager must make sure that he or she has the resources needed to handle all the feedback.

The main problem that so many applications have is that they do not meet the users needs effectively enough. Often enough the cause of these problems isn't developers lack of competence as programmers or user interface developers. What makes a big difference is the project developer's ability to observe how the people in the user group work with the application and the problems they encounter. Based on these observations the project developer must identify the tasks and objectives that have to be met so that application's usage problems are being worked out.

What's even better is if the project developer can actually work with the application so that he or she performs real life tasks that the application users have to perform. This works the best when it is done during the Testing with the Users Process, that is, after the application's initial version has been developed. Working with the application (and with other application users) for even one day can provide important insight into what should be changed or which additional features are needed so that the end result is a fully and conveniently usable database application.

Smaller changes and additional features can be handled by using the time reserves that were built into the Users Requirements Statement and the development process during the Analysis Stage. New and additional features should be left for the application's next, updated version, unless a different agreement is negotiated with the customer.

Ensure that the user representative group members and the customer's management members stay committed to the application, its planned resource needs and its usage.

Every application development feature and functionality that is described in the Users Requirements Statement deserves enough attention so that it is completed on time.

Project planning must divide the project into atomic-granular parts, that is, into small, clearly identified steps and tasks, so that all the steps and tasks are identified sequentially. Project management must use this information but so, that the people working on the project have enough autonomy and flexibility for handling the needed tasks. So, don't micromanage, but stay consistently informed about the progress and the challenges.

If needed, bring in the additional or backup developers as resources (that were identified during the project planning stage).

Allocate extra time resources as needed. Be cautious about allocating time and other resources for developing new and additional features, unless the customer requests them. If the step meets the Users Requirements Statement's description, move on.

If the application's functionality is being put in place the way it was planned for, and the customer wants to add features to the application's current version or make changes to the current version, and we have time and other resources available for doing so, then lets implement the changes, recording them in the Users Requirements Statement as well. (Users Requirements Statement's new version should be signed every time when the changes are being made.) However, nothing is free - the programmers and other people involved in the project want to get paid, and if the customer wants additional work to be done, the customer should also cover the additional cost the request generates.

This approach is both in the customer's and in the service provider's best interest, because there is no such thing as a perfect software product. People can always imagine something better than they have. So, any product can be imagined as being better than it currently is. This is a very important point to keep in mind. In a sane world the reality can never measure up to what people's imagination can create. At a certain point the extra time put into the additional improvements simply does not justify the results that are generated. So, the customer can and should make the informed decisions about when the additional expenses are justified. We can always develop the next version of the current application. Lets get the current version done the way it was planned for, so that it is fully usable and convenient to use, then we have time to discuss the next version.