Some of the world’s most successful companies have a secret: Business and IT are finally learning to work together in a manner that provides better competitive differentiation and bottom-line benefits. However, the road to successful business-IT partnerships has been paved with abandoned projects, inefficient business solutions, and political bad blood.
For one thing, most business people are not technologists, so they often have trouble articulating what they actually need. Nevertheless, IT is supposed to know how to translate business requirements into technology solutions, which is hard to do when both sides speak different languages. So, despite best efforts and the best of intentions, the outcomes are not always as intended.
“This is all too common, and it is because the two sides (business and IT) do not understand each other,” said Brett Balzer, CMS Program Manager at Underwriters Laboratories. “I work in IT, and the trend has been to be more business focused. One thing that I have not heard is for ‘the business’ to become more technology savvy or capable. I think that with the direction the world is going, it will be essential for business leaders to understand technology, and not just pass it off to IT. They need to learn what the capabilities of their systems are and how to articulate what they want to get out of them.”
You Spent How Much on What?
Imagine spending more than £1,100 on a box cutter. Not the average box-cutter, mind you, but a tool designed for another purpose entirely.
Gary Nuttall, business intelligence analysis team leader at Chaucer Syndicates, was tasked with deploying hand-held barcode readers in a warehouse. The barcode readers were pen-like devices capable of reading and recording barcode data attached to parcels as they arrived. The idea was, if the company purchased the barcode readers, warehouse staff members could simply scan an incoming package rather than opening incoming boxes and logging the items manually. Like popular deliver services, the company would benefit from better staff productivity and more accurate data.
Nuttall analyzed relevant data: how many goods-in bays there were, how many staff were on duty at a time, battery recharge cycle, allowance for broken units, etc. He worked out how many devices needed to be bought. “The project went live and delivered on its promise of increasing staff productivity,” he said. “Credit to all involved.” It certainly was a good project, he explained. It met its deadlines, dealt with all the constraints, and delivered the expected business benefit.”
A couple of weeks later Nuttall got a phone call from the warehouse manager. Apparently, the staff loved the devices so much they wanted more, which Nuttall thought was odd. Had the units broken? No. Were they taking longer to charge than estimated? No. The staff simply loved them. Somewhat perplexed, Nuttall decided to pay a visit to the warehouse to determine whether there had been some sort of miscalculation.
It turned out the pen readers were being used to split open parcels, because they were the ideal size.
“Sometimes a project can deliver benefits in a way you don’t expect,” he said. “It’s important to ‘walk the floor’ to see how a project is really going.”
Apparently, it’s a good idea to train employees on new processes and have some departmental oversight, too.
New Application, Old Way of Doing Business
Dave Mendlen, CMO of DevExpress, is one of the few who have worked on business solutions as both a technical leader and a business leader. At Ameritech, he worked on point-of-sale (POS) and call center applications designed for the company’s cellular business that had a rather interesting history.
“The system was not optimized for the sales professional,” said Mendlen. “The sales people just knew that’s the way they did things – one step, then another step – but they didn’t really understand why they were doing what they were doing.”
As is typical, the person who built the proprietary system had left the company. A replacement application improved the user interface but not the process of cell phone activation.
“It took forever to activate a phone when it didn’t have to. The process was designed in a sequential way, when it could have been designed to implement processes in parallel. That way, you could do a background process (like a credit check) so you’re not waiting for one step to complete before starting the next step,” said Mendlen. “Eventually, they had to rewrite the retail and call center applications. It was a classic case of passing the weaknesses of one app down to the next.”
What Competition?
Ken Nicholson, an engineering consultant at Rambus, worked on a semiconductor project that looked promising but had dire results. The goal was to develop silicon IP that could be licensed to larger companies. The product was a network accelerator chip that reduced protocol handling overhead on the host CPU. Stakeholders at the company believed it would revolutionize network performance. Chipset and server manufacturers were interested in the product, which reflected well on sales, marketing, and engineering. And, the project was considered so strategic it was spearheaded by the president with support of the board.
But… “By the time the solution was delivered, it was no longer leading-edge and the features it offered were of little value in the market,” said Nicholson.
The investors lost tens of millions of dollars. The company was subsequently dissolved.
Advice for Avoiding Common Pitfalls
The above examples illustrate what can happen when something critical has been overlooked. However, there are a few more sage words of advice DevExpress’ Mendlen and Rambus’ Nicholson have to offer.
#1: Choose the Right Project Lead. One problem with cross-functional teams is that the buck may stop nowhere. A common piece of advice is: Get an executive sponsor. However, just any “executive sponsor” may not do.
“You absolutely have to have the person with the right political capital because they can insist on the best business people and the best technologists. Often times what happens is the business people assigned are B players. Having the wrong business people involved is death,” said Mendlen. “Whoever is running the project has political capital and hopefully real capital and resources to apply to it because, whether it’s Windows Media Center or a call center, you’re going to have to live with it for a long time. Don’t pay for it twice; pay for it once and be thoughtful about it.”
#2: Pay Attention to Technology Cycles. Both Mendlen and Rambus’ Nicholson underscored the need to understand where a technology is in its lifecycle. Otherwise, the end result may be a commodity or legacy solution by the time it is delivered, which reduces the potential for sufficient return on investment.
“You need to have the right stage technology and the right people brought into projects. And you’ve got to be relentless. If a project isn’t working, kill it,” said Mendlen. “What happens is these projects go on and on, burning resources, so you have to kill it.”
#3: Beware of Scope Creep. While there is an increased trend toward “Agile” projects that are designed to be smaller in scope so they can be executed more quickly, projects nevertheless can become unwieldy as more features, functions, and people are added to the mix.
“The successful projects I’ve seen are the ones that have been scoped and sized. Don’t try to solve too many problems simultaneously. Break it into smaller projects so you can succeed with one and then another,” said Mendlen “Quite often, projects start as small ideas and then you end up with teams of 200 or 300 people and those things rarely succeed.”
See also:
