Meeting Requirements vs Meeting Needs

A while ago I was meeting with a prospective client who told me about how much trouble they were having with their collaboration efforts at his company.  We talked for a while and I was shown a list of requirements for what the platform should have.  I took that list and then went to go speak with a few employees in the organization to find out why they weren’t using the tools if the requirements were met.

One of the requirements was to have the ability to collaboratively edit and create documents so I go to the first employee to ask her about it.  She says, “sure you can do that in the platform but it requires some knowledge of HTML and wiki markup language to know how to actually work on a document with someone.”

Another requirement was to have the ability to create private groups for teams.  Again, I go to another employee to ask him about it. He say, “oh ya, you can create groups if you want but then you need to wait at least a week before that group will get approved, by that time we no longer need the group.”

Finally, another requirement was to allow employees to motivate and encourage each other by giving each other badges or “kudos.” Again I go to another employee and ask them about this and the response I got back was, “Yes, you can assign badges and give “kudos” to coworkers but the problem is that you need upload your own badge and then tinker with it so that it looks decent when it’s uploaded not only that, there is no context around what the badge is for or what the “kudos” is for.”

Oftentimes those who develop requirements for collaboration platforms aren’t the same people who are going to be using them. Requirements are usually put together in the form a big list which someone can go down and check off.  Then if any issues arise in the future such as employees not using the tools, those who developed the requirements can say, “we checked off everything you asked for, it’s not our problem.”

This is a situation I have seen many times and the problem is that many of those responsible for these initiatives aren’t looking at the big picture, they are purely focused on the technology requirements instead of actually understanding the problems that these technologies need to solve and how employees are going to use them.

This is a very costly mistake to learn but you can avoid this very expensive lesson by doing the following:

• Develop your use cases by speaking with employees at your company in various departments to get their feedback and perspective.  This is research.
• Make sure the team leading this effort is cross-functional, meaning it’s not just a bunch of technologists working on a product.
• Communicate the updates and developments to employees, don’t wait for everything to be done.  Communication is key.

That’s all you need to do, three things which are mainly focused on communication.  This is a classic example of bringing together both the needs of the business with the requirements of the technology.