What is FIT?

Make ROI secondary to "Fit" when analyzing investment opportunities and strategic initiatives.

• Fit over ROI
• What "fit" is not?
• How "fit" fits in?
• Do Software Methodologies "fit" with Programming Languages?
• Can't be half-hearted about strategy?
• What's a million dollar baby?
• Search for an optimum "fit"
• Coordinate like a chicken with head cut-off
• BHAG better than thousands of tiny little optimizations in functional areas
• Synergy, supermodularity and fit
• Look for fit, don't cry over ROI
• A very contrived example for techies

I have yet to meet a business executive who does not intuitively understand the idea of fit as a critical component of business strategy. In and around boardrooms, one can always hear incessant discussions about "fit". We can't hold this acquisition for too long, since it does not have a good fit with the rest of our business ... It will be a good idea to buy this other business, since there is a great cultural fit ... We have decided to join hands and merge our businesses due to extensive synergies between us, which will save us over $100 million annually.

While business people have a pretty good understanding of "fit", they become quite intrigued, when asked if they could measure "fit". Some of them define "fit" as synergy that will create savings, others define it as future increases in revenue at relatively lower investments. All these answers are partially correct.

Fit over ROI
My purpose is to show that "fit" and related concepts are not entirely unmeasurable. Of course, it is hard to measure the effect of "fit" due to complex interactions among its various components. But if we can work so well with an imperfectly measurable ROI, then what stops us from using a better metric of "fit". It is no secret that ROI on strategic initiatives, investment opportunities and sundry projects is hard to measure even if we exclude the impact of executive agendas on ROI. At the same time, it is possible that a perfectly accurate measurement of "fit" is NP-hard class of problem and measurement may become too technical. But if we can circumscribe the domain of our strategic decision-making, measurement of "fit" is achievable.

What "fit" is not?
But first, let's discuss what "fit" is not. "Fit" is not economy of scale, though returns to scale is one of the sources of "fit". "Fit" is not positive feedback effect either, since "fit" can exist independently of positive feedback effects and "fit" is not improvements in bargaining position. Though, enhancement of bargaining position may be an important goal during acquisitions.

Here are two examples of what "fit" is not and what it is. Two firms that offer white label "software as a service" solution in the banking industry merge together. As a result of the merger, the combined newco can now get larger discounts from telecom, hardware and power suppliers. This saves newco about $5 million annually. As you have guessed, this is not really "fit". In a seminal article on strategy, Michael Porter has described how different activities of Southwest Airlines fit together to form a strategy. That case study is a great example of "fit" but Michael Porter did not describe any way of measuring the value of that "fit".

How "fit" fits in?
So what is "fit"? "Fit" is complementarity. Complementarity means that doing more of a subset of activities increases returns to doing more of the rest of the activities. For instance--to use a very basic and hackneyed example--there is a high degree of complementarity or "fit" between assembly lines, low product variety, highly specialized workforce and hierarchical management. Similarly, there is a high degree of fit among flexible, programmable equipment, broad product line, knowledge workers, broadly trained workforce, flat management structure and higher quality. These complementarities are so strong that you can't improve profits by having flexible programmable equipment and narrow product line or by putting knowledge workers on assembly lines. You will be wasting investment in machinery in one case and talent in the other. Michael Porter found during his research that mutually complementary activities tended to make a coherent pattern. This gives us another conclusion, which is that you cannot take a subset of a coherent pattern of mutually complementary activities and combine that with another subset of mutually complementary activities. What this means is that you can't take quarter of a "fit" from one company and then try to insert that into another "fit" to improve profits. It just won't work. Cost will go up and the "fit" will be really poor. This issue of "fit" will manifest itself in low staff morale, low productivity, conflicts, wasted resources, problems in the design of HR policies and hiring practices. Management will blame each other for problems without realizing the fundamental problems inherent in the strategy. In short, a poor "fit" can lead to a really dysfunctional organization, an organizational equivalent of American Beauty movie. This is what makes it so hard to imitate successful companies. By the way, this proves another point, which is that you can't pick and choose parts of a strategy. Strategy is indivisible. It comes in one full whole lump with its strengths and weaknesses, with its beauty and warts and if you don't like the warts, its better to give up the whole strategy. Think of Freudian psychoanalysis, which is one full highly consistent set of premises and you can't logically accept one part, without accepting the rest of the theory.

