Quality Assurance and Project Management:

CRD

Jan 16 2009   10:12AM GMT

Understand customer requirements and make your customer understand



Posted by: Jaideep
CRD, Customer Requirements Document, business requirements, customer requirements, defect free software

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.

Jan 14 2009   10:10AM GMT

Digging the 10 precious ‘Experience’ Treasures



Posted by: Jaideep
SDLC, business management, Bug Management, CRD, Customer Requirements Document, team management, customer requirements

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


Oct 15 2008   10:34AM GMT

Reasons of Unclear Software Requirements



Posted by: Jaideep
Project Management, Quality Assurance, SDLC, Project Lifecycle, STLC, Bug Management, CRD, Customer Requirements Document, software requirement

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):

  • The vendor representative deputed for studying software requirements is inexperienced in terms of customer business
    The vendor representative’s tenure is too short at customer site to study its business and requirements
    The vendor representative is not curious enough to dig down each process at customer site
    The vendor representative being poor at documentation
    The vendor representative thinks collection of relevant forms and reports is a waste
    The vendor representative keeps more in his mind than documenting (the business rules, processes and requirements)
  • (Customer Part):

  • No clear cut representative(s) identified
    Business clarity is delivered by the person other than actual process owner
    Process owners too occupied
    Process owners depute their subordinates and perceive they will explain the correct picture
    Management before signing the final documents do not vet each process and business rule
    Poor management’s involvement
    Wrong perception that vendor will build a strong software that will meet all their requirements on its own

  • Oct 10 2008   10:56AM GMT

    Why pay to vendor for understanding customer requirements?



    Posted by: Jaideep
    Project Management, SDLC, Project Lifecycle, CRD, Customer Requirements Document

    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…