WHEN ENGAGING WITH A PROVIDER TO DEVELOP CUSTOM SOFTWARE, CLIENTS ARE OFTEN CHARGED FOR PIECES OF WORK THAT REQUIRE MODIFICATIONS. SOME CLIENTS HAVE THE PERCEPTION THAT MODIFICATIONS SHOULD BE AT THE EXPENSE OF THE PROVIDER. VENDORS, ON THE OTHER HAND, TAKE THE POSITION THAT VARIATIONS SHOULD BE AT THE EXPENSE OF THE CLIENT. THE SITUATION FOR REWORK IS RARELY THAT SIMPLE.
Most rework actually does not occur due to defects in the system. Rather, it occurs due to a variety of reasons. The more common reasons are:
Deficient or ambiguous requirements
Poor communication or misinterpretation of requirements
Changing business needs
“A vendor is generally contracted to deliver a system that meets the needs of the client as outlined by the client during the scoping phase,” commented Kareem Tawansi, CEO of software development provider, Solentive Software.
“However, often the needs of the client change as the system is being built – what was necessary 3-4 months earlier may have been deprioritised and other features prioritised,” continued Kareem.
“As a result, a natural set of variations need to be made to the system to accommodate changing client needs.”
Clients also need to understand the difference between variations and defects. Variations result from changes in scope and requirements, while a defect is a fault in the system that has been created by the developers of the system. In a fixed cost arrangement, vendors are liable for rectifying defects in the system at no cost to the client. A client should not be charged for poor quality work. Variations on the other hand, are generally a change in the original functionality and should be the responsibility of the client.
There is rarely contention between what is a defect or what is a variation when a client and vendor have a good working relationship.
“When there is a mutual understanding and trust between a vendor and client, the process of dealing with variations is straightforward,” commented Tawansi.
“As part of the natural process of bringing the system to a state that it can be rolled out into production to its final audience, there is always a period of rework,” commented Tawansi. “As such, both vendors and clients should make allowances for refinements and clarifications. Sometimes, the extent of this is not known until you get there and it is for this reason, that both clients and vendors should share the burden of taking almost-ready software to a production-ready state,” continued Tawansi.
“Beyond the first release into production, software owners should be thinking in terms of version 1.1, 1.2 and 1.3 where each version represents a further investment of 30% of the prior budget. After about the 4th point release update, the next major release should be considered,” advised Tawansi.
To minimise the amount of rework required, both clients and vendors need to go through a learning process. Vendors need to understand the client’s business and the goals for the system. Likewise, clients should be educated about the vendor’s process to ensure a successful delivery.
“The education of clients and vendors is a journey that both must undertake together. The vendor needs to understand the client, their culture and what they are trying to achieve. This can be reached through regular contact with the client in the form of workshops and meetings, as well as spending some onsite time with the client, working side-by-side with them,” suggested Tawansi.
“Communication and interpretation of requirements plays a crucial role in delivering a successful project. In offshoring engagements, communication is a challenge due to misalignments in time zones, language barriers and cultural differences. By offshoring your development, you can place a higher risk of miscommunication and misinterpretation of your requirements,” warned Tawansi.
Business needs are generally dynamic and rarely static. The lead time to develop a complex system is extensive. It is therefore important that vendors and clients are planning for the future when setting out requirements and understand that variations are a natural part of the development process. However, variations completed as part of an agile process will ensure that the system developed remains relevant to the business when it goes into production.