2 May 2010

Who decides a project’s requirements? Customers?

Customers: Are They Always Right?

Anyone who derives direct or indirect benefit from a product or service offered is a customer. It’s not necessary that the customer may be always right. However, the customer has a viewpoint and one must understand and respect customer’s viewpoints rather than forcing developers to determine among the customers who do not agree with conflicting project requirements.

As a software customer one would be primarily responsible for the following activities: Customers at times believe that the analyst or the member from the development team should already know what the customers need. Defining business requirements is not the ownership of the customer but the project team.

It would be ideal if the analyst is given the pulse of the current systems and processes coupled with existing documents to educate them about customer’s business concepts and terminology.

Customers usually don’t find it significant to invest time with the project team for requirements gathering or elicitation activities. Sometimes customers get so busy with the key responsible areas at work that they usually don’t give justice to the requirements gathering activity and the requirements gets captured just on assumptions.

Customer needs to prioritize what requirements are crucial and critical to the project. Requirements, which are vital, need to be delivered on priority whereas those that are good to have features can be delivered phase wise. Customers have to understand that not all requirements can be given at the same time. Phase wise delivery would be ideal.

Nilesh Raje works as Business Analyst with SYSTIME Computer Systems Ltd. based in Mumbai. He also has his articles published earlier with RQNG, International Institute of Business Analysis, ProjectTimes, Business Analyst Times and ManagementNext magazine. He's been a reader here for a while and has proposed this question;

Who decides a project’s requirements?

1 comment:

  1. Currently I am at the client's end in the middle of a system implementations. I don't think the client knows what kind of specifics the provider is looking for, so we end up with throwing out ideas, details & suggestions of what we need.

    Honestly, Both sides is responsibly for defining requirements.
    - The client has the info for what they want
    - The provider know the what kind of details is needed

    The problems is that requirements & specification are often mixed together.
    The provider should figure out why the customer want this? what problem they are trying to solve?

    The client might say 'We need to use the billing module to generate a tax report',
    … What's the actual problem? … is it that they want a tax report to be generated?, billing department to control the report? or their old system did it that way?
    Depending on the answer, the requirement differs.

    The provider needs to be able to separate the problem from the suggested solution, then define the requirement … then suggest a solution.

    The provider needs to figure out:
    - what they have now
    - what they are trying to do
    - what issues they are having

    at the latter part of the requirement defining process … then prioritize the needs

    If the client say they doesn't have time, then provider need to educate the client the financial & time impact with change request due to bad requirements.