CRD

Understand customer requirements and make your customer understand

You not only have to understand the customer but sometimes you have to make customer understand what exactly he requires to enhance his business. Many a times, a customer is not able to chalk out clearly what business requirements he wants to get embedded in the software. He is not clear about what exactly he should get embedded in the software to get the optimum out of the software and business mix. He might be having a broad idea about what he wants to see as a final product, but may not be able to define what the core components of this product are. Customer would say the team to study their business as they are doing it, without getting involved in it. This could be serious and the seriousness if not understood rightly in time (emphasize on ‘understood’, rightly’ and ‘in time’), would lead to disastrous results.

Customer is not for experimentation. Clear and crisp ‘Requirement freezing’ is the right start. Customer may be required to be educated on what business, requirements and rules can be built in the software. A simulations or scenario generation is important to make customer understand how the software will work once completed. Customer needs to understand very clearly at the initial phases - What ease or comfort will the software bring out to business processes by giving out certain set of business results. Customer has to understand very clearly the other part of the story too. The software definitely will require certain extra skill sets, enhancements, or extra efforts once it is completed and implemented at customer site.

Digging the 10 precious ‘Experience’ Treasures

Past is not to be buried. It contains a treasure called EXPERIENCE. In software development this treasure is of ample importance for acquiring skills required to handle the unwarranted turns and twists during the development (and implementation) period.
What we can learn from the past is the hiccups that caused delays and stoppages in a development project. We can use that learning as a tool to tackle the problems occurred during the project life cycle. The learning could be in the form of:
1. Handling customer
2. Freezing customer requirements
3. Preparation of documents
4. Selection of a project manager
5. Development Team formation
6. Key users committee formation at customer end
7. Management committee formation at customer and development end
8. Team coordination
9. Tester’s involvement in the development
10. Choosing a right methodology for project management

Reasons of Unclear Software Requirements

Broadly there are two main loopholes in case of unclear software requirements – vendor and customer. Unclear Software Requirements could lead to disaster not only for the vendor but for customer also as I stated in my previous blog. To vendor it may cost money, time, reputation, business and at worst the closure of business. To customer it costs time, money, employees trust in its management, management confidence in selecting a vendor and at worst a decision to not to streamline their business in terms of a new software.

The main reasons of unclear software requirements could be:-
(Vendor Part):

(Customer Part):

Why pay to vendor for understanding customer requirements?

In normal scenario when an order is finalized between a vendor and a customer, for building new software by the vendor, the payment terms are set in such a manner that some percentage of the project cost is paid soon after the completion of customer requirements study, generally on finalization and submission of customer requirements document (CRD) by the vendor to the customer. The completion of this phase shows that the vendor has clearly understood the customer and business requirements and is capable enough to build all those requirements in the software product that he is going to build for the customer.

Customer’s ultimate goal is to acquire or purchase the final product that fully meets its functional and business requirements. Then why customer should pay out of his pocket for something at a stage that is of no use to the customer. The requirement study is the need of vendor and not the customer. Customer finally needs a product.

What if the product built is incapable of meeting customer’s requirements. Then why not customer pays to vendor just once at the time of product delivery, User Acceptance and implementation completion?

Do we buy a complete car or pay in parts – for steering, for body, for brakes, for seats, for belts… and so on…

Just a thought…