Do Software Methodologies "fit" with Programming Languages?
Let's discuss the issue of software methodologies from the point of view of "fit". Traditional Waterfall methodologies were developed for a factory type, assembly line environment with distinct stages of software development. Modern agile methodologies, such as, Scrum are based more on overlapping phases of software design, programming and deployment to the extent of having a permanent beta in production. Waterfall methodologies had a good fit with programming languages like COBOL, where you could measure productivity by KLOC (kilo lines of code), separate requirements gathering, design, programming, testing and deployment activities and hire people with high degree of specialization in one of these activities. Structured programming methodology was developed to improve quality of software using old programming languages and tools. These mutually complementary activities made a nice coherent pattern. Newer object-oriented languages, service-oriented architecture did not fit in this mold. Programming of objects required programmers to have a good understanding of design. Test-driven development required software developers to become testers. As public knowledge about these languages increased, Agile methodologies emerged to leverage productivity using overlapping product development phases and a new coherent pattern of activities emerged. This coherent pattern comprised languages, such as, Java frameworks, Jtest, broadly trained software developers, short product development cycles and faster time-to-market.

Can't be half-hearted about strategy?
From the point of view of "fit", my question is: Would it be optimal for a subset of "Waterfall" pattern of mutually complementary activities to coexist with a subset of "Agile" pattern of mutually complementary activities? The simple answer is no. Due to lack of "fit", you can't combine parts of these two coherent patterns. In fact, if you don't find my idea ludicrous, you can try using Agile methodologies with Cobol and structured programming and then drop me an e-mail about how far it went. Even at a high-level you can't optimize on business goals by using "Waterfall" in one half of the organization and "Agile" in the other half of your product development organization. Change will have to be more radical that this pussyfooting approach. This is exactly the reason that newer start-ups are more successful in adopting Agile methodologies and achieving a fit with the rest of their activities to drive competitive advantage over established firms. An example is GorillaNation.com.

What's a million dollar baby?
Interestingly, the "fit" within successful organizations extends far beyond these simple concepts. Successful organization create far-reaching coherent patterns of product design, development, marketing, human resources policies, internal communications, internal controls, financial decisions, supplier relations, distribution, etc. Such strong fit among various activities not only leads to improvements in profits but also improves competitive position of the firm. I'm sure that by now you have guessed a problem. Exploiting such extensive systems of complementarites requires substantial high-octane coordination among different functional areas of the firm. This strong fit also causes huge resistance to change. You can't just make a change at the margins and expect to enhance profitability or competitive position. At one of the large organizations, due to high-level of coordination, several projects were called million dollar babies. Even smaller projects took nine months and a million dollar to deliver. If you heard your senior executive team talking about "radical restructuring" or "nothing short of an overhaul", or "wipe the slate to start from scratch", then they were certainly not kidding. You cannot effect a long-term sustainable change in these extensive systems of complementarities, unless you wipe the slate clean and start from scratch.

Search for an optimum "fit"
Let's again take a software example. If you are using traditional "Waterfall" with Cobol and you introduce a new platform with modern languages and Agile methodology, then profitability will decline, expenses will go up and depending upon how much your actions are valued, your failure will be characterized as full or partial. Please note that my objective for optimization is purely financial. In order to maximize profits, such a change will have to be coordinated at the highest level with finance, marketing, human resources and product distribution to create a whole new extensive system of complementarities or a new "fit". Mathematicians will say that in order to improve profitability through such a change, you will have to coordinate across the whole organization due to "non-convexities" created by complementarities or "fit" among all the different activities of the firm. Mathematicians tell me that a non-convex objective function cannot be optimized in time exponential. So does that mean that non-convexity is NP-complete. I don't know but it just emphasizes the need for high-octane turbo supercharged coordination among all the activities of a firm to search for an optimum solution. Exactly the reason why managers have to be reflective practitioners. However, a search for an optimum business strategy does not have to be a wild one. In fact, it possible to show that that you can limit your search to the adjacent domains, which provide improvements over the current optimum. You will still be able to achieve at least half the gains that may be possible from an unrestricted optimization of business strategy.

