NakedIT: JP Rangaswami says, 'Don't call them IT projects'

The Naked IT interview series talks with innovators about the evolving relationship between IT and business. Please listen to the audio podcast and enjoy the brief excerpts below.

JP Rangaswami is Managing Director of Service Design at  BT Design, which has total responsibility for designing, building and implementing the IT and business processes, systems, networks (non-Openreach) and technologies for BT, the huge British telecom. A Fellow of both the Royal Society of the Arts and the British Computer Society, JP's career has spanned thirty years. Dan Farber, ZDNet's editor in chief, has called him "one of the smartest people in IT." He's a prolific blogger and is active on various social networks, including Twitter, where we met.

In this interview, JP describes the challenges and opportunities associated with transforming BT from a traditional telco into a modern, customer service-oriented organization. The podcast offers a fascinating glimpse inside the mind of an innovative and experienced CIO, so please listen, learn, and enjoy.

On transforming BT into a customer-centric organization:

The first transformation was understanding we were not going to be able to survive in the traditional telco model....[W]e understood that the only way to deliver transformation to the customer was to focus on metrics that were only about the customer and nothing else....[N]obody associates telco with the phrase "customer service."

Then came the challenge of breaking 100 years of history and bringing these departments together....[T]he building we were in used to house Marconi in 1905.

[I]n order to change our world, we had to change ourselves. [T]his kind of large-scale change has never been tried by any other comparable firm....Management recognized [there were entrenched systems] and was prepared to act. [T]he competition [was] watching us, because they knew we would be different if we could manage to pull it off.

We realized the silos, the tribalism, and the warring were actually systematic, because they reflected historical structures and realities. Changing [all this], and the way it was embedded in our culture, is not trivial.

We took the people in IT, networks, products, and processes, put them into one big pool, and threw away all our titles. The intention was to also throw away our old prejudices....so that when somebody called BT, they no longer had a buck to pass because there was no one to pass it to.

On BT as a business services provider:

[H]alf our revenues, nearly $20 billion, comes from services. We're one of the world's largest services companies, but it's almost a secret....We are in the business of doing the things the customer needs done, but doesn't want to do.

On the IT / business divide:

[Projects] will fail unless all dimensions of the project -- the human elements, the commercial elements, the business elements, the architectural elements -- are resolved. Crudely, one could say, IT projects fail initially on nomenclature because they're called IT projects. To me, it's as ludicrous as saying male childbirth. A project exists in order to create some transformation, some business outcome, and if there isn’t a business component to the project it should be strangled at birth.

The idea that you could take a critical function within an enterprise and state that it is "not business" is insane....[E]verybody and everything should be about creating new business value on behalf of the customer.

[W]e have conned ourselves into believing there are separations to justify organization charts where people build empires, when actually you [should] have a bunch of people taking accountability for different facets of the business.

[W]e have to get to the idea that we're all in this together, because we are in business together, and we are in the business of delivering value to our customers.

On IT project failures:

First and foremost, we have to manage better communication....Project failure and success seem to depend on saying, "Are you able to accurately articulate and collect what the requirements are?" and "Are you able to express the right estimates?".... Too many times, the collection process is weak, because the customer is not easily able to articulate [his needs] in language the people [on the project] understand. [S]oftware estimation is not a trivial exercise; it is still an art rather than a science.

[F]ailure is usually a characteristic of unwillingness to recognize change and to cover up....It's like a salesman putting forth a forecast to management...without ever talking to the customer. Management [is] blissfully unaware of the fact that the information is false.