When faced with extreme uncertainty in a problem – where perhaps the only certainty is that the solution will end up bigger than it appears to be today – it’s tempting for a team or its management to be aggressive with workload, to take on stretch goals with the intent of “getting ahead” or “getting on top of the problem.” Because situational uncertainty creates insecurity, the various stakeholders – executives, managers and executors – will seek out certainty of situational control. Just as there will be those who seek control, there will be those willing to feign control.
This is not leadership, and in fact it’s a management anti-pattern. Committing to a solution too soon, or being a “serial committer” of several solution paths over the life of a project, is at best a waste of time and energy, at worst poor stewardship: it often leads to instability (e.g., team burn-out, staff turnover), high operating costs, poor performance, and no results. It is also bad management: when faced with a high degree of problem uncertainty, it will be impossible to know how much progress is actually being made toward creating a solution. Aggressive pursuit of completion is, therefore, pointless.
This can be called out by indexing the degree to which work “piles-on” a project. This can be expressed as the sum of work in hangover (that is, work that is signed-up for but not completed in the time-box) plus the expansion of scope over the same time period (new requirements or depth of understanding which increases work estimates.) “Pile-on” has a compounding effect: teams have memory; with each passing iteration of goals not achieved and discovery of new work, the team appears to never get “on top of” the problem. The project appears to be under-achieving and therefore losing more ground to an ever-expanding solution definition.
We can get a sense for the effect of this by plotting a “pile-on” index.
Consider a team working in a highly volatile domain, such as an R&D exercise. In these situations it is difficult to establish a well-defined initial shared vision between business and IT, and scope management is difficult as requirements will enter, exit and re-enter the solution domain in very short periods of time. The solution is therefore something of a “moving target.” In this situation, if the team:
- commits above its capacity to delivery (e.g., sets stretch goals)
- delivers to capacity (hits none of its stretch goals)
- experiences scope expansion iteration-on-iteration
It will more rapidly exhibit “work pile-on.”
In this example, while scope is expanding and creating a “scope deficit,” over-committing amplifies the degree to which work is “piling-on” the team. Instead of working at a sustainable pace to better understand the problem domain, the team (by team decision or mandate) is self-inflicting a greater degree of hopelessness. Going in mad pursuit of a “solution” when there is no clear understanding of the “problem” in the first place has the opposite effect of its intent: not only does the team not “turn the corner,” the project gives every appearance of sliding further and further into an abyss.
This is also where team memory comes into play: the final data point, showing up-tick (the last data point), is not itself representative of the corner being turned: a single point is not a trend, the project trendline is still negative. Until that flattens out, work is still trending toward greater “pile-on.”
This index appears to hold outside of this example. Consider two other scenarios:
- Deferred Discovery: a team defers requirements discovery to be completed during the first few iterations of delivery, but commits and executes within its capacity. This might be a situation where scope is more important than time or cost – additional requirements are known to be coming (and are hopefully factored into the release and project plans), cadence and predictability are more important to project success.
- Aggressive: a team working in a requirements domain that is decreasing, making commitments that reflect capacity but delivering slightly ahead of requirements. This might be a situation where the delivery date is more important than scope – in this case, all parties agree to clearly focus on the highest value requirements. Shared vision and scope management are more important to project success.
Using data from representative projects, we can plot the “pile-on” index of all three situations.
The plotlines in the second graph show a relatively neutral “pile-on” in
dex for the aggressive and Deferred Discovery scenarios: both are working to relatively predictable paths. The Aggressive team, trending slightly ahead, is a positive working environment where it is able to track to an early completion. The Deferred Discovery team, working at a predictable pace, may re-define its project time-box (by adding one or two more iterations) to fulfill scope. Both situations are manageable and predictable and demonstrate teams are in control of their solutions. By comparison, the “futility” path (copied from above) shows no mastery of a solution domain, and in fact shows inability to manage in uncertain circumstances.While working toward an uncertain (and expanding) domain can be frustrating, that frustration is magnified when stretch goals are set or imposed and not met. Feigning control in a situation of tremendous uncertainty creates more harm than good. The better management practice is for a team to acknowledge the situational uncertainty and collectively and incrementally develop a better understanding of both problem and solution. This minimizes frustration and maximizes the energy, creativity and raw bandwidth applied to drive out a solution.