Countering Parkinson's law for improving productivity

Abstract

Improving productivity is one of the basic goals of any software development company. One possible reason for productivity being lower than what is possible may be due to Parkinson's law, which states that work expands to fill the time available for its completion. In a software project this means that if more than needed time is given to a programmer, the extra time will not be revealed as "free time" on the programmer's weekly activity reports, but will result in the programmer consuming all the allotted time resulting in loss of productivity. A simple approach of allotting less time may not work as there are often small reasons relating to clarifications/coordination that provide the "reason" to a programmer for taking more time for completing a task. Therefore, to counter the effect of Parkinson's law, we therefore, took a two pronged approach: 1) allocating 33% less time than the estimated effort for a task and 2) facilitating issue resolution that may impede progress through a 15-min time-boxed daily meeting. We conducted an experiment for about six months in seven software projects in the real environment to study the impact of this approach. We found an improvement of at least 15% in productivity of the programmers compared to their baseline productivity without any degradation in quality of the programs developed by them. Results were validated with a statistical significance value of P < 0.05 using Minitab tool. The views of project managers and programmers on the use of this approach, along with few limitations of this study, are discussed in the paper.

Lean design management using a gamified system

“…Parkinson's Law [23] and Student Syndrome [24] explain this as: \work expands to ll the time available for completion" and \individuals tend to waste time and wait until activities get really urgent before they work on them." A simple approach to allotting less time may not work as there are often small reasons relating to clari cations/coordination that provide the \reason" to a design engineer for taking more time for completing a task [25]. 1.3.2.…”