Common Bottlenecks

There are typically two areas where organizations incur significant project delays. The first, says Edward Weller, a CMMI high maturity lead appraiser and software project management consultant from Arizona, is project start-up, where it sometimes takes too long to agree on requirements and release content. Speeding up time to market in this area means encouraging team development and resolution of requirements - there are no rewards for leaving requirements ambiguous in the hopes that leaving clarification until later will let you slip the latest new feature in. It also demands change control so the real impact of late change is understood, and recognition that demanding twice the functionality in half the time never works

The other major cause of delays happens when numerous defects are allowed to remain in the product as it goes into test from development. The most effective method of improving a project's time to market here is inspections, Weller says. "I've seen 'system' test cycles cut to 25 percent of pre-inspection values," he says.

"Most companies spend 50 to 75 per cent of their budget on rework: post ship defect repair and test rework costs. Unfortunately, we pay a lot more attention to manufacturing scrap than intellectual effort that is scrapped."

"Proper planning for testing, and set-up of packaged tests can do a lot for speeding up the testing phases," Weller says. "When tests are planned, more emphasis is placed on developing the right code the first time.

Marc Lachance, a specialist in eliminating barriers to effective ROI and IT president at M E Lachance & Associates, says the IT operations group, which provides all the facilities to the developers, is another source of delays. This group's typical focus is day-to-day operations, with new initiatives an afterthought. The technical support resources, infrastructure readiness and test facilities are often sources of major delays. Making the IT operations group more client-focused, and including development as a client, can make a big difference, he says.

And he agrees with Weller that proper planning for testing, and the setting up of packaged tests, can help put product development into hyper drive.

And then there is implementation. "I have often seen development initiatives that plan for implementation at the end. If implementation is well planned, it may change some of the requirements, which will help to speed up implementation," Lachance says.

Many legacy systems have long change cycles that increase the time to market. What a CIO can do is to try and take IT changes out of the critical path for business changes requiring agility.

CIO-at-large Hemant Kogekar says in one organization he worked for product codes and characteristics were hard coded in the programs, so change cycles ran over about nine months. "We convinced the business to invest three to four months of effort to remove the hard codes and create a flexible model for products. This cut down the cycle time from nine months to less than three months," Kogekar says.

Then there was the insurance company where pricing changes used to take several months of testing and rule changes inside legacy systems. Developing a pricing engine with easy to modify rules and connecting that with the legacy systems eliminated the need for most systems changes in the pricing, cutting the time to days or hours. All the business had to do was ensure that the rule changes were well considered.

"I have more examples where good use of tools created flexibility at critical bottlenecks which dramatically improved time to market. Of course good design and architecture are important. But that does not always mean re-engineering the whole system or business process," Kogekar says.

Meanwhile NineMSN COO Nick Spooner says it's natural for a CIO to be eager to deliver a full solution that may take longer than the business wants to accept, but a good CIO knows when to compromise. Spooner says time to market has been a key differentiator at both NineMSN and in other organizations where he's worked in the past, so he's had plenty of time to learn that finding the balance between that desire and organizational needs means working closely with fellow CXOs to learn the different levers of the business.

"If you've got a sales team or a product team that needs to deliver in a certain period of time, but the solution is going to take twice as long, working with the CXOs helps you find something that meets all of the expectations," Spooner says.

"While it's always great to be able to deliver a hundred percent, there are times when there is also a need to look at what is fit for purpose that meets the expectations in terms of getting it out to market. And I don't think you can do that in isolation; it's particularly important to draw in your colleagues, it's particularly important to understand what it is that they need.

"The thing you're looking for is, in true program management style, the trade-off between scope versus delivery and time frames and you've got to find a balance between the two."

Click here for Part 6 of CXO Priorities | GLOBALIZATION