A few things of what I learned in the past years talking to clients.
Understanding my customers processes is essential for my daily work, especially when you build a tool that helps managing workflows. While the software supports transparency, communication and makes sure you follow a pre-defined process, you cannot do it without understand users problems first.
Make people talk and understand the why
Most of the times there are two different ways how a project starts. Either clients have thought of their processes in preparation or they are just “working the process”, but have no definition whatsoever. I usually start the same in both cases: Asking questions. Coming from outside the company there are no dumb questions. Before any code is written, you have to understand what you need to build, even if you have a solution in mind. Ask them what a typical project looks like, what they do and why they are doing it. Repeat what you understood in your own words. That helps you and your counterpart!
I brought together people from different departments at one table, who never have seen one another before. Sadly in bigger organizations this is common. Invest time to get to know every expectation, because you are the one who has to bring it together, go one step back and ask questions again. Every time I had the feeling that we are implementing something that simply makes no sense (or stands against the overall goal of the project) and withhold that thought it was a mistake!
Implement and show off!
I don not force myself to understand every detail and have a solution for everything. Most things you will find out on the way. As soon as I have the feeling that I have a good-enough understanding and can come up with some quick “aha” effects for the biggest pain points I start implementing things. Than you get into practical implementation and be sure that things that you had “totally defined” earlier are the ones that change first.
Depending on your development process and technology it might be easier to make changes on the go as you think. In our case I try to develop an application that is as flexible as possible, because companies are not all the same and their processes are different. That demands to draw a concrete solution of the generalized one you have, but you do not have to start over again for every project.
While you might be deep into the technology and architecture of your application, your clients are not. They just give comments on what they see. Therefore try to show them as much as possible and gather feedback. A positive side-effect is, that you automatically update people all the time and they feel more involved and have a better feeling on the overall progress.
Technology is often not the real issue
This is old news: change management is hard. People tend to have their own individual solutions that had been working for them for a long time. In my case they sometimes have to switch from a very flexible (but also very chaotic) system “sending emails with random people in CC” to a more organized (but more strict) system. Or they have an old legacy-solution that worked but is not maintained anymore. Technology can only help, but not always take over all the work for them.
Be transparent in communication (communicate why you do what you do), be open for questions (even if you have to answer the same questions over and over again) and make sure to lead to decisions but not force them on everybody. Bigger projects can have the threat that you will be pushed hard (e.g. to meet deadlines) and loose oversight of why you do build certain features. There are times when you have to go for the quick solution. But always be aware that in the end any high loss of quality will be a long-term pain and communicate possible effects!
photo credits: by Matthias Ripp