In The Diachronic Metadata Repository as a Tool for Risk Reduction via Conflict-Prevention During Legac... of this blog, Figures 2-5 briefly outlined the structural reasons why three types of conflict inevitably arise in Legacy->ERP conversions (LERCON's😞 functional conflict, technical conflict, and sociopolitical conflict. Although they are different in their nature and causes, these three types of conflicts nonetheless share one important property, Figure 6 shows that they can all be subdivided into three further categories of conflict: procedural, substantive, and avoidable conflict: Figure 6 
The differences between procedural, substantive, and avoidable conflict can be most succinctly summed-up as follows: 1) procedural conflict occurs when folks may or may not agree on ends but definitely don't agree on means; 2) substantive conflict occurs when folks may or may not agree on means but definitely don't agree on ends; 3) avoidable conflict occurs when folks may in fact agree on both ends and means, but extraneous factors are raising so much dust that they don't realize it. In the realm of socio-political conflict: 4) Procedural conflict tends to arise over the basic question of whose methodology should be used to plan and implement a LERCON. The methodology the customer likes? The vendor's own methodology? The methodology touted by the third-party experts (e.g. system integrators) honcho-ing the job? 5) Substantive conflict never arises because all socio-political conflict is non-substantive by definition; 6) Avoidable conflict often arises because customer management does not take the time and forethought to insist on a pre-formed consensus among its own staff, the vendor's staff, and the systems integrators' staff with respect to how the job is going to get done. So in the absence of any such pre-formed consensus, everyone is free to raise as much dust as is humanly billable without choking the CFO. In the realm of functional conflict: 7) Procedural conflict almost always arises over the basic question over the starting-point of the conversion: the customer's "AsIs" or the vendor's "ToBe". For example, why do "gap analysis" if the vendor's "ToBe" is not going to be customized, which is always the vendor's opening gambit? 😎 Substantive conflict can legitimately arise over what really IS "best of practice", as well as over whose view of the universe is more complete - the vendor's or the customer's? 9) Avoidable conflict most typically arises because everyone's so busy scheduling customer staff into "ToBe" classes that they forget to schedule vendor and system integrator staff into "AsIs" classes. So the vendor and system integrator staff wind up with a "cartoon" picture of the customer's business that is going to generate a "cartoon" conversion. In the realm of technical conflict: 10) Procedural conflict typically arises because every techie thinks his or her way of doing something is better than anyone else's, and project management does not insist on an agreed-upon procedural game plan in advance. How many conversions have you worked on where three groups of techies argue for three weeks about whether there's enough bandwidth to send some files to a staging system or whether they have to go sneaker-net? 11) Substantive conflict typically arises because there really is a fundamental misfit between the customer's business and the vendor's system, and everyone starts arguing about whether to change the former, change the latter, or develop a compensating interface. 12) Avoidable conflict typically arises because people who don't know what they're doing are somehow put in charge. How many conversions have you worked on where management has one team of developers working on ETL for the initial migration and another team of developers working on post-migration interfaces, but nothing in place to ensure that both are working off the same page? Given the fact that LERCON's are highly susceptible to procedural, substantive, and avoidable conflict in the socio-political, functional, and technical domains, it's amazing that any of them actually complete successfully the first-time around. (Uhh ... wait a sec ... DO any of them actually complete successfully the first-time around? Never mind, just kidding.) But what makes matters even worse is the fact that LERCON's come in four basic flavors, as shown in Figure 7: Figure 7: 
And when a LERCON comes in any flavor except the upper-left (Type I), life is going to be either rough (Types II-III) or just about unbearable (Type IV). But guess what? Even though most LERCON's actually are Type IV, most of them are conceptualized by management as if they're Type I. And this failure of management to acknowledge that it's facing a Type IV LERCON simply exacerbates the fact that it is this very type of LERCON which is most prone to procedural, substantive, and avoidable conflict in the socio-political, functional, and technical domains. From the considerations outlined in Figures 6 and 7, it follows that Figure 8 merely restates a truism familiar to everyone who's willing to acknowlege it: Figure 8 
The REAL question, therfore, is not whether Figure 8 states an unwelcome truth. The REAL question is that asked in Figure 9: Figure 9: 
If the answer to this question is "no", then failed LERCON's will contunue to litter the IT landscape like the skeltons of whales beached long-ago. But if all the different players and actors shown in Figure 9 could get together and agree on a consensual LERCON process-model, then maybe it might be possible to roll-out LERCON's with less fuss, less muss, and much more chance of success. And as will be discussed next time, this is where the notion of a "Diachronic Metadata Repository" comes in ... as a conceptual structure and working tool around which to structure a consensual process-model for LERCON's.
The differences between procedural, substantive, and avoidable conflict can be most succinctly summed-up as follows: 1) procedural conflict occurs when folks may or may not agree on ends but definitely don't agree on means; 2) substantive conflict occurs when folks may or may not agree on means but definitely don't agree on ends; 3) avoidable conflict occurs when folks may in fact agree on both ends and means, but extraneous factors are raising so much dust that they don't realize it. In the realm of socio-political conflict: 4) Procedural conflict tends to arise over the basic question of whose methodology should be used to plan and implement a LERCON. The methodology the customer likes? The vendor's own methodology? The methodology touted by the third-party experts (e.g. system integrators) honcho-ing the job? 5) Substantive conflict never arises because all socio-political conflict is non-substantive by definition; 6) Avoidable conflict often arises because customer management does not take the time and forethought to insist on a pre-formed consensus among its own staff, the vendor's staff, and the systems integrators' staff with respect to how the job is going to get done. So in the absence of any such pre-formed consensus, everyone is free to raise as much dust as is humanly billable without choking the CFO. In the realm of functional conflict: 7) Procedural conflict almost always arises over the basic question over the starting-point of the conversion: the customer's "AsIs" or the vendor's "ToBe". For example, why do "gap analysis" if the vendor's "ToBe" is not going to be customized, which is always the vendor's opening gambit? 😎 Substantive conflict can legitimately arise over what really IS "best of practice", as well as over whose view of the universe is more complete - the vendor's or the customer's? 9) Avoidable conflict most typically arises because everyone's so busy scheduling customer staff into "ToBe" classes that they forget to schedule vendor and system integrator staff into "AsIs" classes. So the vendor and system integrator staff wind up with a "cartoon" picture of the customer's business that is going to generate a "cartoon" conversion. In the realm of technical conflict: 10) Procedural conflict typically arises because every techie thinks his or her way of doing something is better than anyone else's, and project management does not insist on an agreed-upon procedural game plan in advance. How many conversions have you worked on where three groups of techies argue for three weeks about whether there's enough bandwidth to send some files to a staging system or whether they have to go sneaker-net? 11) Substantive conflict typically arises because there really is a fundamental misfit between the customer's business and the vendor's system, and everyone starts arguing about whether to change the former, change the latter, or develop a compensating interface. 12) Avoidable conflict typically arises because people who don't know what they're doing are somehow put in charge. How many conversions have you worked on where management has one team of developers working on ETL for the initial migration and another team of developers working on post-migration interfaces, but nothing in place to ensure that both are working off the same page? Given the fact that LERCON's are highly susceptible to procedural, substantive, and avoidable conflict in the socio-political, functional, and technical domains, it's amazing that any of them actually complete successfully the first-time around. (Uhh ... wait a sec ... DO any of them actually complete successfully the first-time around? Never mind, just kidding.) But what makes matters even worse is the fact that LERCON's come in four basic flavors, as shown in Figure 7: Figure 7: And when a LERCON comes in any flavor except the upper-left (Type I), life is going to be either rough (Types II-III) or just about unbearable (Type IV). But guess what? Even though most LERCON's actually are Type IV, most of them are conceptualized by management as if they're Type I. And this failure of management to acknowledge that it's facing a Type IV LERCON simply exacerbates the fact that it is this very type of LERCON which is most prone to procedural, substantive, and avoidable conflict in the socio-political, functional, and technical domains. From the considerations outlined in Figures 6 and 7, it follows that Figure 8 merely restates a truism familiar to everyone who's willing to acknowlege it: Figure 8 The REAL question, therfore, is not whether Figure 8 states an unwelcome truth. The REAL question is that asked in Figure 9: Figure 9: If the answer to this question is "no", then failed LERCON's will contunue to litter the IT landscape like the skeltons of whales beached long-ago. But if all the different players and actors shown in Figure 9 could get together and agree on a consensual LERCON process-model, then maybe it might be possible to roll-out LERCON's with less fuss, less muss, and much more chance of success. And as will be discussed next time, this is where the notion of a "Diachronic Metadata Repository" comes in ... as a conceptual structure and working tool around which to structure a consensual process-model for LERCON's.
