Seeing the big picture: Why modern business development is broken

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 organizations how to combine human insights, business needs and iterative design
  • the rise of agile, that has taught IT organizations how to organize and develop complex systems under uncertainty

Still, we see organizations constantly fail to deliver the value that business design teams uncover or that modern technology and data enable. Although business organizations are getting better at understanding customer needs, and IT is getting more agile, they seem to actually be optimizing the way they work separately, not together.

Today we see design thinking as the go-to way to develop concepts, while agile is the dominant way to go when bringing concepts to life. Seeing design and development as separate work lead to handovers that usually diminish value. Such 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 organizations should focus on minimizing all handovers done.

 In our experience there are many reasons for inefficiency in development. We have run into the following problems in many organizations (even in our own, to be completely honest):

  1. 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 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 standardized delivery model. Implementation is then re-prioritized 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
  2. 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.
  3. An organizational “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 team and API’s as a bridge between Business and IT

We encourage organizations in the 2020’s to build a bridge. This means creating a new model to develop and organize both work and architecture. We propose building a new team between IT and business that gives birth to both a modern way of development and uses API’s as bridges. 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.

Part 1: The new, clarified role of business units

In the new model, the business units of organizations 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.

Part 2: The impact delivery team

This new multi-disciplinary team between business and IT is where design thinking meets agile. The team takes business needs or problems from the business unit’s backlog, and uses API’s and data from core systems to create solutions.

We propose building 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 technology, data or design thinking are just different means to solve appointed problems or challenges.

Part 3: IT enables it all

People who understand both IT and business are core members of IT teams. IT is responsible for technical competitiveness in a changing business environment: Continuous improvement of technical capabilities and business critical core systems. IT also creates enterprise architecture and preferred development tools, technologies and methods. IT offers core system capabilities as fully functional two way API:s to impact delivery teams.

Benefits at scale

This Impact delivery approach combined with API’s as bridges makes it possible to create business development that solves the most critical problems of large scale companies to gain business performance by combining design thinking and agile. It enables natural time zones of development. Business development has to happen in days or weeks, capabilities in impact delivery team are developed in weeks or months and core system development takes typically months or years. API structure makes it possible to build new user interfaces fast on top of APIs. It makes it possible to change core systems without changing anything in the impact delivery 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, including DNA, Posti and LähiTapiola. After organising business development in this way we have seen radical improvement in both development speed and business results.

New call-to-action

This article has been co-written by Johannes Hirvonsalo and Jussi Olkkonen.