The past decade has seen significant advances in how new business is developed. The biggest two notable changes have been
- the rise of design thinking, that has taught business organisations how to combine human insights, business needs and iterative design
- the rise of data and agile, that have taught IT organisations how to organise and develop complex systems under uncertainty
Still, we see organisations constantly fail to deliver the value that business design teams uncover or that modern technology and data enable. Although business organisations are getting better at understanding customer needs, and IT is getting more agile, they seem to actually be optimising the way they work separately, not together.
Today we see design thinking as the go-to way to develop new business concepts, while data and agile is the dominant way to go when bringing concepts to life. Seeing design and development as separate work and separate functions leads to handovers that usually diminish value. These handovers between teams cost time, money and usually end up in the project getting out of sync with the essence of the concept. Instead, modern organisations should focus on minimising all handovers done.
In our experience there are many reasons for inefficiencies in development. We have run into the following problems in many organisations (even in our own, to be completely honest):
- A Culture of “business orders” and “IT delivers” in business development. What this means is that usually businesses use design thinking to create a concept and then hands over a technically semi-realistic plan to IT for implementation. In any given moment in time an IT backlog is typically super full. To cope with demand IT usually has a standardised delivery model. Implementation is then re-prioritised to match the delivery model and the end result is usually the concept not being ready in time and does not directly solve the identified business problem and/or deliver the intended customer value. We tend to hear IT departments saying that the business side is expecting both unrealistic delivery times and mind reading skills from tech teams.
- Systems renewal by merely asking what features does the business need. We see a lot of ERP, CRM or order management systems etc. renewal projects where IT is running a series of workshops where different business units are asked what features they need in a new system. Feature lists are then implemented in an agile way. The end result is unfortunately a very complex set of features that usually mimic old processes instead of transforming the way business operates in real life – which is usually the exact reason a systems renewal started in the first place.
- An organisational “game of thrones” between business and IT. Because the aforementioned great divide, Business and IT are invading each other’s spaces in search of power and/or efficiency. For example, IT departments are taking over business’ critical customer touchpoints such as applications and other digital interfaces because they are perceived as technology. At the same time business units are building their own separate business IT departments because their corporate IT is too slow in business development. The end result could either be (as was an actual case) a 1.5 star rating in an app store customer review or what we call integration spaghetti (several separate integrations) that is impossible to maintain in long run or both.
Fixing the big picture: The impact delivery model & API’s as a bridge between Business and IT
We encourage organizations in the 2020’s to build a bridge between Business and IT. This means creating a new model to develop and organize both work and tech architecture. We propose building a new kind of team between IT and business: We call it the impact delivery team. The team gives birth to a modern way of organizing development and uses API’s as bridges between business and IT. It enables letting both business and IT concentrate on what they are naturally good at and results in a dramatic increase in development speed while reducing the number of integrations and development costs. Let us explain, in three parts.
Part 1: The new, clarified role of business units
In the new model, the business units of organisations are responsible for everything that the customer sees and experiences and is free to develop things at a very fast pace according to business needs. In technical terms all UX development including the frontend coding and API integration coding are part of business units and working in teams with business people such as finance or sales. Business units have control over customer experience. For example Posti has organised consumer and SME development in this kind of organisation called postinext.fi.
Part 2: The impact delivery team – a data driven business process team
This new multi-disciplinary team between business and IT is where design thinking meets data and agile. It is not a part of business organisation nor IT, but resides right between them in an org chart. The team essentially takes on business needs or problems from the business unit’s backlog, and uses API’s and data from core systems to create new solutions.
For the impact delivery team to work, it is required to build a team that is truly multidisciplinary. This is a team with data, business, design and tech people with high problem solving and co-operation capabilities. In their work data, technology or design thinking are just different means to solve appointed problems or challenges. We have been experimenting with the impact delivery team in a few of our engagements with very promising results.
What the team is typically working on is changing core business processes such as customer service, sales, production, service or supply chains. Data and design thinking enable process re-engineering. For example at Amer Sports transparent data of the Suunto supply chain made it possible to rewrite sales-, sourcing and logistics processes. New processes enabled millions in cost savings and better customer experience. Job descriptions changed. At Amer the way sales reps are working now is completely different. Instead of force selling products to reseller they have real time data on inventory and sales volumes of each store. In the core of job description is helping stores to improve customer experience and Suunto sales.
Part 3: IT enables it all
People who understand both IT and business are core members in IT teams. This is because IT is ultimately responsible for technical competitiveness in what is today a changing business environment: There is a need for continuous improvement of technical capabilities and business critical core systems. IT also creates enterprise architecture and preferred development tools, technologies and methods. In this model IT offers core system capabilities as fully functional two way API:s to impact delivery teams.
Benefits at scale
The Impact delivery approach described above combined with API’s as bridges makes it possible to create the foundations for business development that solves the most critical problems of large scale companies that want to combine design thinking and agile. It enables “natural time zones” for development: It enables customer facing business development to happen in days or weeks, new capabilities in impact delivery team to be developed in weeks or months and leaves core system development time develop in it’s own pace. The API structure makes it possible to build new user interfaces fast on top of API’s. It makes it possible to change core systems without changing anything in the impact delivery team/business process team or business units. New companies in the data driven business environment are born this way. Others will have to change. No company can afford to keep business and IT separated as they are today.
We are already working in teams in different forms with several of our clients, for example Amer Sports, DNA, Posti and Helkama-Auto. After organising business development in this way we have seen radical improvement in both development speed and business results.
