Quality and Cycle Time in Projects

The cycle time is a very important outcome variable because the projects are usually carried out under the strict delivery schedules. The cycle time for projects depends on the two factors - the planned development time and the discrepancies between planned and actual development times. When the planned schedules are longer than the minimum cost-effective schedule, then they do not raise the development costs. This is because, under the ideal circumstances, the projects can be completed using lesser developers than the optimal staffing strength.

However, if the schedule gets tighter, then the cycle time can be affected by the dysfunctional team dynamics which is according to the Brooks' Law. In an empirical study which explored the discrepancies between the planned and the actual durations, it was found that the most important reasons for the discrepancies were mostly capacity related issues like the personnel involved in the unplanned activity, the maintenance of the earlier projects and the product-complexity related issues like underestimating the complexity of the application.

The main factors which drive the cycle time includes:

• Amount of the functionality to be delivered: The "size" can be measured by the function points, the story points, and the use cases.

• Delivered quality requirements: Clearly an organisation can deliver anything quickly if it does not have to work after it has when delivered. So, a meaningful measurement of the cycle time improvement will have to consider some measure of the delivered quality like the defects per size or the defect containment effectiveness.

• Time on task: This is the time which the project team will devote to the interest of the project. Most of the teams will spend a specific amount of time fixing the defects related prior to release, working on the other parallel projects, attending training and taking vacations. The interruptions are the fact of the life and will have a profound but usually unmeasured impact on both the cycle time and the productivity. Every interruption will need a "context switch" that is absorbing the specifics related to the cause of the interruption like understanding the particulars before the defects report is released, investigating potential causes, determining the potential solutions, implementing and also testing the fixes.
• Defect insertion rate: This is a function of the experience level of the assigned personnel, the complexity of the problem which will be addressed and the reasonableness of the established schedule. As all the industry cost, the estimating models will clearly demonstrate that the excessive schedule pressure will lead to significantly higher level of defect insertion rates and so higher rework.
• Appraisal methods and timing: The type and the amount of the appraisal done at each phase of the development process should have a profound influence on the effort necessary to find and fix the defects. The failure to do sufficiently will increase the effort in the appraisal and rework. More effort should be spent on finding and fixing the defects invariably which will lead to longer cycle times.
• Hands-off and queues: Lean thinking has shown that both the hands- off and the batch queues contribute to increase in the cycle time. The smaller batches and the end-to-end teams' responsibility will contribute positively which will help in reducing the cycle time.
• The cycle time in the organisations can be reduced by adopting the following:
• Smaller teams which will undertake smaller units of work and so more efficient.
• Smaller iterations will facilitate parallelism. For example, the iteration A can be tested while the iteration B is built and the iteration C will be defined.
• Smaller units of the functionality are less complex and the defect insertion rate will be consequently low.

• Shorter iterations will reduce the consequences of the requirements changes driven by changing the business circumstances.
• Most of the teams are structured so that the end-to-end responsibility can be given. So, fewer hands-offs and shorter queues or the backlogs of the incomplete work.
• It may be less difficult to manage and also reduce interruptions.