How fast can you go?

On my first project management course I remember being taught about the iron triangle of cost, quality (some might include scope) and time. You could choose to fix any two of these dimensions but the third would then float depending on nature of the project. If a project was slipping behind schedule you could go quicker by adding more resources or by cutting quality/scope.

I quickly learned that in practice this wasn't really true, at least for complex software projects. An esteemed colleague of mine once put it very succinctly 'you can only get one plumber under the sink' - if a particular component or service needs to be fixed or upgraded very often there is only one person, the resident expert on the widget in question, who can work on it at a time. This insight was captured back in 1975 by Fred Brooks in his infamous book: The Mythical Man-Month: Essays on Software Engineering.

In this situation well meaning senior management will be heard to say 'what are my options to accelerate this?' or 'who do i need to call to speed this up?'. The unpalatable truth is that by the time this situation has arisen there is often little that practically can be done beyond removing blockers or distractions from the path of the single plumber. This answer is usually poorly received, perhaps because it reveals the impotence of management structures in resolving tactical challenges in a highly complex knowledge ecosystem.

It is for this reason that escalation to increasingly senior levels of management doesn't usually alter the outcome of expertise related issues; a case of more heat and less (or at best the same) light. The assumption that all problems are simply ones of prioritization and can be fixed 'if only someone more senior was aware' is, in the moment, usually flawed.

In circumstances where the required acceleration pertains to more routine tasks then surely the application of management pressure can produce meaningful acceleration? Well perhaps, but the opportunity cost can be so significant as to outweigh the perceived benefit.

For example let's consider on-boarding of new resources, perhaps to replace departing colleagues or to recruit a new skill into an existing team. This value-chain - the value being the motivated, appropriately skilled, equipped and up-to-speed colleague ready to make a difference - is designed to have sequential activities, completed by different teams and optimised to minimize waste. No single step can proceed if the proceeding step is outstanding for fear of conducting nugatory work should that prerequisite fail.

Convincing the management of all of these serial functions to give your request special treatment is possible but requires a disproportionate effort. Asynchronous holiday or other absences of key individuals that need to sign-off or operate in concert often defeats even the most tenacious manager, as does unexpected system outages or upgrades.

In my experience the effort to accelerate the outcome of these business-as-usual processes is exponential; with a modest effort you can nudge it along to the organisation's default tempo but to make a significant difference to the final outcome requires a herculean effort and thereby a substantial opportunity cost.

So if hard-charging management within the organisation rarely accelerates the outcome what can we do to speed up delivery or to rectify issues as promptly as possible? The complexity of the modern enterprise encourages specialization but minimizes resourcing in the name of efficiency; in doing so often under-values the expertise of individual upon whom such an ecosystem relies.

Perhaps if we can learn to optimize our processes around the time of these system experts (as the health service does around consultants) and adjust our management incentives to permit a little inefficiency in the pursuit of velocity, we can optimize our true value-streams and move at a pace closer to that our customers and stakeholders now demand.

(Views in this article are my own)