As a company, we've been involved in technology transformations with businesses of varying sizes for years. Some coming in part-way through, others, right from the very start. Below are some valuable points in areas we commonly support businesses with. It's meant as a key indicators blog that may get you interested to know more details. If you do, the details of the report are at the bottom.

Early adoption 

When beginning the transformation, start small in order to demonstrate how effective the change will be and then build momentum and gain buy-in at the executive level. The transformation will gain most traction when there is an executive sponsor and has other teams engaged who are on the same page and willing to help out.

Stages of transformation

The transformation can be broken up into stages. From the early pilot stage, where decisions into the strategic design happen, to later stages for scaling and optimisation, where increasing velocity in building software, standardising and streamlining the delivery of value become important. 

Identify challenges

Have a clear view on what challenges you're likely face and monitor for new issues as the transformation progresses. Some challenges to think about:

• It's easy in the pilot stage to focus only on initially delivering value to market; but this could contradict efforts at the scaling stage which should focus on repeatedly and predictably adding value, by reducing the risk and time it takes to deliver that value to customers. 
• It can be easy for the pilot team to become centralised in the transformation but again, this doesn't scale well. If your transformation works out as planned, you'll be moving too fast for us, mere humans to handle. So instead, increase focus on decentralisation and the adherence to technology by automating processes to remove even more friction.
• Old systems and processes can cause fast moving teams to grind to a halt. Changing the operating model will require focusing time on decoupling these systems and not simply rewriting processes around them. In a transformation, this serves little value. Change management and architecture review boards are common culprits.

Showing value 

Beyond presenting what the changes to the operation model will be, frame why those changes are happening and how they will be implemented. We've found that the bottom up presentation of the changes is as important as the top down view. To help with this, apply some effort into putting a structure and process in place that allows work tracking systems, such as Jira or Service Now, to present a view of technical work in easily digestible reports.

These processes and reports have a continuing positive impact throughout the whole programme, for both managers and engineers. Other important areas to consider are:

• transparency of what is happening
• having the ability to track and measure the success of the programme as a whole 
• being able to drill into individual projects' details
• modern reporting methods. Stop emailing spreadsheets to people and make use of the technologies available so that they are accessible online where the information is always up-to-date.

The measures used to track and govern a transformation across ab organisation have been shown to typically focus on a few key areas. About half of the measures shown in the report focused on the process of delivering technology whereas the other half focused on the value and outcomes that were delivered. 

Overmanagement 

It's common to be top-heavy in areas and have more "managers" than analysts or engineers. When this happens it risks a lot of wasted time in "management theatre" to justifying work. Instead, question the value of the output of these roles (they may be useful later on but not at the beginning), focus on delivery and put some effort in early to automate the presentation of reports and gaining feedback from users. Spending hours transferring information from different systems so that it can be shown in the 'right coloured box' doesn't provide any value. Instead, use the tools available to you to focus on making data driven decisions. 

That said, there are definitely places where the information needs to be collated together into more digestible formats. For example, you will not be able to engage your business leaders if you can’t frame your technology transformation in the context of how it helps them achieve their business strategy. Even here, it's important that there is a clear link from business strategy to technology changes. From an engineering and architecture perspective, creating a product requirements template and asking this to be completed for significant pieces of work has proven very useful for us in the past. This becomes a collaboration page between tech leads and strategists to progress reports and engineering/architecture plans.

Technical design 

Once we have everything framed correctly and stakeholders bought into the change, the next biggest impact which can be made is changing how we design things. Remodelling into product-centric architecture, projects, and even product-centric team structures have shown to be the most beneficial places to focus.

Changing into a product-centric architecture requires focus on value streams. Specifically, the existing architecture surrounding those value streams and how technology teams implement or operate them. There is a role within these teams for a value-stream architect. This doesn't need to be an individual, and can just be a role which is adopted by engineers or engineering managers as-and-when needed. This role should be responsible for streamlining the delivery of value items for each value-stream through transparent and visible metrics.

Below is a high-level plan that this role should consider. In the report there is much more detail on each point but this is a good set of steps to start discussions and refer to the report for more information if needed.

• Establish flexible, low-friction ability for teams to build
• Introduce architectural patterns that increase speed of delivery
• Event-driven architecture
• API-first architecture
• Domain-driven design
• Engage enterprise and business architecture organisations
• Allow teams to make architectural decisions 
• Move to cloud and cloud-native computing
• Initiate a “toolchain as a product” paradigm
• Focus on automation
• Adopt open-source platforms and tools
• Create architectural communities

Transformations should be considered to happen all the time. This is IT - if you think done with your transformation, you're probably about ready for the next one. Hopefully, if you've not considered some points covered in this article in your last or current transformation project, they can help you make some useful changes in the future.

This article is based on a report published on the IT Revolution Press https://myresources.itrevolution.com/id006657048/Project-to-Product-Transformation