The software development group at this large manufacturing firm is infamous for never delivering software on time or within budget. So of course someone in management suggests offshoring some of the software development work to save money.
And the offshored project comes in early and under budget, with quality at least up to the level of internally developed software. Naturally, offshoring is touted as the way the corporation should go.
Many people in the centralized IT department, including pilot fish, aren’t thrilled with this idea, and they have serious questions about the orange-vs.-apple qualities of what is being compared. They do an analysis of the processes followed for offshore success versus an internal failure. Lo and behold, with the internally developed project, the local VP kept changing his mind even after having signed off on the various project documents. He even made light of his ability to intervene at any moment; he didn’t seem to care what those changes did to the cost, deadlines or quality.
With the offshore project, he knew that once the project documents and contract were signed, they would represent exactly what was going to be delivered. Says fish, “He could jump up and down, threaten to fire people, or even hold his breath — the only way to get a change was to sign a contract modification (change order).”
As a result, he was very careful with those documents. He made sure he understood what they said and that they represented exactly what he wanted.
The internal failures were largely due to upper management, not inability of IT staff. The success of the offshore project was also largely due to upper management, not an inherent ability of the contracted firm.
End result? The offshoring continued, and internal projects remained, but eventually the upper management was replaced.
Feed the Shark! Send me your true tales of IT life at sharky@computerworld.com. You can also subscribe to the Daily Shark Newsletter.
