â€œYou donâ€™t need to talk to the users – Iâ€™m the user representative.â€
â€œBut talking to the users will help us make the software better!â€
â€œTalk to the handâ€¦â€
When we hear this, we cringe. And thus begins a discussion on which the fate of our project dependsâ€¦
Weâ€™ve dealt with user representatives who believed that they knew better than the users. Weâ€™ve dealt with people afraid to let consultants talk to the users, because the consultants might mis-set expectations and create bad will when the development team fails to deliver. Weâ€™ve dealt with over-protective information-hogs, who donâ€™t want to telegraph their moves, for risk that they might lose control of the project, or lose credit for the project to someone else.Â How do we get past these barriers?
The problem is lack of trust
All of these archetypes have something in common – a lack of trust. In themselves, their organizations, and/or with us. This is where good consulting makes all the difference in the world. If we fail to get past the user representative, we will never deliver what the users truly need.
Occasionally, we run into the â€œnot enough timeâ€ and â€œitâ€™s too expensiveâ€ arguments against getting time with the users. In our post about why incremental delivery is good, we touch on the cost dynamics of developing software.Â In our post, where bugs come from, we talk about how there are orders-of-magnitude benefits to avoiding mistakes while gathering requirements relative to discovering them after deploying software. When we canâ€™t get input from the users we increase the likelihood of gathering the wrong requirements. And we wonâ€™t know that they are wrong until we get feedback from the users. The later this happens in the process, the more it costs to fix. When half of all enterprise software projects fail, the last thing we want to do is make it more likely that weâ€™ll build the wrong stuff.
Building trust is the key to getting around the roadblocks and getting to the users.Â Louis Rosenfeld wrote a great post last year – Why Should We Be Trusted?. Make sure to check out the comment thread too – especially the â€œfour step planâ€ proposed by Jason on July 5th. He adds more details, but his â€œthings Nâ€ are
- Be clear about what [we] do
- Be critical of ourselves
- Do it
Dale Carnegie teaches that we can never win an argument. He also teaches that we can persuade. Depending on who weâ€™re talking to, that may require logos, pathos, or ethos. We can present logical arguments or anecdotal data. We can apply our gravitas to be compelling.
Every conversation will be different, but always with the same goal – engender sufficient trust to get access to the users.