System Transformation Portal

By William M. Ulrich
(Originally appeared in Computerworld March 19, 2001) 

Many things have changed in IT over the years. Computers are faster, software is better and we can exchange information with the click of a button. 

Yet one thing that hasn't changed - but should - is the way we address the challenge of ensuring that functional requirements are implemented into critical business systems in an acceptable time frame.

Take a telecommunications company that hired consultants to replace a billing system. Tens of millions of dollars and years of effort went into building a system that failed to replace the old system and created more work for users because they had to reconcile outputs between the old and new systems.

Delivering systems in a timely manner has always clashed with getting the requested functionality into those systems. IT tried to improve the functional aspect of this challenge by introducing "heavy" methodologies involving hundreds of extraneous steps and forms. But these methodologies prolonged development projects and were abandoned in the early 1990s along with requirements analysis. Development cycles remained too long, and meeting functional requirements remained elusive.

Today, IT organizations must deploy e-business systems in a fraction of the time spent deploying other types of systems in prior decades. But they need to meet these time constraints and still ensure that the functionality they implement is what the end users want.

Various solutions have tried to address these time constraints. For example, agile, or "light," methodologies reduce development cycle time by eliminating unnecessary steps found in heavy methodologies while retaining the rigor needed to guide developers through the process. 

But agile methodologies don't address the specification issues that are driven by miscommunications between business users and development teams. For example, a user may think he's getting a new system, but he may only get a functional subset. The speed with which e-business systems must be designed and deployed continues to press companies into finding faster ways to get system functionality right the first time. Improved collaboration among participants can help here.

A collaborative development cycle requires that project team members - including end users, IT professionals, customers and business partners - create a shared purpose and principles, develop a common specification language and deploy communications tools to help them more freely exchange requirements and results.

Representatives from each group that's part of the project team should create a project purpose and set of principles to guide their actions. For example, a project purpose may involve creating an e-business system that allows customers to order products without having to interface with a human being. A principle may state that any participant can view any requirements, specifications, test cases, prototypes or other results at any stage of the project life cycle.

Agreeing on a common specification language is more important than the type of specification language being used. Any participant should be able to view system specifications and determine how they will impact the resulting system at any point in the project life cycle. This increases the likelihood of a user catching problems early in the development cycle and before the cost of fixing those problems soars.

Internet technology can facilitate the exchange of ideas, requirements, specifications, prototypes, test cases and related information. Online meeting and development tools allow participants to collaborate more frequently and freely than they would in face-to-face meetings. These tools should link all participants at every stage of the project.

Collaboration isn't a difficult concept, but it can be hard to implement based on historic barriers among IT, other business units and third parties such as application service providers or customers. But until this occurs, development cycles will remain too long and requirements too elusive to support growing e-business requirements, dooming a company in an economic downturn.