Late in the game changes - defective process or competitive advantage?

Most South African IT companies are familiar with ever-evolving specifications, especially for e-commerce projects, and programmers can attest to last minute changes. Is this the result of a defective process?

Nomaswazi Nkosi, national support manager at Compuware Southern Africa, says: "One should view late changes as a potential source of competitive advantage, rather than as a result of defective process.

"Late changes create the potential to deliver functionality not even envisioned yesterday - as new technologies emerge at such a rapid pace," she says.

"Today, late changes arise from the uncertainty and turbulence in the marketplace - not from a defective process," says Nkosi. "Market forces, business alliances, suppliers and customer keep changing, and so must the applications to support them."

She says historically, businesses attempted to reduce the overall development and maintenance cost by concentrating on requirements and design to drive out defects early. Today, we must rather focus on how to reduce the cost and time required to handle late changes.

Nkosi says practices that worked in less turbulent times need to be re-examined. She proposes three strategies for managing e-project requirements: focus rigour late in the life cycle; institute light requirements practices (that is minimise formality and rigour, especially early in the process); and maximise requirements understanding through improved collaboration.

To accommodate downstream requirements changes, Nkosi says a stable code base should be maintained, testing should be automated while an adaptable design should be sustained. "In other words, design for easy change and don`t allow defects to stick around."

For high-speed development, she recommends stripping away excess formality and documentation, and concentrating on employing the simplest practices to get the job done.

Nkosi says people often forget the real purpose of requirements specifications is not to produce documents but to ensure that everyone involved in the project `understands` their role. "So rather than give programmers lengthy reports to read, give them a synopsis and hold a brief discussion session.

"Success with high-speed e-projects lies in giving talented people an understanding of what they are supposed to accomplish and encouraging enough intense interaction to generate innovative solutions and uncover mistakes," says Nkosi.

Tools that focus on straightforward requirements recording and monitoring, such as Compuware Reconcile, help with high-speed development. A plus of Reconcile is that it also facilitates communication between the authors of requirements, developers and testers.

Nkosi cautions that not everyone should be managing e-business projects. "Some managers want to apply traditional practices in traditional ways and this does not work.

"However, managing e-project requirements doesn`t mean abandoning traditional requirements management practices. It does mean understanding the difference between `ad hoc` and `light` - stripping away the `should do`s` to get to the `must do`s`," she concludes.