In business circles Toyota is talked of with awe. Not for its cars or well-heeled Formula One team, but because it is a manufacturer that has a policy that has lifted it from Japanese almost ran, to serious rival to Ford in Henry Ford’s home, the USA.

About Standard & Poor’s

Standard & Poor’s is a provider of financial market information, including credit ratings, indices, investment research, risk evaluation and core data, which is used by financial managers making key investment decisions. It is believed to be the world’s largest provider of independent equity research and mutual fund analysis information. According to S&P, over a trillion dollars of investment assets are tied to its indexes of information.

The list of organisations that have tried to ape the Toyota ‘lean production’ method includes rivals GM and Ford, aerospace giants Boeing and even the NHS. Jora Gill is one of many business people to admire Toyota, but he can also claim to have achieved a similar success story.

Lean manufacturing allows Toyota, or any organisation using it, to develop products quickly, reduce the time it takes to produce an end result and have zero to low levels of waste. Toyota can develop a new model of car in just 18 months and in 2006 it took just 29 hours to build a Toyota from scratch. General Motors took 33 hours at best. A decade ago GM and Ford were taking 50% longer to build their vehicles than Toyota and the final product was famous for its unreliability, while Toyota are famous for the opposite.

Since joining Standard & Poor’s (S&P) as VP for international business systems in 2006, Gill has taken his inspiration from the company and introduced Agile, a waterfall development and project management system that is gaining popularity.

Gill uses Toyota as an example of why waterfall is well worth adopting. “It’s better value. Toyota’s business has taken off because it’s delivering faster, and better quality.

“Describing how it overtook the stalwarts he adds, “It’s not taken off because they’re cost cutting, which is where Ford are, or GM.” Like the car manufacturer, he believes it is all about re-appraising how the organisation views its return on investment, and in doing so it will realise that it is seeing a return more rapidly, which means revenue is coming in more quickly.

Although a mass manufacturer, what Gill respects about Toyota is that it has ditched the traditional way of mass manufacturing and instead “produces our cars as our customer wants, and they can have what they want when they need it”.

This approach is ideal for a CIO at a major financial institute he claims, because it eradicates the traditional scenario of clients and users demanding every little piece of functionality they can think of, which then has to be incorporated into a massive development and roll-out. “People say ‘we need this, this and this’, without anybody saying ‘why?’ Users believe and have experienced four-year development cycles, so they demand everything up front, because they know there will be no further development after initial roll-out. He believes 64% of what they require is never going to be used, only 20% is often used. “How many people use every component of Excel?” he asks as an example.

Gill describes a development pattern that every CIO, sitting in the lounge on a Sunday afternoon can relate to. He describes the kids asking for a swing, in much the same way as a department requires some new IT functionality. You tell the kids that they could wait six months and a complex swing will be developed for them. Or you can tell them that you’ll tie a piece of rope to the tree and they can play on a swing immediately.

"’Great let’s start it’ – and you’ve realised value because all of a sudden the kids are happy,” he says. “Next, the kids say ‘well its not very comfortable, it would be nice to have a seat’. OK, but you ask if they need a fancy seat or even if they need the seat,” and his metaphorical seat is delivered, presumably on budget. “Next the kids want more fun, because the seat is not really fun, ‘why don’t you put a tyre at the end of the rope’. Excellent, now we really understand you want a tyre.”

Staying on a domestic tangent, Gill points to darling of the retail industry Tesco as an organisation which took lean practices into yet another field and has prospered as a result. “Tesco were the fourth or fifth player only about 15 years ago. Now it is number one by a mile.” It centralised its processes and the rise of Tesco has been well documented.

Coming back to IT, Gill says, “We’ve had extra features that would never get used. To produce those extra features, somebody had to do requirements analysis of these features that were never going to get used. Waste.” He adds, “We would over-engineer, we’d do complex code for features that would never get used. We would find a lot of defects right at the end, because when you’ve got a project and you’ve got a delivery date, towards the end which bit can you squeeze? It is your testing.” He describes scenarios of applications having three months of development and only two weeks of testing and therefore defects go into production, “and that is the costly part”.

The ultimate beneficiary is the user, according to Gill. “What this is saying is that you don’t have to put everything up front, because how could you possibly know what you want on day one?” This allows users to change their minds, something they do anyway. As long as changing needs doesn’t add costs, Gill is fine with it. “The principles of lean are to eliminate waste, add value and increase feedback.”

For an organisation the size of Standard & Poor’s, it means that if the market and its business needs change, Gill’s team can react with the business. He tells business units, “you don’t have to decide today or commit, but we do deliver it fast, we deliver it small and in sprint durations,” he says. As a result, he is able to ask the business what would change its business on that day and deliver value, and that is delivered first.

He then adds medium-term requirements. Traditionally the corporation will begin to see a return after six months or a year. But by delivering in short bursts with the highest priority needs at the forefront of delivery the realisation of value is much sooner.

With continual development following, akin to the water in a waterfall, the business will see another return, followed by another and so it goes on. Examples of successful users of this methodology include Google and Apple. “The number of products Google comes out with amazes everyone, it is constantly innovating.” As a result Google is yet to be leapfrogged by its search rivals and the users are “hooked” he says, constantly looking for the next release.

Coming back to S&P, Gill says when major projects are delivered at the end of a six-month development cycle the testing suffers and corners are cut. Often the testing doesn’t focus on the areas of the product that would deliver the most value. “It is not realising anything. Continuous integration means continual. We are integrating every two to four weeks. It’s almost like a mini-project that is continually ready for production.”

The same behaviour works for software documentation. Gill admits that most is three years out of date because it’s written when the application is completed, but as the application is updated, no one updates the documentation. At S&P he tells his team to produce documentation, “but just enough”, so that it can react to change.

S&P also benefits from an IT division that is as tightly integrated as its software. “We work as a team and we are constantly improving what we’re doing.” The end result for Gill is something that is still elusive for many organisations, but not at S&P. “Technology has had to learn the business to be able to collaborate. So we’ve had to learn about the business that we are in and we’ve spent a lot of time really understanding the business and the value for the business.”

Gill makes it all sound so easy, and asked how he broaches the subject with the board he responds, “They’re looking at the financial figures, and they’re looking at the investment return, but there’s not a huge deal of investment, other than time on training and deliberating how we deliver. They get the code quicker. It is a no-brainer really.”

He admits waterfall methods only work if the board has bought into the idea. “If you don’t have a really close relationship with business you are going to struggle.” To get that business buy-in, Gill hosts planning meetings where it is made clear that IT is a partner and “not simply a cost centre”. Gill’s team are enjoying the change as well.

“IT doesn’t feel like these techie guys sitting in the middle,” he says because the business people are now engaged with them. A team building exercise Gill has introduced is stand-ups. “Every morning we stand up with our IT team, and we ask three questions. The leader of that stand-up group will tell everyone what they did yesterday, what they will achieve today and what impediments they have. It takes 10 minutes, business users are invited and Gill is a strong believer in the constant stream of communication it creates.

Listening to Gill you’d think he was a long-term follower of waterfall. “It was introduced in a previous organisation I worked at and I was really anti it, if I’m honest.” Being a traditional development person he was concerned that planning and milestones were going to suffer.” Despite his talk of board level buy-in, Gill found a lot of the adoption was from the bottom up. “What I would advise is to take a small project and team and just go and try it.”

Janice McGinn, former editor of CIO, is now The 451 Group’s research director: CIO practice