Convoluted best practices in technology development can create a hurricane of chaos, even in financial enterprises that are often touted as being on the leading edge of technology innovation.

As a quick view of one Fortune 500’s IT unit illustrates, flawed best practices can quickly wreak project havoc.

  • A system support staff charged with troubleshooting applications and server problems could no longer address tech failures in the required time frame.
  • Although each IT unit had its own set of best practices, the staff reported spending half its time on unplanned, unscheduled tasks.
  • In the spirit of technology maintenance and handling new projects, the IT staff had mushroomed to 1,500 professionals, and yet chaos still abounded.

That was the initial scenario in June 2001 when TechRepublic member and IT consultant  Marc Talluto was hired by the financial entity to improve IT response time. Talluto, a principal at Chicago-based consulting firm Acquity Group, LLC, explained that tech management overlooked a key element in project development methodology—the creation of project documentation for each part of the project’s life cycle.

Identifying project patterns
After spending a few months working with the company—which involved interviewing IT employees and various tech groups—the consulting firm, which develops technology strategies, project methodologies, and then aids in their dissemination, saw a pattern emerge.

Project data (such as server size, network bandwidth, and the documentation of business functions) and development data (like architecture diagrams, network segments, server names, and database tables) weren’t being modified to depict how the project vision diverged from actuality.

For example, while developers could code and deploy a Java application to specification while following best practices, they were giving little thought to who would maintain the application upon deployment.

The troubles weren’t just in the development phase of the technology life cycle. Tech project data from business analysts, spec writers, developers, testers, and support teams increased and became more complex without consideration of the next team’s ability to decipher the project’s history. That meant the team charged with supporting post-deployment applications couldn’t efficiently do its job.

Failures in communication are common culprit
The project patterns identified by Talluto’s firm are a result of a fairly common breakdown in IT projects due to poor communication between project teams.

“While a given IT team may use the latest technologies and recommended architectures, they don’t interact with other teams efficiently or manage interteam processes effectively,” explained the consultant.

No one, including management, obviously wanted the ensuing chaos, yet no one unit determined how to thwart it.

“It was not intentional, but rather it happens slowly over time,” said Talluto. “Factors including the pace of technical change, the needs of the business, staff turnover, legacy architectures, and resource constraints all lead to an IT environment that is managed by reaction.”

Making changes at the top
Knowing that the rate of change with a large IT organization can be slow at best, and that buy-in and enforcement of standards is always a challenge, Talluto set out to have the company adopt interteam best practices.

He started at the IT helm and then worked his way down.

“Basically we have set a vision for how all IT departments should operate together,” said Talluto. “We’ve mapped how current initiatives fit into the vision, and are now working on mitigating the gaps that exist between current and future state.”

With management’s involvement, Talluto helped the company build out more realistic and generally longer time frames for project development. This included a view of how applications would interact with one another as well as a vision for the technology life cycle and associate checks and balances.

Educating the tech masses
Talluto then set out to get staff buy-in by educating them about the big picture of the project life cycle. He explained that since many people touch a project, each project had to be focused on a specific set of incremental steps so that the next team could succeed.

Part of the buy-in strategy was illustrating how the project development problem had become a common occurrence across the entire organization. This fostered involvement, as all staff realized that the solution would help them and everyone else, said Talluto.

“By reviewing some production incident, you can better identify the best-practice failure and its domino effect to staff,” he explained.

The consultant steered clear of accusatory messages and blame. “The question of who hasn’t implemented best practices is tricky because each one may have independently, but they have not done so as an organization,” he said.

Seven months into the turnaround, the barriers to success have been mostly cultural, said Talluto, adding that they’re not insurmountable. And revamping lost best practices doesn’t mean everything else comes to a standstill, he pointed out. This past December, Talluto also spearheaded a new set of project initiatives for his financial client. He expects his best practices implementation to be completed by the end of 2003.

“Technology in [the financial] industry has not typically been a focus until the last few years, when it has exploded,” said Talluto. “It is far easier to buy hardware and software than it is to learn how to manage it effectively.”