With regard to schedules and applying time pressure to employees, there are various schools of thought. Most experts contend that application of schedule pressure, especially extreme pressure is counterproductive. I tend to agree with this school of thought within reasonable limitations. According to some research, employee productivity was the highest with no schedule, next highest when set by an expert (most accurate), then next as set by the worker. Productivity was lowest when set by the supervisor alone.
I believe the amount of schedule pressure that should be applied depends on the situation. In most cases it should be kept to a minimum except for those employees who would abuse the lack of pressure. If an employee is well motivated, additional schedule pressure would be counterproductive. The employee should be aware, however, that the project does have time constraints, but not to a point of compromising quality and innovation.
To Schedule or not to Schedule, that is the Question
In all fairness, it would be impractical not to have a schedule or estimate cost, tools, and manpower required to complete the project. Not to do so would not only be unfair to the organization, it would become impossible to decide whether to implement any project. What is the answer? Compromise. Obviously for most major projects, an exact schedule cannot be determined. No matter how skilled your management and staff is at estimating requirements and cost, you cannot estimate the cost of the project at its inception to the exact dollar. Therefore the most obvious compromise is to estimate a cost range and schedule range. This is where I believe iterative development is very worthwhile. For more information see the sections on UML. I will summarize the usefulness of iterative development with regard to scheduling here.
With regard to most projects, requirements many times are modified during the middle of development and sometimes late in the project. Iterative development, especially with regard to software, addresses these issues well, and plans for changes to project requirements. Iterative development essentially has four phases with several iterations which may be contained in each phase. The phases are:
Therefore during the inception phase the schedule must be very loose. At the completion of the elaboration phase the schedule can be tightened up quite a bit, but not so much to limit quality and the ability to modify requirements. Therefore some range will still exist right up to the end of the project, but the schedule should become more accurate as the project nears completion. This does not mean that there cannot be a target date for completion. It just means some flexability for unforseen circumstances should be built into the budget and schedule.