How do you eat an elephant?

One bite at a time.

In this case, I am thinking about complex requirements customers have. The first stage in dealing with complex requirements like: “I want main line items on my PO with subline items related to each of those main line items.” is to start designing a conceptual solution in terms of objects.

For that simple statement, Access has many tools with which to approach the concept. Do you want to use a form with a subform with another subform embedded into that? How will the user want to maintain main line items and sub line items? Usually there are use cases you can start with that the customer will be able to give you.

These use cases can range from simple to complex. I usually try to start with simple use cases to test the major component possibilities and concepts to see how simple I can make the system. I try to utilize native behavior of Access when possible and not overcomplicate or fight the ways Access works.

It’s unhelpful to try to provide quotes or pricing until you at least have an idea of how to solve the problem, although sometimes you don’t have an option. The customer will need some kind of quote or ballpark at least to help determine whether the functionality they want is feasible. You want to be able to build the simplest solution as rapidly as possible to figure out what will work and hence what price you’re willing to provide the functionality for.

On the flip side. Knowing the final outcome the customer wants and if they are not defining the interface they want, you have a better chance of finding their budget comfort zone and then seeing if you can tailor a solution to fit that budget. This is backwards of the way most people handle the quoting situation, but can be the most effective at meeting the customer’s budget for a satisfactory amount of effort on your part. This requires a different kind of requirement though, like the outcome the customer is looking for rather than the features they think will provide this outcome.