On this occasion it’s an analytics solution, create a team together that’s representative of the user spectrum, alongside a team of developers both internal and external. Storyboarding finds the common ground across user profiles and geographical boundaries whilst keeping sight on building a solution for all. The requirements are captured, basic wireframes are created with various users in streams to build a complete solution in the least amount of time. A risk with streams and different team is a lack of consistency and potential duplication, different developers build in a slightly different way. It can often resemble a cooking class. Everybody starts with the same basic ingredients, yet the recipe may be interpreted differently and with creativity in presentation being wildly different. This is not desired from enterprise solution that should be delivering a mechanism for data driven decision making. The end solution will fall short of delivering to the business need and requirements. One project outcome that really stuck was the announcement at the end of the project that there is now capability to measure 96 KPIs across several domains. A discussion then ensued on why no one was using the solution!

Unpacking the example above the intent was correct, the desired outcome was to take the business forward so why did it fail? A representative group of users and people were engaged, the choice of technology was appropriate, the collective mindset was focussed on increasing speed of decision making with accessible data and visualisations. The oversight was that the ambition assumed that what the business was doing today was needed in the future. Process changes and change management were required yet not acted upon. 

Taking a further look at the role of change management, a cornerstone in this area is Leavitt’s Diamond Model which was developed in the 1960s and he went on to categorise ‘industrial organisations as complex systems in which at least four interacting variables loom especially large: task variables, structural variables, technological variables, and human variables1.’

In the analytics example provided, organisational change was necessary, it was assumed that this would happen as the technology provided would be sufficient to understand with some basic end user training to provide the necessary capabilities to adopt the new solution. What was overlooked was the mechanism and desired end state to have a new approach to understanding the business and a common language established that could be shared and understood by all that interacted with the solution. Leavitt categorised this as task variables.

The work of Leavitt evolved and in the 1990s the task and structure were merged to create the people, processes and technology (PPT) framework which has become a methodology for software development, this is focused specifically to the development process and not taking into account the wider organisational context and assuming that the business processes were optimised and as such the technology should support what already exists.

A McKinsey review at the end of 2022 concluded undertaking, a successful tech transformation requires strong leadership, careful planning, and top skills, from design to management to execution. Though each transformation is unique, the most effective start with three key principles2:

• Develop a sound understanding of the business’s strategic goals and the technology changes needed to deliver on them. 
• Drill into identifying the key dependencies. Executing a tech transformation starts with a highly disciplined process to drill into “root dependencies” to understand what needs to be in place to enable further progress. 
• Scope the work to something that’s aggressive but manageable. Tech transformations are large and complex initiatives. Unless they’re scoped adequately—not so big that they become too complex to manage, and not so small that their impact is negligible—progress is hard. 

What has become apparent with the creation of agile development and the willingness to fail fast, the scope of work is without a doubt aggressive and on the verge of manageable yet it’s the other elements of understanding the business’s strategic goals and more important the key dependencies that are overlooked, resulting in an MVP that in isolation withstands a pressure test yet when integrated into the organisation’s technical environment fails due to isolated development.

What’s next for the evolution of Leavitt’s model transitioned to PPT and proposed to become PPTD. Data is key, this has been discussed in a previous reflection. Data is essential to the survival of a business of any size today. A PPTD framework would offer a more complete and valuable picture of the whole enterprise3 specifically if desiring to embrace the power of AI is fundamental to the strategic goals and ambitions.

With what we have learnt over the last 60 years what should we do today? Slow down to speed up, do the groundwork well. Evaluate the business processes, are they fit for the future, do they support the strategic goals of the organisation? If not, take the opportunity to fix the process, understand the dependencies to find efficiencies. Treat data with respect and integrity, invest in data governance. Engage the right people at the right time and take the organisation on a journey avoiding the grand reveal moment at the end. Start small, utilising test and learn. Embrace fail fast early, not right at the end and avoid the realisation of why no one understands why there is a lack of appreciation of 96 visualised KPIs!

Article sources

1. Leavitt, H. J. (2013). Applied Organisational Change in Industry: Structural, Technological and Humanistic Approaches. In J. G. March (Ed.), Handbook of Organizations. New York: Routledge (pp. 1144–1170). First published in 1965 by Rand McNally & Company.

2. McKinsey (McKinsey.com): “Tech:Forward approach to a tech transformation | McKinsey”

Accessed October 2024

3. Downes, N. (Medium.com): “Leavitt's Diamond Model in the age of AI | Medium)”

Accessed October 2024