“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
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
- Share
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.
From the perspective of a “user representative” (i.e. a process analyst), it can be invaluable to have the user rep there for any discussions between a developer or consultant and the end user. If discussions between the dev/consultant and the end user are occurring “offline,” as it were, the precepts of good change control are not being followed. For those of us tasked to document, document, document, it is crucial that we be involved in any interaction with the end user. It’s not because (most of the time) we don’t trust the developer or consultant, it’s usually because we don’t trust the end use. There’s a nasty tendency to lose sight of the big picture and begin asking consultants and developers for nice-to-haves and customizations that adhere to existing UIs (so they don’t have to undergo difficult process changes that might create efficiencies). Discussions about processes are one thing, but design discussions are an entirely different level of destructive to a project plan. We drive toward goals that are set by expense and time, so stop talking to the end user and adding more of both.