They might not tell you, but your business peers think your department is too slow.

Here's how to change that.

The IT department has always suffered the reputation of being too slow. For years, users complained that IT just wasn't fast enough. It's why, they said with shrilly self-righteousness, they were forced to go around it, giving birth to the phenomenon we know as shadow IT. "

But none of this is new.

Here's what is: An even greater need for speed and agility from the business. If CIOs thought their departments were already being pushed too hard to roll out IT projects quickly, they're not going to like what the future has in store.

An economy stuck in the fetal position is making businesses more desperate than ever to action almost any new opportunity that could prop up their drooping top lines. That means they're having more meetings, outside of their regular planning cycles, that are churning out more ideas on how to make money--most of which need IT support.

The numbers back up that observation. According to CIO research, the number of Indian CIOs who say that "deploying too many technologies or applications is a major challenge to their department" rose from 71 percent in 2011 to 79 percent in 2012. Our research also points out that since the slowdown, the number of IT projects that medium to large companies are undertaking in a year has tripled.

This trend, coupled with a lingering reluctance among consumers to spend, is effectively shrinking the pie companies are fighting over. Although consumer confidence is on the rise, Nielsen's Consumer Confidence survey (November 2012) points out that 54 percent of Indian consumers still say they'd rather put spare cash into savings than spend it. As a result businesses are decreeing that new products, services, and solutions need to be pushed out faster to ensure they get the largest piece of a smaller pie. Add then to this mix swiftly changing customer demands.

Put together, these trends have increased the number of new, quick ramp-up projects within enterprises, heightening the need to hustle and be more agile. "It's speed that gets a company to realize the benefits from a technology initiative," says Ashish Agarwal, SVP-IT at Apollo Munich Health Insurance. "Tech projects can be accelerated and it would certainly expedite business benefits."

CIOs who aren't taking this need for speed seriously should remember that there's plenty, including their reputations, at stake. A recent Forrester study asked business leaders how long they thought it would take IT to build and deploy an innovative new idea that required software development as a key component. Only 8 percent believed IT could deliver within three months. It gets worse: More than four in 10 business leaders thought it would take a year or more.

You get the idea: IT was considered slow before the financial crisis and it risks being considered even slower today.

The question is: How fast is fast? A year? Six months? How long does IT now have before it's considered a 'dawdler' by the business? Key to answering that question perhaps lies in looking at the horizon Indian businesses operate within. In the last 18 months that's shrunk. According to CIO research, a growing number of Indian companies say their business' horizons have contracted to less than six months. That means more business leaders are now making plans for the next six months--as opposed to the traditional year-long cycle. It also means that an idea only has six months to go from concept to completion--and start paying for itself. Based on that, CIOs we spoke to now say that one quarter or less is about how much time IT has to deliver business projects.

The experts agree. "Companies shouldn't take one year to deliver a project only to find out that that's not what their customers wanted. Instead, they should break a large IT project into smaller prototypes and deliver it at shorter intervals, preferably, in a calendar quarter or less," says Andy Kaufman, a project management professional and the president of the Institute for Leadership Excellence and Development based in Chicago. Kaufman helps companies improve their ability to deliver projects and lead teams.

That's easier said than done. How do you take a large project that affects multiple stakeholders and legacy systems and turn it around in 90 days or less? And then do it on a regular basis? CIOs who want to achieve that type of continuous delivery need to attack the challenges that have traditionally got in their way. You know them well: A lack of business-IT collaboration, slow software development practices, and an inability to prove ROI, which impacts IT's credibility.

Ready to get on the fast track? Here's how to get started.

IMPERATIVE: Hold Business Close

For CIOs who want to introduce a culture of speed to their organizations, there are a couple of things they must do. These include breaking down large projects into smaller, but more in-demand, products and services that can be churned out more frequently.

They also need to find ways to cut the number of concurrent projects IT handles--thereby sharpening its focus. And finally, they should ensure that the products they create satisfy both customers and the business. All of this will allow business and IT to push out prototypes faster and more frequently, thereby creating more opportunities to meet customer demands, and transforming themselves into a more agile unit.

None of that can be accomplished effectively without the co-operation, nay, the full involvement of the business.

Without this collaboration, it's almost impossible for CIOs to convince their management to make the necessary changes for a new way of working to take off. Nor will CIOs be able to successfully defang middle management, where most of the resistance against a new approach will come from.

Building deeper business and IT collaboration means understanding what each other's priorities are, standing by the other during testing times, driving one another, and jointly asking management to change some of its practices. This is probably what CIOs will spend most of their time doing because no one else can do it for them.

Step one in that direction is realizing that traditional methods of business-IT collaboration don't make sense any more. "The model in which business says 'here's what we need' and the IT team develops and implements it, is not effective. The right model is having a combined team led by the business that includes IT folks. We should stop calling anything an IT project. Business projects with a heavy dose of IT in it will drive the agenda," says Nadim Matta, senior partner, Schaffer Consulting; and president of the Rapid Results Institute.