Coordinate like a chicken with head cut-off
Therefore, if you put your firm ahead of you, you are going to be running around--may I say like a chicken with head cut off in a positive sense--to ensure that all the activities across the organization are strongly coordinated for such a change to become a success. In fact, this was exactly what John Nash (remember The Beautiful Mind) proved. Every coordination game involving two or more players has at least one Nash equilibrium. Once Nash equilibrium is achieved, no unilateral action by a single member can increase the team's payoff. If you recall prisoner's dilemma, you will notice that it's impossible for a single member to unilaterally improve the team's payoff. The condition of co-existence of "Waterfall" and "Agile" methodologies may be no different than prisoner's dilemma. Rational decision-making ends up reducing payoff. This is exactly why big, hairy, audacious (BHAG) goals are considered more valuable, since such goals have the ability to drive a higher level coordination across the firm. Managers know this intuitively. There are complex mathematical theorems developed by Paul Milgrom that show that without coordination at the top, you won't go too far. To get real benefits, you will have to totally redesign the way you do business.

BHAG better than thousands of tiny little optimizations in functional areas
If managers are unable to coordinate their choices and while attempting to optimize within their functional areas they believe that the choices of other managers are fixed based on the past behavior of their colleagues, then they will positively and systematically under-respond to changes. John Nash proved that under such circumstances, if team members were individually allowed to search for improvements, no further improvement will be possible for the team as a whole unless changes were coordinated among the team members. This solves another puzzle for us. Several times I've been asked whether it is better for each manager to optimize within their functional areas instead of trying to do big stuff, since big stuff is frustrating and choices are painful. The answer is no. You will invariably end up suboptimizing your business strategy unless coordination occurs across all the functional areas. There are no short cuts to achieving fit.

Synergy, supermodularity and fit
Another mathematical concept that corresponds to "fit" is the concept of supermodularity. It was Paul Milgrom, who applied this concept to Economics and Michael Porter brought it to analyze business strategy. In a very rough manner of speaking, supermodularity is similar to 2+2 = 5 or synergy effects. Purists would like to hang me for saying that. What supermodularity means in Mathematics and Economics is that the sum of changes, when all components of a system are increased together will always be more than the sum of changes, if components are increased in smaller groups. Whole is more than the sum of its parts. Does it remind you of Kurt Lewin and Berlin School of Gestalt psychologists? Well, here we have another proof that if "fit" is extensive, then nothing will improve substantially unless changes are coordinated across all the functions. Are we talking about radical change again?

Therefore, "fit" is a concept that can be defined, analyzed and measured by looking at the complementarity of activities, supermodularity, coherent patterns of activities, theory of games analysis and returns to scale. But this measurement is not going to be a cakewalk. Allow me to use some circular logic to say that "fit" is important, since most of the firms value complementarity over similarity and "fit" over economies of scale.

Look for fit, don't cry over ROI
So what does this mean from a practical point of view. All measurements of ROI (Return on Investment) will be incomplete unless you can take the effect of "fit" into consideration. Fit is real but hard-to-measure. If the "fit" is going to be improved by the project, the ROI of strategic initiatives will be underestimated. On the other hand, if the strategic initiative won't enhance the "fit" or lead to friction and conflicts, then ROI will be an overestimate. Which proves that sometimes there may be good mathematical reasons for consensus-building within organizations. I'm not saying how this consensus building should occur. Such a consensus-building could be authoritarian or collegial. It doesn't matter how it is achieved as long as it exists. Anyway, that is a digression from our topic. My recommendation is that analysis of strategic initiatives should be more in terms of "fit" than in terms of ROI. In fact, ROI should be secondary to "fit". But as we have seen above, every "fit" comes with its own trade-offs. Alas, there are no free lunches!

