How To Organize Your Project Needs For Our Discussion
This page is intended for people with whom I have an initial meeting coming up to first discuss their project.
Here’s some ways that I encourage people to think about their needs, in preparation for those first discussions about their project:
1.) Depending on how long the list of what you need is, I encourage people to break things up into three (or optionally four) priorities: “Must have” (the database is useless without it), “Will need eventually” (The database is useless long-term without it, but you can survive temporarily without it), and “Nice to have” (would be nice, but not a problem if you have to do without it.) You may also add a “Blue Sky” wish-list category: absolutely lowest-priority, “maybe someday” brainstorming, things you dream about but understand may not be realistic for technical or budget reasons.
This sort of organization helps with budgeting if it’s a long list, the less important stuff goes at the end so it can be cut if things go too long.
2.) Ask yourself, “What is this doing right now that I don’t want it to?” And “What do I want it to do that it’s not doing right now?”
The answers to those questions are the best way to figure out what you need… I know that seems obvious, but some people don’t think of it in those terms right away.
3.) Think in familiar, plain terms of what your business needs you to accomplish to get your day-to-day work done.
A lot of people who have a bit of experience with a database try to “think like a computer”, they try to think in terms of what a database can do for them in quasi-technical terms, trying to imagine how the database will work “behind the scenes”.
I discourage people from thinking this way. Instead, think in terms of paper forms and filing cabinets, reports, rolodexes, etc., if that’s easier. Just think about how you would describe whatever tasks you have to get done in your workday to someone who wasn’t a database expert. Let me be the one to figure out how to automate things and translate them into database terms.
Of course, some people have enough experience with FileMaker to really understand it under the hood and specify the database they want in more technical terms—if that’s you, that’s fine, too.
But there’s no need to try to “reach” for that if you’re not 100% familiar with the technology and the insides of how FileMaker works. The computer is supposed to “come to you” and have things work in terms you understand, and I’ll worry about bridging the gap between your concept of how your business runs and what FileMaker’s technical needs are, in order to make that happen.
