Nicknamed “The Prince of Paradox,[i]” philosopher and writer G.K. Chesterton asserted the following:
“In the matter of reforming things, as distinct from deforming them, there is one plain and simple principle; a principle which will probably be called a paradox. There exists in such a case a certain institution or law; let us say, for the sake of simplicity, a fence or gate erected across a road. The more modern type of reformer goes gaily up to it and says, I don't see the use of this; let us clear it away. To which the more intelligent type of reformer will do well to answer: If you don't see the use of it, I certainly won't let you clear it away. Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it.”[ii]
The shorthand version of this quote is “Don’t ever take a fence down until you know the reason why it was put up,” which is close to capturing the overall meaning, though I would add the observation that, where Chesterton thought the modern type of reformer would go up to the fence “gaily,” I would substitute “naively.” It’s an easy conceit that informs younger generations that all that was set up before with which they take exception was done so out of ignorance. Properly trained auditors know the basis for their comparisons, and appropriate methods for evaluating against any given audit standard. Poorly (or even un-) trained auditors simply show up and start condemning each and every condition or technique with which they disagree.
Meanwhile, Back In The Project Management World…
A common and frustrating characteristic of reformers, in this case those who would implement some more “advanced” PM capability, such as Agile/Scrum (ProjectManagement.com’s theme for November), is that they will often approach their work with the confidence that their proposed business model updates will work for their new organization, if only the targets of the reform would (a) recognize the superiority of the reformers’ approach, and (b) cooperate with it fully. This is pretty ironic, considering the practice of software engineers to conduct what’s known as A/B Testing. In situations where older code is undergoing significant additions or modifications, or when, say, a website isn’t performing as anticipated, a standard practice is to avoid implementing the modifications all at once, and instead update characteristics incrementally, constantly comparing the new version’s performance with the existing. By approaching the update in this fashion, the team avoids the scenario where they find themselves having worsened the situation from where it was when they began, with no idea precisely which change or combination of changes caused the reversal, and, therefore, no cogent path to reclaim their losses. Without a comprehensive knowledge of all of the other modules that interact with the one being changed, it’s almost guaranteed that a significant number of these modules will fail, perhaps causing the modules depending on them to also fail, initiating a cascading effect across the entire application. And, just to be clear, it is extremely difficult to get a handle on each and every connection among nodes in even a relatively simple network.
Somehow, though, this caution in tinkering with existing nodes in a network tends to evaporate when the discussion turns to implementing a novel PM strategy, such as Agile. Make no mistake: business models are highly complex networks, whether they came into existence through a master plan, or entirely holistically, by piecemeal. One might be able to change out, say, the software package for the general ledger with relatively few implementation issues, since the functioning of the GL is highly regulated. Not so with Project Management software packages or approaches, where even the appropriate level of system rigor tends to be a highly contested matter. If an organization finds itself in the software marketplace through, perhaps, some Project Team members developing an app that solves an acute problem afflicting entire portfolios, but that organization was ill-disposed towards setting up Work Packages and Control Accounts, it’s highly unlikely that they will suddenly embrace that very change just because they are now being asked or required to create Epics, Stories, and Sprints. And even in those circumstances where the organization has a fairly robust traditional PM capability, there may very well be legitimate reasons for not streamlining the configuration management/ change control process. It would, then, be a mistake to attempt an Agile management implementation until after those reasons can be discovered, evaluated, and addressed, lest they manifest in the new business model.
To be sure, all of this can be done. It simply requires the flexibility to be cognizant of the reasons behind the configuration of the existing business models. In short, it will require the Agile PM reformer to be, ahem, agile enough to hop over Chesterton’s Fence.
[i] Retrieved from https://www.christianitytoday.com/ct/2001/augustweb-only/8-27-52.0.html?paging=off#bmb=1 on November 11, 2022, 17:31 MST.
[ii] Chesterton, G.K., The Drift from Domesticity (1929).