I have been in meetings recently where some consultants, tasked with building an enterprise software solution based on a FileMaker solution I built, keep asking, “What are the fields and data types the system is tracking?”. Various people involved ask me over and over for lists of fields and tables, and I dutifully give them lists of fields and tables. They ask me for sample data, I give them sample data. Invariably they keep calling me back to meetings. “We looked at the lists of fields and tables. We looked at the sample data. We looked at the requirements documents. So, what are we supposed to be doing?” (I’m paraphrasing but you get the idea.)
Let’s leave aside for a moment that calling a meeting with a vague purpose is also an effective way to waste time. Focusing on details like the actual data too soon in the process is the wrong approach. Clearly, fields are important: the data itself is the heart of the system. But solution development is so much more than this. The data or content is only one part of it. It’s tempting to start the process with the concrete parts that we can write down in tidy lists. It’s satisfying to us as developers because it lends itself to being easily quantified. However, solution design is abstract too. It’s about discovery, observation, curiosity, and problem-solving.
Rather than chasing after bits of data, they ought to be taking a step back and asking, “What do the users want to do with this solution?” Then they would uncover so much more. They would get all the fields they need in the course of talking–and actually listening–to users, not just mindlessly recording their words into a requirements document in a hollow fashion. They would discover what users actually want to achieve, not just what pieces of data they are tracking. A database is not just a place to dump data. What’s the use in that?
These patient users in a corporate environment have often been given different enterprise-level tools over the years. Many many millions of dollars are spent on developing and customizing these products. Dozens of IT personnel work on and manage these systems. And yet, these tools still fall short. Very short. Users hate using them. They don’t deliver as promised. There is no flexibility. Changes and improvements take months, sometimes years. They often fail to give users the tools to not just capture the data, but to analyze it and work with it in a meaningful way. Mobility is zero to none.
FileMaker can do this, but it’s not just about FileMaker. It’s about an approach to solution development that cares not just about putting in development time, keeping developers busy, keeping the department going and justifying its budget. Or justifying a consulting contract by scheduling meetings and doing a lot of talking. It’s about starting by discovering what the thing you’re building is supposed to do, what people are expecting to get out of it, how they want or need it to make their work easier. About designing a system and adapting the tools to fit a need, not the other way around. About being inspired by the user’s challenges and helping overcome them.
Requirements gathering is not about making lists of data and structuring the system in the way most convenient for the developer. I wish large corporations would stop for a moment and think about what they’re doing. I sometimes feel they are missing the point. Users are exhausted with, over and over, trying to help consultants develop new solutions to problems that weren’t solved with the old solution they helped develop when that was new, five years previously.
There are some real challenges in developing very large systems. These issues are not to be taken lightly. And users don’t always know what they want, either. They change their minds, give incomplete information, or try to do your job for you. In short, they’re human. At least some of the big guys seem to be on the wrong path in terms of delivering useful, integrated products that work effectively though. As a developer for small- and medium-sized workgroups, I’m grateful that I have the opportunity to work closely with users and be involved with them in a meaningful way. There’s no greater reward than someone coming back to me later and saying, “There’s no way I’d be able to do this without the solution you built.”
By some accounts, more than three in five IT projects fail. One of the ways they fail is by not giving users what they need, right from the beginning. It seems like we should, by this time, have the tools and learning to do things better. Not every solution has to be innovative, but it surely ought to be useful to getting work done and not an obstacle to it. Users by and large have been trained by the millions of specialty apps out there to expect better too. Before we get caught up too soon in lists of data, let’s ask them what they want to accomplish, what their challenges are, what they wish for in their work.
After all, don’t you wish someone were listening to you too?