FedEx Corp. is a prime example of how IT is just a part of the business: There is no question about whether technology will be used for business service development. The only question is how.
From developing its package-status tracking application in 1994, to its latest endeavor, the SenseAware service, the FedEx innovation group, which reports to the technology and marketing departments, resolves customer challenges with technology.
Geared initially to scientists, SenseAware allows customers to track real-time data about their shipments -- whether the package has been exposed to light, where it is in the system, or what temperature it is at any given time.
The FedEx innovation strategy team may be responsible for bringing new products and services to market, but everyone at the company "carries responsibility for driving innovation in some form or fashion," a company spokesperson said.
In other words, IT is not thought of as an entity unto itself. It doesn't lead the charge when a new service is being developed, nor is it an afterthought; instead, it is an integrated business process.
"My pet peeve is the term 'business and IT alignment'; it's not about alignment any more, it's integration," said Jack Santos, CIO executive strategist with the Burton Group in Midvale, Utah. "There shouldn't be a business on earth where IT isn't integrated into the business to deliver services to customers."
It's up to the CIO to make integration with the business happen. "You can always tell who a new CIO is, because they don't think in or speak in business terms, or talk to the customers," Santos said. "The CIO has an opportunity to make as many contributions as any other business person to the customer, but if you find out about a new service R&D is working on after the fact, you failed."
Steps to business service development successes and failures
It has to be decided whether a service should be developed from existing service components, bought or built. "I used to work for several banks, and they all said, 'Well, our solution is so unique that we can't pull it off the shelf … and it wasn't unique," said Michael Kirwan, CIO of Yahoo Inc.'s corporate systems group. "The trick is the ability to recognize when a solution is truly unique and can't be bought," he said.
The banks Kirwan worked for needed the same technology that just about every other bank needed in order to deliver services, such as a general accounting package -- of which there were plenty. In the case of Yahoo, the company could not buy what it was looking for off the shelf. What today is called "the cloud" did not exist, and the monitoring and software distribution technology Yahoo needed to deliver new services to customer did not exist either, he said.
I used to work for several banks, and they all said, 'Well, our solution is so unique that we can't pull it off the shelf … and it wasn't unique.
Michael Kirwan, CIO, corporate systems group, Yahoo Inc.
"So, in our case, we had to build a private cloud. But the general rule is, look to other services and build on them, then buy, then build it if you have to," Kirwan said.
Another reason Kirwan has seen business service development projects not cross the finish line: a lack of transparency as to the projects' true costs and between the CIO and the business, he said.
In the end, the aim is to be able to build a foundation so that services can be added or changed as needed. Earlier this year, Continental Airlines Inc. did not set out to develop a new service to shorten the time airplanes are delayed on the tarmac; but when a new Department of Transportation rule went into effect, with fines attached for these delays, the airline was ready. It had already built a Microsoft SharePoint platform for e-discovery and document management.
A new employee portal for tarmac delay tracking was a service the airline essentially added on the fly, said Denise Wilson, senior manager of technology in Continental's enterprise engineering group in Houston.
Agile approaches to business service development come in many shapes and forms. As seen above, an off-the-shelf product can be tweaked quickly. But many experts view agile software development in terms of a framework, such as Scrum; while the Agile Manifesto describes agile as a methodology that involves these principles:
- Individuals and interactions instead of processes and tools
- Working software instead of comprehensive documentation
- Customer collaboration instead of contract negotiation
- Responding to change instead of following a plan
Regardless of the industry, and regardless of whether a project is IT-related, the trick to being agile is to develop a release planning stage, in which aspects of the project are divided into smaller, more manageable chunks, said Ross Pettit, client principal at Chicago-based agile consulting firm Thoughtworks Inc.
Every week there is a checkpoint to gauge the progress made, the current understanding of the problem to be resolved, what needs to be done next, and how the team is tracking against the agreed-on solution path, Pettit said.
By having the primary stakeholders involved in this process, the business problem is laid out for all to see, and obstacles can be removed immediately. "Week after week, there is tremendous transparency and exposure to all the stakeholders, so if a problem comes up, the team can say 'Here's what we need access to, here's the person we need to talk to, here's the people we need to work on this problem,'" Pettit said. "This allows stakeholders to make the resources available for what needs to be done, immediately."
Let us know what you think about the story; email Christina Torode, News Director.