The way Matta sees it, business and IT leaders should collaborate to bring together a team of business and IT execs, set them a challenge, and then get out of the way. The team then has 100 days to find a solution. It's an approach he has used successfully with Fortune 500 companies, whose very size builds silos.

This can be tough for CXOs because it runs against the grain of most leaders who are taught to be 'in charge' or lead from the front. And that's why, Matta says, it's important for CIOs who want to try a new, faster approach to get "air cover from at least one business leader," who sees the benefits of letting teams take over.

"If you have that," he says, "you reduce your risk. It also increases the odds that the investments a company is making in IT are going to deliver higher returns."

Vivek Khanna, VP of finance and information systems at Havells, tries to ensure that every project is driven by a business-led IT team. "CIOs must treat every project like a business project," he says.

That belief is what, he says, enabled his team to pull off two ERP projects back-to-back in a six month period--in Thailand and China. The ERPs, says Khanna, were meant for a company that the Rs 7,500-crore Havells acquired. While the ERPs used some templates, the implementation required a number of customizations, which as any CIO knows bogs down projects.

There were other hurdles as well. "Communication was a challenge. During training workshops, when the Indian team visited China, training sessions needed an interpreter and sometimes written communication. The entire change management process started from understanding their existing business processes, performing knowledge transfers via physical training sessions, conference calls and video  conferencing," he remembers.

Despite these obstacles, each ERP was functional within 90 days, a far cry from when large projects like these took over a year. "Our thought process is: If a project's duration exceeds a certain period, you start losing focus," says Khanna.

Key to his success is a team of 18 he put in place. "My internal team has core business skills. They helped me roll out projects very quickly. They understand business well and have over 10 years of experience," he says.

That understanding of business is critical to project success, says i-Lead's Kaufman, who also believes in business-IT teams. "Project management comes down to managing business expectations." But to manage them well CIOs need to regularly interact with the business. "All the involved stakeholders must feel a sense of ownership in the project. It helps accelerate delivery," he says.

At Anand Rathi Financial Services, IT and business work hand-in-hand, says Mukesh Mehta, VP and head-IT. It has been five years since the in-house IT team built Web-based CRMs for each of the firm's eight business units, including insurance, retail, HNI broking, mutual funds, and commodities. In early 2012, Anand Rathi's business team decided to take the next step: Give the managers of different units the ability to better monitor potential leads.

To do that, Mehta's team would need to complete three smaller projects. First, they needed to create a mechanism that enabled potential clients visiting Anand Rathi's website to leave behind key information. That data was then re-directed to an appropriate business' CRM. Each CRM then had to automatically produce daily reports with the number of potential clients and those that had been followed up on. Finally, each CRM was linked to each unit's HR portal. With three projects running across eight business units, Mehta was juggling 24 projects.

"It took us only two-and-a-half months to complete the customizations on all the CRMs, but we couldn't have done it without regular meetings with respective business teams," says Mehta.

IMPERATIVE: Minimize Scope

When Ola Cabs launched in 2010, it wanted to ensure, like most other businesses, that it could offer all the facilities a modern customer expected of a cab service. To CEO and CIO Bhavish Aggarwal that included a website, a contact center, and a mobile app, all of which should have been ready on day one.

Aggarwal is not alone. In a world that rewards one-stop shops, companies that offer end-to-end services, and greater customer choice, not having multiple offerings is seen a sign of weakness, or worse, of amateurishness. It's why customers, for instance, prefer the supermarket to the local kirana.

It's also why businesses tend to create software that can do everything at once.

Jez Humble, author of Continuous Delivery and principal consultant at Thoughtworks, a software company that focuses on software design and delivery, believes there is an inherent flaw in this type of thinking. He says businesses are trying to predict what customers or users want--instead of asking them. "When IT thinks of all their wonderful IT projects, they think of all the ways in which they can make each of them as perfect as possible. The reality is no one cares. It's sad but true. People want to solve their own problems. It's not about the fabulous products you can build, it's about how you can solve a customer's problems," he says.

He has a point: Customer predictions are extremely hard and can often be counter-intuitive. Neither are detailed requirement documents the answer, because if they were, IT projects wouldn't suffer from scope creep.

Desisting from guessing what gets people is a lesson President Obama's campaigners learnt. When the team was tasked to send out e-mails asking for donations, the big question was: What do we put in the subject line? They experimented with hundreds of subject lines  but, to their surprise, the one that really worked was: 'Hey'. In an interview with Bloomberg Businessweek, Amelia Showalter, director of digital analytics, said: "We were so bad at predicting what would win that it only reinforced the need to keep testing."

"That's totally counter-intuitive," says Humble talking about the campaign. "While sending out these e-mails, the team would never have been able to guess what people would respond to. The truth is, guesswork in IT is lethal. Imagining what the business needs or the customer wants is a collective waste of time and effort--especially in waterfall models where you deliver the product to the customer or business only at the end of project completion."

The smarter thing to do is to put a prototype out there quickly for customers and let them tell you where to go--what Showalter called testing. To do that, companies need to break down large projects into bite-sized pieces and prioritize them. It's what Humble did when he built a commercial release management system for a Fortune 500 company.

