IT-engineered Corporates: How to implement with grace digital transformation

A recent – still on-going – movie saga narrates about genetically modified soldiers, who acquire “super” powers at the cost of “minor” unpleasant side effects.

This transformation is done by means of engineered viruses, whose strains are secretly modified, to which these “voluntaries” are exposed.

This seems very close to the situation of digital transformation, where too many CEO expect to turn own Corporates in “super” Corporates, just by “injecting” over-powered technologies in their operational contexts.

Unfortunately, when it is not done properly, this may result in outcomes, which are opposite to expectation, that is “minor” improvements at the cost of “super” unwanted side effects.

As digital transformation cannot be avoided, the point is how to make it right.

The parallel between IT and genetics is not that weird, and this will be explained in the following paragraphs. In fact, some concepts from medical domain can be used in Corporate domain, for anticipating issues and driving changes.

After all, any Corporate – regardless its size and mission – is a living organism, whose cells – employees – perform general and specialized functions, and share the same Corporate aim, making the whole system stronger by each individual contribution.

In this perspective, each CEO must care of making own Corporate grow, by offering best possible nourishment (in both solid and abstract terms) and environment to each cell of this organism. If the CEO makes own job right, cells – employees - will deliver.

IT platforms and viruses

Rabies turns also quiet animals into aggressive creatures, whose only mission becomes to spread the disease by infecting more animals. Hence, the virus of rabies can change mission and behavior of infected subjects.

While digital innovation is introduced with the intention of change for improvement, it is not granted that chosen platforms are aligned with such intention because, for instance, their impact on new processes and performances can be dramatically inadequate to expectations.

In fact, the selection and design of change enablers – IT platforms – is often carried out from a stand point too far from operational level, and it may result in complete misalignment with real needs to be fulfilled.

Employees equipped with wrong platforms, and obliged to bad processes, may hence turn into aggressive creatures, whose bad feeling and stressed attitude may propagate also to functions not directly affected and reach – eventually – also the customers (when the journey does not go the other way, as it may happen with e-commerce applications).

Therefore UX – User Experience – must be carefully designed by balancing expected business results and real capabilities (as-is and to-be) of targeted users.

The only way to design right the UX is to know who the planned users are, and what they expect to happen when engaged in the process through any IT platform. It is about knowing the “persona” inside the user and addressing his/her needs.

Too often, once identified the complete segmentation of users’ population, it appears clearly that it will be impossible to deploy for all of them at once a satisfactory solution.

The logical consequence of such circumstance should generally advise to offer initially platforms only to those users, whose persona will find UX at least acceptable, better if enjoyable.

If many personas are identified, it will make sense to order them in terms of priority and program, in accordance, the development and deployment of the platforms.

For instance, Persona No.1, Persona No.2 and Persona No.3 will be targeted for first launch, while Persona n+1, Persona n and Persona n-1 will be left for last run, when the platforms will deliver the full set of expected functionalities and performances, which will meet also their needs.

Such progression – persona after persona - would not only avoid disappointment and friction from certain categories (which are not served well) but will also confine possible issues only to those segments of users, which are piloting the initiative.

To make this happen, in practical terms, the exercise consists in structuring processes, features and performances to have fully satisfactory UX for all the users, whose personas are prioritized.

In the following picture, this is exemplified by defining Cluster A, Cluster B and Cluster C, each of them able to deliver features/processes for improving/completing – in incremental fashion - what is needed to fulfill expectations of all personas progressively included by the merge of clusters.

In this progression in example, Cluster A provides core minimum requirements, which will satisfy only two types of personas.

Entry level is not negotiable. This means that anything below this threshold of acceptance (e.g. process completeness, features, performances) will make null and void the business case for the IT platform.

Cluster B will add more functionalities and processes, on top of those provided with Cluster A, and enable three additional types of personas to be served by such enhanced IT platform which, compared to Cluster A, moves its qualification from basic to advanced.

Finally, and similarly, Cluster C will address the last missing type of persona and make the IT platform complete and fully developed/deployed.

Naturally, each stage of development/deployment must be stable, complete and performant from the standpoint of the targeted personas. This is the way to have smiling employees and customers instead of rabid humans, who will not help with reputation and value of our Corporate.

Daniele Rizzo ? 2019

While time does not appear in above scheme, it is of course crucial to manage this variable with utmost care. Indeed, time impacts not only costs, but also the overall success of any IT initiative because delivery of all clusters must happen within the available window of opportunity.

