except when they are wrong ;) . Well, customer is almost always right but only about the problems/symptoms they are experiencing. But sometime even they are not in a position to completely explain their problems. And the gap becomes even wider when some customers start telling you about the solution, that they think, could solve their problems rather than focusing on explaining the requirement first. Suggesting the right solution is our job.
Not to mention that before a requirement or problem reaches you, it may already have gone though several tweaks and in that process, the context and intention, about the original requirement/problem is either lost or have never been propagated in the first place. So we should not be afraid to challenge the requirement, if it is hidden behind a suggested solution.
As a consultant, the challenge is to first get the requirement or problem in its unadulterated form e.g. 100% pure requirement / problem symptoms from the end user. Get the confirmaion about not just “What” but “Why” , “Who” and basically everything with a question mark, to make sure we understand the context / intention of the issue to avoid literal interpretation. Does not mean you should bore the user to death even before writing a single line of code but Correct interpretation of the requirement and verification with the customer representative can avoid problems at a later stage.
Once we get the idea about the original requirement then next step is analyze and think about possible solution options…but wait..more often than not, we have a solution approach already suggested by the customer’s business process expert / IT operations person. We should not fall into the trap of blindly accepting a solution approach suggested by the client representative.
Remember that some of client IT representatives themselves have some experience with software development and that’s not a bad thing at all. However, it also means that instead of getting pure requirement from a business user, we get a requirement description which is contaminated with a suggested solution approach. As a consultant our next challenge is to set the customer’s expectations about a suitable solution considering the constraints.
-----------------------------------------------------------------------------------------
Edited and Cross Posted from my internal company blog.
-----------------------------------------------------------------------------------------
Posts
There is only one problem - there is no 100% requirement without a technical solution flavor in most cases.
ReplyDeletePeople think of requirements usually in the context of what their current system does. An average user cannot abstract out the requirement from the technical solution in which he works about it.
This is not a user problem either - many consultants are also guilty of thinking about "how do I solve it in SAP technologies" the moment they go into workshops.
Thanks Vijay for adding your thoughts.
ReplyDeleteAgree that it's not easy to express the requirements without being affected by the technical domain. But that's exactly why we need to be more cautious to understand the context and intention of the requirement. I don't think users will have to make any extra effort to express the problem/requirement in normal business language, once they know that it's kind of important.
Further, It's not even such an issue if users want to describe the requirement in relation to external aspects of the system, they are familiar with. But it's more dangerous when requirements are drafted by the IT representatives of the customer team/functional consultants and described more as internal working approach/solution. In the process, the original requirement from the user went missing/ignored.
If I review a design/estimate with requirement section that, for example, starts as
....we need a new Z table to upload....or
....develop an ABAP program to search for all the CRM documents with reason codes A but keyword B not present in long text.....or
.... requirement is to implement a user-exit to check..
then I get really concerned and would like to know the background and related functional/non-functional requirements.
This is a good read coming from a SAP blog.
ReplyDelete