How to gather requirements from German clients
In most our projects and engagement the developers need to gather the requirements from the German client. This is not without pitfalls. Especially because of the different cultural background. But guess what: -> With the right process for gathering those information, this cultural gap can be easily overcome.
In the following we will give some practical advice to gather requirements from clients in Germany.
Have a first meeting
In the first step, have a short meeting with the client, asking some basic things about the project. The question can include:
“Who are the users of the system?”
“Kindly tell me more about the client who has ordered this system.”
“What modules will be in this software?”
“What technologies are to be used?”
“What are the requirements for documentation for the software?”
“Will other people also be working on the software for development?”
“Who is giving input regarding the requirements, except you? Is there someone from the customer side involved?”
etc.
etc.
etc.
These questions and many more should be asked, to get a feeling what the project is all about and also prepare mentally for the challenge. Also note down the points which are mentioned by the client. Usually one forgets most of the mentioned things after the first day after the meeting.
Repeat what the client has said
After hearing an answer or several answers, it’s always best to repeat in own words what has been understood.
For example: The client has been talking for a while about the project. Now the developer says: “Kindly let me repeat what you have said, so that we are on the same page. The system should be build in PHP and has 4 modules, which include the Customer Relationship Management, Human Resource Management, a Finance module, Travel Cost Calculator. The Customer Relationship Management Module should have the following functionalities……………………………………………………………”
Best would be to repeat the complete list of functionalities and the understanding about the project. This way the client in Germany is sure, that the developer in India has understood the requirement.
If that repetition is not done by the developer, then there will be always a doubt at the client side, whether the requirement has been understood clearly by the developer. The reason for this is also because sometimes the phone line is not clear in voice, the difference in accents (German Accent versus Indian Accent), the difference in perceptions (German Culture versus Indian Culture), the educational background (The client from Germany might be an MBA graduate, while the developer from India might be an Engineering graduate).
Therefore try to repeat at the end or during the meeting what the opposite side has said, so that all sides are sure about what everyone involved is speaking about.
Here a simple example to make this clear:
Client says: “I want this system to be programmed in PHP 5.4. The framework to be used is YII. The special thing about this software is, that it has an online calculator which takes its input from a server which will provide the information from an API, which will be provided by us”.
Developer says: “Thank you for telling about the requirement. Let me repeat this, so that it is clear that I have understood this properly. You want a system, which has to be programmed in PHP 5.4. The framework to be used is YII. The software also includes an online calculator which gets its information from an API, which will be provided by you. Is that correct so far?”
This might be a simple example. But this already shows that there could be a misunderstanding. Did the client mean by “provided by us” -> provided by the client company? Or did he mean “provided by the developer”. By repeating the requirements, the client will hear that the developer said “…API, which will be provided by you” and will intervene. The client will then say for example “Thank you for repeating the requirement. Most of it is correct. Only one point is not exact. The API has to be developed by you and will not be provided by us”.
So repeating the requirement will always help to clarify requirements and bring everyone in the project to the same page.
Ask for the requirement in writing
Especially in outsourcing projects to India (or any other country for that matter) it always makes sense to have the requirement in writing.
The client could be sending a first draft of the requirement as a Word file. Then the developer could ask questions regarding that requirement by writing the questions below the points which are in doubt. Through that, there would be a back and forth (sending Email back and forth with the Word document) where the document would become a fully fledged requirement document which can help as a guide during the development of the software.
Therefore: After the first meeting, ask the client to give the requirement in writing. Sometimes also the client will ask the developer to write down, what he has understood from the previous and current meetings so far, so that this becomes the document, on which future discussions can be based.
Use an online project management tool
Another very good way to gather the requirements properly is to use an online project management tool.
The developer would regularly post on which tasks he/ she is currently working on and also updating about the progress of each task.
By doing that, the client can from time to time check into the project management tool and see how far things have progressed. The advantage of that is also, that the client can intervene or can ask clarifying questions, if he sees developments which may go into the wrong direction.
A further advantage is also, that when the client writes directly into the project management tool, that the issue/ information is given in writing and can also be used for future reference.
Have a weekly meeting
A weekly short meeting can help to get both sides (the client from Germany and the developer/ developers from India) on the same page. It will also strengthen the relationship between both. The other person does not become a “stranger” with time.
It will also help to correct the path on which the developer is going. It could also correct misconceptions of the development which the client might have got.
Have a daily report
The daily report from the developer from India could be just an Email, updating about the current developments. Sometimes challenges will be encountered during development, these can be clarified with the client and solutions can be decided upon.
Have a hourly report
In some engagements it can make sense for the client in Germany to ask the developer in India, to give a short hourly report, which can be just one or two sentences, on what has been done in the previous hour.
Use common sense during requirement gathering
Sometimes it’s good not to always look at requirements from a technical point of view. Sometimes it makes more than sense to look at it from a business perspective.
One example:
——————————
Currently we work on project, where the client is insisting on a solution where he can measure the behavior of visitors to his premises. The current solution involves a plugin which does the calculations for measuring the visitors behavior. Unfortunately the plugin does not show the results in a manner how the client wants it. Now the developers are desperately trying to change that plugin, so that it works according to the clients requirement.
But in this case it would be better to look at the client requirement from a business perspective than from an IT perspective. By looking at the challenge from a business perspective it becomes quite clear, that the requirement cannot be solved by the current plugin, and that a individual programming of a solution becomes necessary which is not dependent on the current plugin.
If the programming of an individual solution would consume too much time and thus too much budget, then the decision could be made to try to get the best out of that currently used plugin.
——————————
The above example might not be the best one. But it shows on how the client side and the programmer side can sometimes fix their eyes on a solution which is based on their needs. The client wants to exactly see what the visitor is doing (business perspective) and the developer desperately tries to make this solution work via the plugin (technology perspective) which is available and also by configuring the plugin, so that it does what the client requires.
By using common sense (which can bring together the business perspective and the technology perspective) the client and the developer can speak about a solution which is feasible (i.e. can be developed with technology), is doing what it is supposed to be (i.e. measuring the visitors properly) and is also able to be developed in a specific timeframe (i.e. a timeframe which justifies the costs involved for the development and the subsequent benefit arrived from the programming).
Check in detail whether a requirement is implementable or not
Before starting to program it is also more than advisable to check, whether the task given by the client in Germany is implementable in that way or not.
Similar to the plugin example above, its always good to get a basic idea about the feasibility of the development part.
One example:
——————————
One client wanted to have a HTML5 plugin to be developed which would work on almost all mobile browsers. The issue here was that HTML5 is not a fully developed technology and has therefore many defects which sometimes cannot be easily solved.
For example, HTML5 plugins are not as fast on Android device browsers, as they are on iOS device browsers. The reason for this: Android is based on the programming language C. On top of that sits a Virtual Java Engine and in that the HTML5 plugin is executed. This long process makes the plugin very slow in Android device browsers.
In iOS device browsers, the HTML5 plugin is directly run on C, therefore the performance will be much better on iOS.
Only after several developments and customer feedback a possible solution was found. In the end, one HTML5 plugin was developed for the Android version and one HTML5 plugin for the iOS version. The system would recognize from which device (Android, iOS or WindowsPhone) the application would be called and accordingly the specific version would be handed out to the browser.
——————————
From the above example it becomes clear, that it is always a good advice to check the feasibility of the requirement and to inform in advance of possible advantages (in this case: Fast on iOS browsers) and disadvantages (in this case: Slow on Android devices).
Be open (i.e. openly say what is the challenge, do not hide it)
In the engagement model, which YUHIRO is pursuing, i.e. the client hires a developer full time and long-term, it’s not necessary for the developer to hide any thoughts regarding the developments (I would not say that it is required to hide any thoughts in other engagement models 🙂 But in our case it is really not necessary).
Let’s just take the example with the evaluation of visitors in the above example. As long as the client does not know, that a Plugin is used for the development of the solution, he (the client) won’t be able to understand, that another solution might be difficult to arrive at, because it would consume a lot of time and effort.
So once the developer tells the client openly, that a plugin is being used, so as to make the development easier, then it will be also easier for the client to understand why there is so much reluctance to completely change the development by the developer.
By being open, the developer and the client can arrive more quickly at a possible decision and subsequently on a solution which will solve the issue.
Think about long term solutions
Especially in short outsourcing projects, there is a strong tendency to go for “quick fixes”. These “quick fixes” include Hard Coded variables, Unnecessary Code, An Overload In Plugins, the list goes on…
In projects with German clients its mostly about solutions which can be maintained, expanded and scaled in the future. i.e. the solutions should be able to be maintained and additional functionalities should be able to be implemented even many years down the line.
Therefore short term “quick fixes” should be avoided and always the strong, reliable and scalable long term solution preferred.
This long term thinking should be always kept in mind when speaking to clients from Germany.
It would be also Ok, to openly ask the client whether “Quick fixes” are allowed in a specific case, or whether this is a long term project (Sometimes our clients have themselves clients which give very short term projects, in these, it might be helpful not to go for elaborate solutions as the budgets will be usually be very small).
Build to hand over
Another point which should be kept in mind is: Develop the software in such a way, that a third developer would be always able to look into the code quickly and he/ she would be able to continue where you left off.
This might not be always in the best interest of the developer (at least when looking at the short term effects: The Developer can be replaced easily). But when looking at it in a long term perspective it makes more than sense to “Build to hand over”. The code will be more readable, well documented and easy to build upon. Even for the developer himself who programs on it, it will be easier in the future. May be he/ she will be required to look into the very code which was coded by him/herself and might not be able to understand what to do, if not programmed in a way “to hand over”.
Not only for one’s own purpose is it good to build the software in such a way, that it is possible to build on top of it easily. Also the persons involved with the developer will get a very good impression of him/ her. He/ she will be seen as an expert who writes re-usable code. With time the developer from India will get a very high status.
The advantages do not stop here. Usually clients in Germany will have additional developers which will work locally on the software code developed by the developer in India. They will get a positive experience by using a readable code, instead of one, which is impossible to decipher.
Conclusion
To sum it up: Honesty, trustworthiness and openness are all very important when working together with German clients in long term engagements. Especially when developers are dedicatedly working only for this one client.
Furthermore the points mentioned in this text can definitely help to make the client-developer relationship stronger and foster a culture were world-class (or at least German-Quality-class 🙂 ) solutions can be developed.
Pictures: Flickr.com/ Downey/ Mann
The author: Sascha Thattil works at YUHIRO and supports companies from Germany to establish software teams in India. YUHIRO a German-Indian IT company, which provides software developers for IT companies, agencies and IT departments.
Schreibe einen Kommentar