Technology Led Transformation: The Business’s Contribution to Success or Failure.

Most experienced executives are inherently cautious around major technology transformations. In our transformation work, we at the Bevington Group have found that most executives appreciate the risks of cost blow-outs, delayed delivery dates, software bugs, customer impacts and decreased productivity (even if temporary) on deployment.  Overall, the cost of managing these risks often severely impacts on the ability of the business to realise the expected benefits.

Yet, in spite of the risks, there are often very strong drivers to move to new core technology platforms. For example, you may be toiling with older systems which make your organisation unresponsive, expensive and unable to support future growth plans, or your systems may be so fragmented that error rates mean that you lose more customers than you keep.

So, where and why do so many projects go wrong? Well I am not going to address questions of project management here, there has already been an enormous amount written on this. Instead I am going to take advantage of my experience leading the Bevington Group, and take the perspective of the program’s Business Sponsor.  This article will describe what can be done to improve the chances of a business successfully delivering technology lead transformation. In particular, the business needs to: communicate what is needed; receive what is expected; be ready to use the system’s new capabilities; and be ready to reap the defined benefits.  To do so, we will very briefly outline some of the traps which are often neglected in transformation program establishment and management.

Technology Driven Process Improvement – The Pitfalls

Imagine you are in an enterprise which has a core system infrastructure with multiple flaws: it is on old technology which will soon be unsupported; it is difficult to develop new functions or interface with it; it does not enable effective digital communication with customers; it does not help manage quality or workflows within the organisation. All in all it is inflexible and, relative to competitors, makes your services expensive and/or prone to errors.

Given this, you decide to replace your core systems. Immediately there are activities that can improve your chances of success, and which most good programmes will initiate. They are: establish governance structures; appoint programme leadership; ensure business ownership and start building a robust plan. However, sadly, many organisations miss the most important step, to answer the question “What do we really want from the system?”

Effective Change Management Means Defining Your Business Operating Model

You cannot be vague about the business outcomes of a system transformation. Mentioning terms such as “digital”, “integrated” or “flexible” do not give you sufficient clarity to decide between system options. Instead you must first clearly define how you want your business to work. Your Business Operating Model (or BOM) will incorporate: process; structure; role design; capabilities; policies; metrics; business disciplines; and, naturally, technology. Written in business language rather than technical language, the BOM description ensures the leadership team has a common understanding of where the organisation is going. To state the blindingly obvious, but often missed “If you do not know how your future business will operate, it is unlikely that the new system will help you get there”. So, do not start detailed specifications on a system until you have defined your future Business Operating Model.

OK, so let’s assume you avoided the first early trap: your leadership team have a common view of where your enterprise is going, and what it is going to look like. This provides a firm starting point to begin the requirements journey. Now to avoid the next trap: over and under-specification. It is extremely common for an organisation to put an enormous amount of effort and detail into specifications of functions that are not core. Subject Matter Experts can spend an inordinate amount of time specifying solutions to today’s problems, rather than ensuring that the future core engine of the business is properly described. Essentially, those deep in specification can become lost in the weeds, and end-up rebuilding today’s model.

There are a number of ways the specification problem can be addressed. The first is to deploy an “off the shelf” system, and limit changes to configuration (i.e. changes to the “settings” of the software rather than changing the programming). This provides the opportunity to go “specifications light” – why spend a fortune specifying something that is already built? The focus can then be on using the system’s existing functional specifications to define the processes and ways of working, and then validating this with the software provider. Changing functional specifications, when you are buying an off-the-shelf system, will increase complexity in deployment, defeating much of the purpose of an off-the-shelf package. After defining your Business Operating Model, you are often best choosing an off the shelf system that, whilst potentially imperfect, best meets those needs.

However, often a custom build solution is required, within which there are different options to manage specification risks. One approach is to use agile methods, which are “documentation light” and “testing heavy” methods to build software. This has significant advantages over waterfall methods, as it avoids getting lost in a mountain of specification paperwork. Unfortunately, it might be a stretch to use these approaches on large, IT lead transformation. Other approaches involve specification in software tools that enable you to see and prioritise requirements as you go. This latter approach is becoming increasingly common, but beware, in the wrong hands they increase, not decrease, “befuddlement”. The best approach is not to use SMEs to start with individual requirements, but rather have architects focus on describing core functionality, interfaces, workflows and outputs, in a way that supports the Business Operating Model.

Business Readiness Is Essential

Ok, so let’s assume you have been a particularly perceptive leadership group, you know what you want your business to look like, you have avoided specification traps, and you may even have a system which is performing as expected in a test environment. The next question: is your business actually ready to receive it? Well, this is actually a very vexing question. One has to consider: processes; procedures; staff capabilities; role design; structures; support models; geographies; and metrics (to mention but a few).  Given the scope of work, “business readiness” is not a last minute activity. It is, in fact, the key component of achieving the behavioural change needs to successfully transform.

The complexity can be seen when looking briefly at process design; role design; and staff capabilities. Appropriate tools must be used to design roles and processes together providing an understanding of how work is done, and who does it. Following this, the process risk is assessed, the gap in staff capability understood, and plans to resolve are developed. The key message here is that you should be spending a substantial amount of your total time and budget getting “business ready” for the technology transformation.

Now, lets’ assume you have reached the stage where you are planning your deployment.  In truth, technology risk is only a part of the challenge in good planning. As a Business Sponsor you also need to be concerned that people know what is expected of them, know how to use the system, know the new processes, and understand why this change is so important for them (because it is bound to require additional energy from staff). All of this (and more), needs to be considered in your Change Management plan, which becomes one of the cornerstones of your deployment plan.

So, if you design (and agree) your Business Operating Model, select the system to best match, control the risks inherent in requirements, and manage deployment such that all elements of a Business Operating Model are addressed, then you will avoid very significant program flaws.  Naturally this is not a conclusive list of challenges, but they are challenges which are overlooked as we, quite rightly think about good governance, reporting and project management. Being alert to challenges from the business perspective can save you a lot of time, money, and heartache, and allow for a successful transformation.

Roger Perry is Managing Director of the Bevington Group, Australia’s leading specialist in organisational design, process improvement, and change management. He publishes widely and is one of the region’s foremost productivity improvement and organisational design experts. Contact Roger at roger.perry@bevingtongroup.com

To learn more about Bevington Group’s consulting services, click here.

CEO-June-Tech-Transformation-v3-1Download a PDF of this article – Technology Led Transformation: The Business’s Contribution to Success or Failure.