Systemic infections

According to medical definitions, “systemic” means affecting the entire body, rather than a single organ or body part. Hence, a systemic infection is not localized and cannot be countered by acting on the hosting portion of the sick organism.

Fortunately, infections are not always systemic and majority of them can be treated with appropriate drugs, up to the point of having them eliminated or, at least, confined and controlled.

In case of digital transformations, it is uncommon that a single IT platform is applied across the whole Corporate structure, while it is usual that a set of platforms is implemented, going to have a systemic impact by means of combination of localized specific consequences.

Corporate functions (ranging from M&S to Finance & Administration, from HR to R&D, from SCM to Industrial Operations, etc.) have own processes and enabling platforms. However, while compartmented, all of them have dependencies in input and output, hence improvements (or malfunctions) in one portion, or more, of the value chain may propagate across the whole system.

Once established the similarity between platforms and viruses, let’s overview the other elements which must balance these forces and drive their implications.

Precautions and warning signs

When it is about digital transformation, if the analogy with viruses is taken, nobody can choice a “no vax” standing. IT enablers must be introduced, but this does not mean doing it without precautions and preparation. Fortunately, to mitigate risks, common sense may help.

First precaution is to avoid deployment plans too fast and too wide.

Successful introduction of a new platform is not done just because an account is created on a web-based software. It is impossible that dropping such a big thing on the head of thousands of users will result automatically in a smart deployment of the related process.

Common sense would suggest selecting a significant pilot and trying the deployment on such controlled scale, before extending the practice across the whole organization.

Be very careful with suppliers pushing for accelerated deployment plans! Once introduced, the epidemy might be not easily eradicable.

Second precaution is to have clear and documented processes, which must be properly designed, programmed and executed by means of the new platform.

This is a reinforcement of the first precaution, as without a strong command of the process, any platform will lead to a chaotic business environment, regardless the speed of deployment.

Indeed, in absence of such prerequisite, the supplier of the platform will effortlessly fill the vacuum with own interpretation and deliver inadequate – too often wrong - solutions (unless this supplier is equipped with supernatural mind-reading powers and/or rare acumen).

If explained A-B-C concept is applied, end-to-end activities are logically segmented, and functionalities clustered and made scalable, in terms of both users’ populations and processes.

For instance, CPQ (Configure-Price-Quote) activities cannot be segmented in separated C, P and Q, processes, because nobody needs these distinct parts, which are a whole in the business practice.

This does not mean that one platform must perform the whole CPQ process, it means that optimization of the CPQ process, across the possible combination of platforms which is needed, must be made with a complete end-to-end vision and leadership.

On the contrary side, Order Entry is a distinct step in the commercial process, which is appropriate to separate from the tendering – or self-tendering – phase carried out during CPQ.

You may want to make it seamless (see, for instance, Amazon 1-Click? ordering), but in general a border with hand-shaking and check-points, from one step to the next, is highly advisable.

Third precaution is to never lose sight with users’ community and stakeholders.

Only the systematic and appropriate engagement of these persons will provide the necessary support and momentum to make progress in tough moments and leave behind obstacles and errors (which are unavoidable).

While command, leadership and ultimate responsibility must stay concentrated in the hands of Program Manager, this person has the duty of sharing information and getting validation of range of options (before taking crucial decisions).

This list - limited to three basic precautions - could be much longer but, in our view, these are the basic for helping to create a robust firewall, against catastrophic conceptual errors in approaching the subject of digital transformation.

Effectiveness in IT-engineered organizations: Two scenarios

When IT initiatives are launched, these are expected to make a deep change, i.e. to achieve “digital transformation”, aimed to dramatically improve performances of impacted Corporates.

If we look to any general category of performance, and we analyze the effectiveness curve which may be valid for any process, the picture in the following may trigger some reflections.

While it is possible to develop alternative scenarios, with respect to those showed below, we believe that they represent significant cases, especially as applicable to large organizations.

Certainly, in any population of employees, at initial time when IT initiatives were launched, there will be an average value of effectiveness, which is the weighted result of overall performance of each individual employee.

Once the average is measured, two groups can be organized, so that a % of employees will fall above the average and the complement to 100% below such KPI.

It is also reasonable to assume two different average effectiveness curves, one for the portion of high-performant population (AH) and one for the portion of low-performant population (AL).

In both these two scenarios, Case 1 and Case 2 (as showed in the picture), it will be assumed that – with deployment of new IT platform - less performant population will improve, while effectiveness of more performant population will worsen.

