Creating Good Software - Align expectations and development

The easiest way to create a bad product in custom development is to misunderstand the customers expectations. This is a discussion of risks that are brought by poor specification, poor understanding of business needs and the hurry to make a profit.

Medium size businesses are usually partnering with one or two software development companies. These businesses are entering a partnering relationship with the software company, and nearly always turn to them for their solution needs.

From a business perspective, this arrangement makes sense for both sides.

  1. The business has the guarantee that whatever new product is delivered will be able to seamlessly integrate with their current systems.
  2. The software development company has a broadened influence on the business and knows that they will extend their cooperation for at least several years more.
The problem with this arrangement is that the customer is trusting the software supplier to deliver any and all possible solutions, even those that aren't in the core product line of a software development company.

Example scenario
Shortinfosec Democorp is using a Customer Relationship Management (CRM) system developet by ACME Software Devel. According to the new business model of Democorp, a new billing system is needed for proper invoicing of delivered goods and services. ACME Software Devel is invited to create the billing system. The requirements given from Shortinfosec Democorp are the following:
  • The system needs to generate invoice for all customers summing up all their outstanding charges
  • The system needs to be able to create discounts for VIP customers in the CRM system
  • The system needs to produce reports for invoiced and outstanding amounts
ACME Software Devel receives the specification, confirms ability to finish the job and creates a product. During testing of the delivered product, the following issues are raised by Shortinfosec Democorp:
  • The billing system does not interface with accounting, to track payments
  • The billing system does not calculate interest on late payments
  • The billing system operates with the current product set, and there is no flexible way to implement new products
  • The discounts are limited to fixed amount or fixed percentage for the VIP customers
  • The reporting aspect is limited to 2 reports
ACME Software Devel responds that these issues were not mentioned in the initial specification, and requests a 3 times increase in agreed price to deliver the required changes. After tense negotiations, ACME Software Devel is contracted to scrap their solution and provide interfaces for a third party billing system. Shortinfosec Democorp hires a consultant to define all requirements and issues an international RFP for the Billing System.

Analysis
The process described above was riddled with errors.
  1. The original specification given by Shortinfosec Democorp is quite poor and abstract - The project manager for the billing system did not do sufficient research to identify all the required aspects of the desired solution
  2. ACME Software Devel. assumed that the specification is final and that the product is very simple - The software company account manager and project managed did not expand the analysis with the customer to investigate all possible issues.
  3. Based on assumptions that the other side knows it all and will tell/do all that is needed both time and money were spent. - The process was at least doubled in costs and time frame.
  4. The entire exercise ended in tense relationship and diminished trust between both partners - Both parties were left dissatisfied by the other one, and a good business relationship was degraded.
Recommendations
While it can always be discussed that the responsibility for functional specifications falls on the buyer, the software development company should seize the opportunity to help or guide the buyer to produce a mutually agreed good product.
Here are several steps that should be taken to improve the cooperation between partners in creating a new software solution.
  1. Never assume that the specification is all the customer needs. If the specifications are too inconclusive or general, strive to specify them in greater detail. This will reduce the need for assumptions and possible incompatible design in the finished product.
  2. Research the market, see what is actually behind the simple sentence uttered by the buyer. For instance, the buyer might like the idea of a software managing the queues of people in front of their sales counters. But this software is known as customer flow management, and is an entire science of it's own.
  3. Establish a good and permanent collaboration with the buyer. Collaborate as much as possible in the early stages - even when the new requirement is still an idea. Always present
  4. If necessary (often it is, to reduce conflict of interest) suggest an external consultancy to assist the the buyer in the process of defining requirements, so that the finished specification is easy to follow.

Related posts

Information Risks when Branching Software Versions

3 rules to keep attention to detail in Software Development

8 Golden Rules of Change Management

Application security - too much function brings problems

Security risks and measures in software developmentSecurity challenges in software development

Talkback and comments are most welcome

No comments:

Designed by Posicionamiento Web