Acquiring Lombardi's Priorities

  • September 11, 2013
  • Scott

Horace Dediu wrote this for the Asymco blog, about Microsoft’s acquisition of Nokia:

When a prosperous company buys a struggling company you have to wonder what they’re really buying.

Here’s how to think about it. A company is defined as the sum of three values: resources, processes and priorities (RPP). Everything of value can be classified into these three categories.

When one company buys another it’s the equivalent of one set of RPPs trying to engulf or swallow another set of RPPs. The simplest (naïve) interpretation is that an acquisition is the purchase of Resources in terms of customers, sales, profits, etc. It might be of assets like employees, intellectual properties, brand etc. I say this is naïve because Resources are the easiest to value because they can be measured and valuing only what can be measured while ignoring what can’t be measured is deeply mis-pricing.

This is a really interesting analysis that ensues in his post.  I highly recommend reading it in its entirety, because through the lens of this merger you will see some insights into other mergers.  As a result, I couldn’t help but think about the IBM purchase of Lombardi in 2010.

Clearly IBM was buying Lombardi partly for the Resources- the measurable numbers of revenue, employees, etc that came along with Lombardi.  But with regard to Processes and Priorities, let’s take a deeper look.

Dediu points out the value of processes is sharply discounted by the market, which doesn’t perceive their value:

When buying a set of Processes, a buyer may see a bargain because their costs for building a similar process could be enormous, even infinite. In the case of Nokia, the process of building hardware may be infinitely valuable to Microsoft as they have had dreadful luck doing it themselves. But they’re seen as value free to the market because it seems that there are many others who are building hardware.

I don’t believe IBM thought it needed Lombardi’s processes, nor valued them much.  IBM has its own software development processes, its own services processes.  For a time, IBM gave the Lombardi folks the opportunity to run professional services more like Lombardi ran services.  And there was some evidence of success with the approach, but it has been gradually re-integrated with IBM’s larger services approach, and the march of generalizing the skills of the consulting force apparently must carry on.

However, I think IBM discovered a process that was working well within Lombardi’s team… but I have a hard time separating it from the priorities discussion so we’ll come back to it.

With regard to priorities, Asymco’s analysis seems to apply to the Lombardi acquisition:

Priorities are the answers to the “Why” question as much as Resources are the answers to the “What” and processes are to the “How.” If you were to think in terms of software engineering Priorities are the “Specifications” where the Resources are the data and Processes are the algorithms. They determine the direction and reasoning of why a company even exists. If you have bad specs, it never matters whether the algorithm is efficient and you have all the data: you are building the wrong thing.

IBM wasn’t buying Lombardi to change IBM’s priorities – but I believe it was looking to change the priorities of the BPM product group. To import the priorities of a company that was winning in the market and competing well against IBM at customer sites.

Acquiring Priorities is also fundamental in that they are usually exclusive. […]  So if you’re acquiring a set of Priorities, it’s likely that you’ll have to discard your own. It makes most sense when a company which might otherwise be prosperous needs to change direction.

This almost perfectly describes the situation IBM’s BPM offering was in.  Over the next two years, IBM’s BPM offering looked more and more like Lombardi’s BPM offering.  IBM successfully combined its product development process and human resources with Lombardi’s priorities for product design and market fit.

So, in a way, an acquisition of Priorities is almost a reverse acquisition. The acquired is actually “buying” the acquirer. The acquired company’s Priorities (and hence Processes and Resources) become the guiding principles in the acquirer. It’s what happened when Apple bought NeXT and may have happened when Disney bought Pixar.

If you look at IBM BPM today – or indeed the entire Smarter Process offering – the stamp of Lombardi DNA is all over it.  And that’s not a bad thing.  Lombardi’s priorities – simplicity, excellent design, and focus on the business – have led to a great improvement in IBM’s offering and competitive position.  Spiritually the Lombardi priorities have carries forward in BPM, even when the personnel have changed.

But there’s also a sign that IBM discovered that Lombardi had some element of process that they adopted as well – as in the design process itself.  The products continued to follow Lombardi’s approach to design (not just the output, but the process to produce that output)…  The priorities and the process were in alignment, if that makes sense.

Meanwhile, IBM has now put that together in the IBM Design Group that Lombardi alum Phil Gilbert is running.  The intent is to impact priorities across a much broader swath of IBM product development – and at a corporate level to elevate the importance of design across the board.  And the other goal is to impact processes – to create, sustain and impact product design processes that will produce great design work for many years to come.

In a very real sense, IBM might have gotten a better deal than they realized when they bought Lombardi (including getting BP3 as a partner!)…



Related Posts
  • March 7, 2019
  • Scott

From the AirlineGeeks: "For the ninth consecutive year, Austin Bergstrom International Airport has reported a...

  • February 27, 2019
  • Gordon

[Editor’s note:  this is a guest-post by Gordon Siegfriedt, a Solutions Engineer at BP3] I recently had ...

  • February 27, 2019
  • Andrew

As IBM has indicated that they plan to deprecate the Desktop Process Designer for the BAW platform many of our...