How does deadline pressure affect the quality of results?
I often experience project teams being formed with the goal of developing innovative new ideas and technologies under pressure. In order to give the team a sense of urgency and to get results as soon as possible, management sets tight time limits.
Interestingly, the longer the organization has not truly innovated, the shorter are these time limits. Sure, that’s because the management is relatively nervous. But it is also clear that this usually doesn’t work!
Now the top experts are locked in a room and get started, but are not sure what they should do. They have to show that they can develop a disruptive innovation, such as the “atomic bomb”, but only get the time to “put more explosives into the existing bomb shell”.
The team is in a conflict and often, the conflict is not even clear. Because the team was perhaps only said to create an innovation within the shortest possible time. Depending on the organizational culture, teams then often tend towards the “hot potato algorithm” and, according to announcement, develop “something” as fast as possible, which certainly will not be THE disruptive innovation.
In my last case of this kind, with a new setup team, the team barely had the time to develop even simplest ideas, build prototypes, and test before time ran out. Within their planning, many short-cuts were then taken, e.g. only considering ideas that could be evaluated in this short time. In addition, ideas were combined very early when building prototypes before the team even knew what influences the different design ideas had on the overall performance.
As a solution of the dilemma we could approach as follows:
The team created several concepts in a first iteration, both for the simple options (with “more explosives”), and for the development of disruptive (atomic bomb) ideas. These were then presented to the management in the first iteration review, for each comparing the Effort (estimated by the development team) to a Benefit (estimated by the stakeholders). This allowed the stakeholders and product owners to decide.
By the way, a useful visualization for this is my Upswing-Gravity-Field, which is shown below. The relationship: Priority = Benefit / Effort is shown graphically. (Upswing=Benefit; Gravity=Effort)
