The damn user doesn’t know what he wants!
The famed “User” is not to blame. It is easy to direct anger and frustration towards the customer of a software product. What needs to be understood however is that maybe the way you work is too confusing for the customer.
We need to be fully aware that customers can be scared of ICT. They are unfamiliar with what can be done and are scared to ask for it. When the relationship has commenced and the project has been running for some time, they become more comfortable with asking for things and have over time developed expectations. Expectations that we as ICT have set during our communication with the customer.
What I have been seeing as a trend lately, are many movements in software development to integrate “the user” or clients into the development process more. It has been unsuccessfully bridged with system analysts, which are in general not speaking user language or developer language well enough to give the clients what they need.
Take scrum for instance, here is a prime example of how to confuse your user. It talks about product owners, scrum masters, sprints, story points, etc. I know many developers that do not fully understand these concepts and people who adopt scrum expect their clients, managers even, to understand what they are doing. It is a level of abstraction which is needed I believe, but it is only effective if everyone is on the same page.
What I propose is a training session with the “User” or client when a project has initiated on how software projects are run by your team. We all know that formal, traditional project management techniques do not “fit” well with software development. We are not building a bridge from a concrete, set in stone plan. We are molding a statue from the visions of various stakeholders which changes over time to fit their needs. We as software professionals fail at his in my opinion, but we are learning fast.
The training has a two-fold effect. It will assist the customer in understanding how things work. They should be able to talk a similar language after the training and know what “Velocity” on your project actually means. I believe that communication is our biggest hurdle to conquer in any business environment. The second fold addresses specifically this issue. It lays out a platform for candid communication where the user can inquire freely without reprimand or aggression. There are no emotional attachments and expectations from which communication can be hindered, well at least there are far fewer than later in the project.
Setting the expectation with the client early that you will be interfacing with them on a regular basis will go long ways into getting buy in from them. It will however deteriorate if you have nothing new to show them at the end of each sprint. Having candid open communication during projects is crucial to a happy customer. I am digressing however.
To sum up the concept. If you are working scrum or some other methodology, even custom made, you have a certain way of working that works. Why not streamline that way of working by training your clients. They will almost certainly not know your way of working. Teach them, so that you can both be more effective. Remember that the one doing the work or creating the content, chooses the way that works for them. Others should leave them to get the job done and assist them in being more productive. How can someone who does not know the process assist someone else?