Thinking Lean to Achieve Nearshore Success (Part 2)

In the first part of this post, I briefly explained the concept of Lean thinking as it relates to Nearshore application development. Due to economic pressures and other …

In the first part of this post, I briefly explained the concept of Lean thinking as it relates to Nearshore application development. Due to economic pressures and other factors, many companies have begun seeking Nearshore partners who have adopted the Lean approach in order to improve the cost, quality, speed, and agility of projects. In this installment, we’ll look at what the Lean concept actually means as it relates to the client, and the ways in which these principles manifest in real-world project scenarios.

But what does “Lean” actually mean?

Although the word “lean” may initially be confused with frugality, we must be attentive to its depth. Remember that the purpose of Lean application development is to improve cost, and also quality, speed, and agility – and it’s no accident that agility and speed are grouped together. Agility does not necessarily mean doing things quickly. It means doing the right things, at the right speed, with the right returns. In this sense, if a provider does the wrong thing very quickly, it does not make them agile. If a company does something very inexpensively, very quickly, and with very high quality, then it sounds better, but if it was the wrong thing to do to begin with, then that doesn’t achieve the promise of Lean either.

This brings us to one of the guiding principles of Lean: understand how value is perceived by the client, and do nothing but what adds value.

As simple as it may sound, this principle is significantly more difficult to implement than it seems. Over decades, the software industry has been built using the paradigm of mass production: software factories with extreme specialization (architects, designers, developers, testers, etc.) allowing progressively less skilled (and cheaper) workers to do the job according to detailed standardized processes – ultimately producing extensive documentation to allow hand-offs between teams. All this has pushed workers further away from the client, making it much more difficult to understand what and where the value is. Nevertheless, try to change this structure and you will hear cries from the rafters – This is the way it’s always been, and it’s worked so far.

The truth is that while this model has worked, it has also created significant waste in the value stream, from the customer request to the delivery of software. This is what the Lean philosophy aims to eliminate. That’s not to say that this is easy – if it were easy to see where the waste is, no one would do it in the first place. Eliminating waste requires critical thinking: It requires questioning the “way we do things.” And beyond that, it requires asking the question: Are we doing the right thing?

Sign up for our Nearshore Americas newsletter:

If CIOs are to answer that question, they should not be limited to receiving requests from business users. They should proactively ask themselves and the business how this adds value to the company; moreover, what will add the most value to the business? By doing this, CIOs gain a more prominent role in strategy setting and obtain the respect and commitment of non-IT colleagues. By employing short but in-depth engagements where IT and business co-workers think through the business model, strategy, and value chain, the right system, process, or organization redesigns can be determined.

The business outcomes can be foreseen and the IT project goals, instead of delivering a set of requirements on time and on budget, evolve into delivering the right business outcome. It is a shift from “doing what was specified” to “doing what will make us all more successful.”

 

 

Tags