This second effect is not unrealistic as high performers – very often - are such because of their personal optimized processes (combination of both experience and tools), which they will be forced to leave for embracing new practices within the constraints of new platform.

It is also worth noting that in these examples AH will remain higher than AL, but this is not necessarily and always true. Indeed, introduction of new platforms may trigger “mutiny”, and make high performers degrade to the point of moving down to low performers’ condition.

As we will remark, the % of employees in the two categories, AH and AL, and their respective initial conditions, will make a huge difference on the outcome of the IT initiative.

As Galileo Galilei wrote, measure what is measurable and make measurable what is not.

More recently, and closer to our context, Peter Drucker stated that if we cannot measure something, we cannot manage it, hence launching any initiative without knowing from where we start is generally a foolish action, and we will stress this in reviewing the cases.

Case 1: Reduced average effectiveness

In this scenario, by introducing a new IT platform, there is the unexpected paradox to have a resulting average effectiveness of the process – New Average Effectiveness – which is lower than initial average effectiveness.

This worsening is usual with situations where, by working on averages, projects are led to mistakes, due to misleading interpretation of reality and assumptions.

For instance, demotivation of high performers may be underestimated or, simply, it was not considered – and precisely measured – the value contribution of legacy processes, which were enabling high performers to deliver more, up to offset the lack of effectiveness of the rest of the employees.

Fact is that increase of effectiveness of low performers is not enough to compensate and overcome the loss of performance caused by degradation of high performers.

Case 2: Improved average effectiveness

In this scenario, the IT initiative has accomplished own mission, as New Average Effectiveness is higher that initial average effectiveness.

Improvement on low performers has offset reduced effectiveness of high performers and created an average improvement for the whole population of employees.

For instance, IT initiative has filled an organizational gap that was affecting low performers, who were not equipped with adequate processes and tools to make own work effective.

This worked double-edge with high performers, but now the Corporate may afford to employ less skilled people to achieve better results, and to move more creative and self-organized persons to appropriate tasks and responsibilities.

This latter consideration on organizational impact leads to next paragraph, which is about those blue pyramids and eggs showed in the picture.

Outliers: How to handle exceptions

Regardless the shapes of effectiveness curves, and respective categories of performance, there will be always someone – possibly a little minority - left outside.

In the picture, there are pyramids, which stay above the curves of effectiveness of high performers, and eggs, which stay below the curves of effectiveness of low performers.

Once digital transformation will go in steady state, the Corporate should understand why these people are there and – only after this step - decide what to do with them.

A decision made without reflection would go in the direction of firing the eggs (too low performers according to new standards), and just leave pyramids as they are (after all they do better than rest as they always did).

A better thought may suggest different options.

For instance, maybe pyramids have adopted the new platform and developed optimized processes (which the rest of employees has not found yet).

In this case, instead of letting pyramids to their own devices, Corporate should engage them and explore how to extend these smart practices to everybody, by means of training or just by setting these benchmarks to everybody as a stimulus for improvement.

Similarly, before deliberating their possible dismission, eggs could be preciously engaged to understand why they are doing so poorly and identify – possibly - bottlenecks, which are objective and affect not only the performance of eggs (but the whole population of employees).

In a way, like canaries in a coalmine, these supersensitive eggs may help in removing constraints and flaws in the processes/platforms, that other employees also experience but overcome possibly by work-around, whose generated inefficiency remains and would go otherwise unnoticed.

Conclusions

It is hard to avoid costs overrun [1][2] and delays when an unprecedented undertaking is launched. Far from being a justification for waste of money and time, this statement is offered as an invitation to combine prudence, tactics and strategy.

The necessity to embrace change does oblige to be equipped with utmost sense of responsibility and appropriate sensitivity to risks and implications, while speed of change does not justify dropping the good practice of planning with flexibility.

On the other hand, from the experience of Helmuth Karl Bernhard von Moltke, we know that “No plan survives the first two minutes of battle”.

Hence, as always, we make our best – even more - and keep Plan B ready!

References

[1] “Megaprojects and risk: An anatomy of ambition”, Bent Flyvbjerg, Nils Bruzelius, Werner Rothengatter (Cambridge University Press – UK - 2003);

[2] “The cost of poor-quality software in the US: A 2018 Report”, Herb Krasner (Consortium for IT Software Quality CISQ – USA - 2018).

 #transformation #digitalization #change #strategy #IT