InformationWeek

"The most critical situation occurred when I lost the lead architect of a critical Java component the weekend of its deployment," Hagar says. Hagar decided to go ahead with the implementation rather than delay the rest of the project. "We called Sun Microsystems and they sent a top-notch consultant, who helped ensure that the rollout was smooth and successful."

On another occasion, a lead developer gave notice that he was resigning two weeks before a new component rollout. Hagar called a contract developer who had previously worked on the system and persuaded him to return to the project the day the developer quit. "We barely missed a beat," he says, "although I admit to missing a little sleep."

TIAA-CREF's Erlikh points out that the two-week period between when an employee gives notice and when he or she leaves can be used to bring a replacement up to speed. A mechanism for an orderly transfer of responsibilities should be part of an overall application development plan, because the expertise of key designers may be required for other duties before the end of the project, she says.

Turning to outside consultants to help supplement staff doesn't always work. At the outset of the Glaxo Wellcome project, Hagar believed there wasn't time to train his full-time staff and hired consultants to supplement in-house skills. He now has second thoughts about hiring outside help. "Because these consultants were gaining highly valuable and marketable experience in a very tight and competitive labor market, we didn't keep them long," he says. "Turnover was a problem for us."

Hagar eventually reversed the policy and staffed the project with retrained full-time personnel. "It made a huge difference," he says. "The Glaxo Wellcome employees came up to speed quickly and proved to be very productive. They had a solid foundation in the disciplines of software engineering, they thoroughly understood our business, and they were excited and motivated by the new challenges and opportunities."

There are good reasons for developing the skills of a reliable, permanent staff. But, in reality, most large-scale projects present financial constraints that make contracting for temporary external resources unavoidable.

"In our project, we had more modules than we had designers," says TIAA-CREF's Erlikh, "so we had to hire consultants. You do the best you can under the circumstances." Even so, Erlikh has found that when the division of duties between the designer and the temporary programmer who is creating code is correct, then the loss of the coding expertise can be compensated for if the temporary person leaves. "If a problem occurs later, the designers have the skills to make corrections," she says.

While there are always risks and contingencies in large-scale projects, whether they come from the technical or the human side, experienced planners advise that the best assurance against loss of control is a component-driven, iterative approach with quality-assurance testing at every step.

It's not an easy process, and should be based on thorough, early planning. "I'm considered a good planner, but I don't enjoy planning," Erlikh says. "I do it because after having experienced what happens when you don't plan, I know what the consequences will be. The farther you get into a project, the worse it gets. And, since I hate a mess, I know to plan early."

return to page 1, 2