Schedules

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.

Individual Responses

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.

Iterative Scheduling

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:

• Inception - The original project idea is developed, and a very rough estimate and schedule may be developed. At this point a reasonable amount of knowledge for requirements of the elaboration phase is obtained and management can decide if they think continuing investment is worthwhile.
• Elaboration - During this part of the project, a minimal skeletal working prototype is developed and the construction phase is planned. Most of the project risk is mitigated at this point and schedule accuracy for the construction phase should be improved. At this point estimates for completion of the project can be more accurate and a final decision to complete the project can be made.
• Construction - The main work is done here to add full product functionality.
• Deployment - The product is deployed to the field.

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 flexibility for unforeseen circumstances should be built into the budget and schedule.