"We built it in such a way that the very first feature was a simple status page showing that the application was live," he says. "The whole idea of continuous delivery, which is a subset of the agile methodology, is to say that software is production ready from day one."

But how do you define what the smallest unit is? For instance, could Mehta from Anand Rathi have attempted just one of the three projects, instead of all three? The answer, says Humble, is to focus on the customer. "If you know the smallest amount of work that you need to do to solve a customer's problem, then, you can solve a customer's problems in less than 90 days."

That's exactly what Agarwal did at Apollo Munich Health Insurance. In October 2011, Apollo Munich's operations team conducted a study to figure out how it could cut the amount of time it took to issue an insurance policy. The team, says Agarwal, looked at the six legs of the policy issuance process and asked the IT team to find a way to speed up multiple areas.

Agarwal knew that the business wanted the changes to be ready for the January-March cycle, when the insurance industry sees a surge in business, and Apollo Munich gets 45 percent of its business. He also knew that they were better off focusing their energies on compressing one key leg of the issuance process:  Technical underwriting. Throwing all their energies into that one area, in his estimate, would allow the company to better scale up and meet the needs of the market.

The business heard him and Agarwal delivered. In just 75 days, Agarwal says, "we scaled up our capacity to handle much higher volumes. I recommend agile practices because you can quickly and dynamically align to changes in market conditions. With large projects, which run over years, you risk a lot of factors changing like business processes and customer expectations. Agile processes help you align to market forces."

 In Ola Cabs' case, it could have waited until it had gotten its Web presence, call center and mobile app going before it launched. But it didn't. The company, which operates in Mumbai, Delhi, Bangalore and Pune, started operations without its mobile app. Five months after its website and contact center were up, Ola Cabs put out its mobile app. In the meanwhile it had figured out what customers really wanted and then created a unique app, one that none of its competitors can still match.

 Aggarwal, however, ensured that the app didn't try to do everything and hence it could be put out in just under a month. "Users are okay with an innovative product which delivers one thing very well in the beginning and then gradually becomes much more feature-complete," he says.

That's an approach, Agarwal from Apollo Munich agrees to. "Target workable solutions instead of perfect solutions or risk losing your window of opportunity. Think agile and think what can be built in a 90-day timeframe," he says.

Another benefit of breaking up projects into smaller pieces and working on them one at a time, is that CIOs can build more agility. How? By putting out prototypes and asking for feedback, both business and IT get a better sense of what customers or users really want. This could result in deleting some requirements from blueprints--saving business-IT teams time. It could also lead to new realizations of what customers really want--which can then be fast-tracked.

That's what happened at Ola Cabs. By the time the company had put out its mobile app, it had already started work on a second feature for the app. Initially, the app was only meant to schedule immediate pick-ups. In the second version, Aggarwal planned for a feature that allowed users to book pick-ups in advance.

In the meanwhile, Ola Cabs had sought feedback and learnt that what customers really wanted was a way to pay via mobile. Although that wasn't a feature that was on Aggarwal's immediate plans, he ensured that he included it in the app's second release--which took 75 days.

For CIOs who want some of that agility and speed, Humble says there are some factors to watch out for. Organizational mindsets, he says can come in the way of speed. Companies, for example, still plan budgets once a year, which isn't conducive to the fast changes they want to introduce at frequent intervals. "Organizations are setup in the wrong way," says Humble. "We have budgets once a year and create big projects at the time. When you plan for a year-long project, from that point on, you have framed the problem in a one year timeframe."


Like with anything new, asking people to adopt this quick and agile approach will meet with resistance. One way to win them over is showing them proof that it works, in terms they understand: ROI

Too often though, says Humble, ROI isn't a key criteria when starting off on a project. "Most companies have a small number of projects that they are expected to build, but they don't necessarily produce good ROI," he says, adding that if a project's ROI is lower than 4 percent, CIOs are better off putting their money into a trust.

Whether or not that was part of this plan, the technical underwriting project Agarwal ran at Apollo Munich, got plenty of business bang. The decision to focus on one key aspect of the policy issuance process ensured that Apollo Munich was able to make the most of its busiest season. The project, says Agarwal, ensured that 97 percent of policies can now be issued in three days--compared to 83 percent in three days before the project.

Not every project will give you easy-to-demonstrate metrics. But CIOs can look for other measures that their businesses track. Since its launch, customers have booked over 4,000 Ola cabs a day, on average--across three channels (its contact center, website, and mobile app). "But the mobile app is the fastest growing channel, increasing at the rate of 30-40 percent a month," says Aggarwal. "Customers simply love the application and its repeat use is higher than any other channel."

In the meanwhile at Anand Rathi, Mehta says that automating certain CRM processes ensured that each business unit no longer needs to manually create daily sales reports. The system now is programmed to generate automatic sales reports at the end of each day. "This has slashed the turnaround time for report generation from 24 hours to approximately two hours," says Mehta. "This translates into a direct business benefit because every vertical can now ensure whether daily sales targets are being met or not."

Who ever said slow and steady beat fast and furious?  

Shubhra Rishi is principal correspondent. Send feedback on this feature to [email protected]