A very contrived example for techies
As I had propositioned earlier, software development methodology must "fit" the programming language that is being used. For example, it would be foolish to use COBOL class of programming languages under an agile methodology. While programming languages get the job done or produce the functionality, there is plenty of evidence that shows that it is the software development methodology that ensures the quality of the output. How effectively business requirements are met is a direct function of effectiveness of a software development methodology. Therefore, programming creates part of the output and methodology generates part of the value of the output and then there is a subtle interaction between the two, like, yin and yang or whatever.

Here is a matrix (not really!) based on the theory of games. Assume that the best attainable output using aggregation of all available best practices is 10. The figure shows in top left cell that the output of COBOL class of programming languages in an agile environment is 6 and enhancements to the quality of the output as a result of plan-driven methodology is 6 too. When we use COBOL class of languages with agile methodology, the output of language declines to 5 but the contribution of methodology to the output declines substantially to a level of 4 due to "misfit". This is shown in top right cell. We notice a slightly improved productivity of object-oriented (Java type) and frameworks under a plan-driven methodology with the output of language at 7 and no improvement in the value created by the methodology, which is still at 6 under bottom left cell. Under agile methodology, the value created by language as well as methodology increases. This is shown in bottom right cell. It is easy to notice that Plan-driven methodology is dominant over Agile and object-oriented languages are dominant over COBOL-types. Under mixed environment, it is clear that Plan-driven will be a preferred strategy.

Now let's check out some mixed strategies. What happens when we use a 50/50 mix of COBOL and Java programming languages in an Agile environment. We get an average output from programming languages and methodology at (6, 5.5). This is worse that using COBOL under plan-driven. This is exactly what happens in many traditional IT shops, when "savvy" management introduces new languages and new methodology to achieve higher productivity, notices a decline and finds it hard to accept it. Similarly, let's check out 50/50 mix of COBOL and Java under Plan-driven. we get (6.5, 6), which is a slight improvement.

Now let's make a slight change to the strategy payoffs. In the game that I have shown below, I have slightly reduced the payoff of object-oriented languages in a plan-driven methodology environment. Similarly, I've reduced the payoff of plan-driven methodology in an object-oriented environment. Now we have set the stage that could lead to deep suspicion between the Engineering or Enterprise Architecture department that owns the technology for programming and the Program Management Office (PMO) that owns the methodology. Let's refer to the picture on our left for a review of strategies and "fit" from the point of view of cooperation between functional areas. The firm is using COBOL-type procedural languages for developing its product using plan-driven methodology. Analysis shows that productivity+quality will be raised by about 17% by moving to object-oriented framework technologies for product development using agile methodology. If the Engineering Department and the PMO are able to coordinate switching to a new programming technology and a new methodology, we won't have any problem. However, if PMO is worried that due to shortage of funding the Engineering Department won't be able to keep its words to switch to a new programming technology, then they will pay lip service to moving to a new methodology but won't take any action. The PMO will be afraid that the output of methodology will drop to a meager level 4, if the Engineering Department does not switch to a new programming technology. Similarly, the Engineering Department may be suspicious that due to lack of skills, the PMO will not be able to switch to a new agile methodology. The result of this suspicion will be that the Engineering Department will be highly reluctant to move to a new programming technology due to their fear of reducing their productivity. Now we have this paradoxical situation, where good intentions of functional departments to not allow their productivity to decline under any circumstance will hold them off from improving the firm's payoff. Does it sound like prisoner's dilemma?

As I mentioned earlier, this is a contrived and hypothetical example. But it does present a framework for analysis of "fit". Now you can change the values and run some tests to validate or invalidate your hypotheses. Drop me a comment if you like it. Have fun!!