Why you Should Not have an Innovation Department
Putting all innovation under one department or division is not a good idea as different types of innovations inherently conflict with each other and require a vastly different approach to innovation development. More specifically — disruptive innovation should always be kept separate from the rest of the innovation initiatives.
With rapidly increasing competition and new players entering the market, a traditional multinational company that I was working with, decided to become part of the change and started actively developing new services and disruptive innovations to compete with the disruptive entrants and startups. The task was assigned to an existing development department, which was already responsible for other new developments and investments.
Being in the heavy industry, typical investment projects took anywhere from 5 to 15 years and were fairly straightforward — over time, the company had become very effective in those and had a standard operating procedure for both developing its own facilities as well as buying others through M&A.
All these processes were similar to each other as they were based on a waterfall model (or phase-gate / stage-gate process) — there were specific procedures to follow in every sequential phase. As an example, you first had to do the market research to prove the opportunity, then get the preliminary agreements accepted, then put together the necessary documentation, then get agreements and contracts signed for the plot, then put in the order for production, then construction on the spot and finally put in place the maintenance.
Every phase happened after the previous phase had been successfully finished — there was no point to start the production before you had the necessary approvements agreed upon.
So, when new service development was introduced in the company, it was conveniently given to the experienced development department, as they already had the process in place to manage new developments.
The problem, however, is that new services and disruptive innovations do not fit well with a waterfall method. By definition, new services and disruptive innovations are in essence something that has not been done before, not in this company at least. That means you cannot clearly predict how it will end up working out technically, how will it be accepted by clients, or even how big is the market in the first place. Taking a waterfall approach to disruptive innovation means investing vast resources and time into building something that possibly no one really needs or that has no market.
Taking the Agile?Approach
You should not design the whole product or service if you don’t know if there is any market for it. That is why the agile methodology was introduced first in the IT sector — to rapidly deploy assumptions to the market, test and get quick feedback. You can then continue developing the product with real-life feedback and knowledge about your own product.
With new service development, especially those with disruptive potential, there are usually a lot of assumptions involved, not just one or two. Initially, you might not know if the whole idea is plausible, technically achievable, or legally acceptable or if it makes sense financially. Then you might not know if anyone would buy it, how much they are willing to pay for it, or how big the market is for it. And finally, you cannot predict how users would actually use it, how often they would use it, how and if they would promote it to other users and much more. These are all assumptions that need to be tested over the course of the development process.
The agile as well as lean development approach is about constant testing and validation of the assumptions, which means that certain processes like design, development, business development and testing need to happen in parallel not one after another. The product currently in production is also much smaller than it was initially envisioned — you just need the basic minimum viable product (MVP) to be built so that you can specifically validate your most critical assumptions. Once you have done that, you iterate from your MVP to add new functionality based on the next most critical assumptions and so on.
Organisational challenges
Agile was not an unknown term for my client organization — in fact, their IT department considered itself working based on agile methodologies. However, the agile approach was not appropriate for the investment heavy long-term projects that were typically managed in the development department. You cannot build an MVP for a $100 million production facility — a project that becomes profitable with scale and has little room for assumptions.
To adapt its processes to service development, new procedures were introduced. However, these tended to be a smaller version of the existing framework. The time period for project development was decreased considerably but it was still a waterfall method — you still had to follow certain procedures and bureaucracy to reach an MVP for example. It was overly complicated to change one team within a department to become agile while the rest of the department, management and organisation stayed within the waterfall framework.
Instead of organisational lobbying, they need to go on the field to talk to the customers
The agile approach also expects smaller investments compared to the waterfall approach. This proved to be again a complicated mindset shift for a department that was heavily focused on raising high investments and whose whole structure supported that — it was a lot of work to get the investment decisions agreed upon, so it made sense to ask for bigger amounts rather than small junks of resources.
And finally, the whole development department was meant to be a highly cooperative division within the organisation — no project was done in silos or independently, each R&D project or M&A initiative was always done in cooperation with some other department, often in cooperation with several departments. Although this is a good thing in certain innovation initiatives, it also makes it a challenge to execute fast and lean — having so many people from many departments with their own agendas and daily routines means a lot of time was spent on multitasking and cross-functional bureaucracy.
Division Based on Innovation Types
Instead of trying to fit all innovation within one department, it is important to embrace the vast differences in innovation types and divide the responsibilities accordingly. In Ehasoo & Sons, we divide innovation into four different types — incremental and radical innovation (sustaining innovation types), disruptive innovation and disruptive technology. However, in this context, we just need to divide it into two — disruptive and sustaining innovation.
Innovation Management for Sustaining Innovation
Both incremental and radical innovation types are based on technological competencies rather than business model innovation, which means that they are easier to plan for. With technical innovation, you are dealing with known unknowns which makes it possible to use proven project management and risk assessment tools as well as the waterfall method to execute. This can include both radical and incremental technical R&D as well as expansion and M&A of well measurable sustaining innovation projects.
These procedures and tools are a standard competence for development departments in any larger organisation and it is a good idea to keep this know-how in one division to maximise the effectiveness of sustaining innovation over time.
Innovation Management for Disruptive Innovation
Disruptive innovation on the other hand is dealing with business model innovation, which means that it requires a change in business model — that could be anything from changes in revenue models (instead of sales per unit you might have a subscription model), change in the supply chain (leaving out the middlemen), change in customer segments (focusing on the end-users of your business customers (B2B2C) instead of just B2B) or other. Because of the nature of the exploration and the number of unknown unknowns, this kind of innovation is not easily analysable beforehand. It needs a different approach from the typical waterfall method — it needs lean and agile methodologies to execute.
Instead of high investments, agile teams need smaller investments and small teams that are as free from the organisational bureaucracy and burden as possible. Instead of high organisational knowledge and background, they need high empathy for the users and customers. Instead of organisational or external lobbying, they need to go on the field to talk to the customers as much as possible.
You cannot build an MVP for a $100 million production facility
These opposing requirements compared to sustaining innovation means that these small innovation teams are also better off being separate from the rest of the (sustaining) innovation development division. Instead, they should be located closer to the customer — customer relations or sales divisions would be a better organisational location for them. But there could even be a small innovation team (or just one intrapreneur responsible for it) under every other department — an innovation team in IT for exploring new ideas from the IT department, in HR for HR innovation initiatives etc. In fact, there could be an agile innovation team in every department EXCEPT the development or R&D department which is responsible for sustaining innovation.
This does not mean, however, that there cannot be any cooperation between the agile innovation teams and the development or R&D department. The development department could be helping with the mentorship of these teams and providing the resources they need to execute.
If the business model innovation (disruptive innovation) also includes radical technological innovation (disruptive technology) then the executing innovation team needs to cooperate with the R&D department, but it also needs to have some of the R&D experts (engineers) included in the team to achieve the best efficiency. Agile innovation teams always benefit from the cross-functional and diverse backgrounds of their members as long as they have enough independence to operate freely in their own agile approach.
The Solution for Innovation Department
In conclusion, you can have a dedicated innovation department, but it is important to not give them full ownership of all the innovation initiatives. Innovation, especially the disruptive kind, should be distributed over the whole organisation and be separate from the traditional R&D or development department that is rightfully working in a waterfall framework.
Division of ownership does not mean a lack of cooperation, however. The innovation department could be the innovation coordinator and promoter within the organisation — a valuable partner for agile innovation teams to help them focus on their primary tasks at hand.
Looking to evaluate your organisational innovation capabilities? Contact us on ehasoo.com for an in-depth Innovation Audit.