The Blue Ocean Management Strategy

W. Chan Kim and Renee Mauborgne, two professors of strategy and international management at the INSEAD business school wrote about their ideas of a “Blue Ocean Strategy” in a famous management publication in 2005. The framework that Kim and Mauborgne described in their book intended to help companies swim free of the threshing, bloody red ocean of corporate competition into calm and uninfested waters – the blue ocean.

The Blue Ocean Strategy formulisation follows four principles;

1.    Reconstruct market boundaries

2.    Focus on the big picture, not the numbers

3.    Reach beyond existing demand

4.    Get the strategic sequence right by building the strategy in the following order; Buyer utility, Price, Cost and Adoption.

The blue ocean strategy is tied intrinsically to innovation and this is what fascinates me. It is a well known fact that value innovation makes competition irrelevant by creating a leap in value for customers and the company.  Several quotes from Kim and Mauborgne’s book ring clear and true and I find them particularly relevant to software consultancies vying for a slice of market share in 2008.

Quotes such as;

1.    When a company’s strategy is formed reactively as it tries to keep up with the competition, it loses its uniqueness.

2.    The focus on the red ocean is … to accept the key constraining factors of war – limited terrain and the need to beat an enemy to succeed.

3.    Value innovation is a new way of thinking about and executing strategy that results in the creation of a blue ocean and a break from competition.

Following my last post regarding the relationship between Innovation and Organisational Structures, I have had some interesting discussions with colleagues regarding the subject. From these conversations, I discovered that innovation and invention are sometimes interpreted as being synonyms of each other. I would think that an invention needs to be first marketed before it can be innovated upon and that the terms are definitely not synonyms. I have perhaps heard of the most succint definition of innovation from Teresa Amabile of the Harvard Business School who described innovation as “the most successful implementation of creative ideas within an organization”. 

In practice, I have always believed that innovation and most importantly; value innovation should be an underlying design principle while building and/or implementing software. Irrespective of whether a company is services-based or product-based, every component designed and every line of code written should have a secondary agenda; to be reused and componentized for an easy re-sell. This ties in directly with the Blue Ocean Strategy since any software written with the above principles in mind is flexible enough to either glue together a new product and/or service and support shifts or changes in company strategy.

Innovation and Organisational Structures

While most software consultancies or system integrators are profit focused and choose to exclusively deliver services on top of existing platforms (that are well-defined thereby reducing project risk), there are some consultancies who boldly choose to differentiate themselves by concurrently fostering innovation based on experiences and suggestions from staff. Staff at these consultancies are often more focused and motivated because they believe that they are a valued asset and have an opportunity to grow their skill sets since innovation is almost always spurred by new, radical thinking. If these innovative ideas do reach an implementation stage, solutions are typically implemented across a range of current and anticipated technologies to keep the product future-proof. This allows staff in the role of consultants to ”early adopt” new technology and gives them the ability to guide the consultancy’s existing clientele towards possible implementations of newer technology; opening doors to new business opportunities. 

From personal experience, innovation finds its biggest obstacle in a consultancy’s organisational structure. I have worked in bureaucratic and adhocratic organisational structures over the last few years in my career and feel that an understanding of requirements, differences and impacts of these structures is very crucial to a software consultancy. Most importantly, not implementing end-to-end processes and/or controls that support a chosen organisational structure can lead to disastrous effects. I believe every Enterprise and Solution Architect should understand this relationship.

First, a brief definition of bureaucracy and adhocracy. A bureaucracy is a strict hierarchical system designed to deal with work in a strict and rigid manner. A bureaucracy is designed based on a known body of knowledge and is characterised by its permanence and stability. Way back in 1968, Warren G. Bennis, a U.S. leadership theorist forecasted that the company of the future would rely on nimble and flexible project teams within a structure he called an “adhocracy”. This concept was widely publicised in a 1970 book titled “Future Shock” by Alvin Toffler. The book predicted that organisations would need flatter structures, faster information flows and disposable project teams in order to survive. Henry Mintzberg, then expanded the delineation concept between bureaucratic and adhocratic organisational structures in 1979 by describing the 2 X 2 matrix below,

	Simple	Complex
Stable	Machine Bureaucracy Standardized work processes and outputs	Professional Bureaucracy Standardized skills and norms
Dynamic	Entrepreneurial Startup Direct supervision	Adhocracy Mutual adjustment

I’ve worked in a machine bureaucracy during the early years of my career for a fibre optic company. The company was rich in technostructure (heaps of managers, scientists and planners). Communication was very formal and we; the technical staff, had several rules to follow without an understanding of their implications. We were not privy to any of the decision-making; only learning of the new decisions after the sign-off and/or implementation stage. As innovation was restricted only to a very few people in the company, the company had to eventually shut down because it did not keep pace with changing industry trends and the demand for new innovative products in the fibre optic space.

While later working for a large multi-national professional bureaucracy, I noticed that innovation was restricted in its entirety. The sole purpose of the I.T. team was to support business requirements. If there was a requirement, then personnel needed to put in personal time to scope a solution that used the latest breed of technology. During an I.T. recession, the business chose to limit adding new features to their applications. This meant that the I.T. team had to transparently use Change Requests to even get an opportunity at learning something new. The implementation of these Change Requests was a hushed affair and staff eventually lost patience. I believe that this was a classical example of a professional bureaucracy, operating exclusively without an innovation strategy that lead to debilitation of staff skill sets. I.T. staff began to leave in droves and eventually all work was outsourced.

I’ve also worked for an organisation with a hybrid organisational structure. The organisation at the higher levels was a typical professional bureaucracy but at the departmental-level it was essentially an adhocracy. Because the professional bureaucracy component of the organisation had several established processes and controls that often conflicted with the departmental-level adhocracy (who had not yet established strict processes and controls because they represented a diversified component of the larger business), staff at the departmental level lacked the necessary tools and organisational impetus to carry out even the most basic duties of their role. Key departmental staff who possessed the ability to lay down processes and controls were not empowered to make the changes required. To make the situation worse, these key personnel were not trained in the latest skills required by the market, so apart from the processes and controls that did not work, they now had to struggle on a day-to-day basis to fill the gaps in their skill sets. The entire structure lacked organisational commitment and therefore knowledge and intellectual property gained during each project by the virtual teams were not assimilated for easy reuse. Staff were continuously working overtime to the fill in the gaps the supporting structure was failing to provide and this resulted in absolutely no time for innovation. This situation was a result of a clash between the professional bureaucracy and adhocracy.

In summary, the dynamic nature of the software development and services industry requires an adhocratic approach. Enterprise architects need to be extremely wary when designing processes that support adhocracies. Innovation should not be ruled out as the fifth element in an organisation’s balanced scorecard that also includes financial, customer, business process and staff L&D perspectives.