How does a person go from Intermediate Access Development to being able to take on a project or position like this?
-Thanks

Great question, Raymond. If you've actually completed all of my Developer classes and gone through the seminars and tools like the ABCD database, then you should absolutely have the knowledge needed to take on a position like this. These jobs are looking for someone who can build complete, reliable business tools - and that's exactly what those classes prepare you for.

The key now is experience. If you haven't already, start building full applications on your own from start to finish - forms, reports, VBA automation, solid data structures, all of it. That hands-on practice is what turns knowledge into confidence.

Also, since this is a role in banking, you should have at least a basic understanding of finance, risk analysis, and regulatory compliance. You don't need to be a financial expert, but you should be familiar with how businesses assess risk, interpret data reports, and follow governance processes. That background will help you understand the terminology and expectations you'll be working with day to day.

But honestly, if you've got the access part down, that's probably mostly what they're looking for. They can teach you the financial stuff that you need to know.

Thank you for the response.  I have gone thru all of your developer classes (and always look forward to the next class).

I've been developing Access Databases that perform various functions for work at the Nuclear Power Plant:
Work Order Planning and Scheduling (in multiple other databases)
Tracking Issues and Plant Status
Upgrading methods previously being performed manually in Word or Excel

I've always felt like the companies that develop systems being used don't have that "USER LEVEL" understanding and so we end up with all kinds of weird "work arounds" to the get system to do things we need... it's not intuitive and some things just don't make since.  I understand the importance of good system development and the need for good Form layouts, etc.  A lot of that takes time and knowledge of how the USERS work.

I guess I would ask, when starting with a new client, how do you go about getting all the information and support you need to ensure you're what you're building will work for the end USERS?  For the projects I've done, I've found I get very little support until it's time to roll the program out, then everyone wants to have their input and make a bunch of changes.

You're absolutely right, Raymond, and first off - awesome job going through all the Developer classes and applying what you've learned in a real-world environment like a nuclear power plant. That's impressive, and exactly the kind of experience that builds serious confidence.

What you just described - trying to understand the user's actual workflow and making the system intuitive - is the hardest part of building a good database. Learning tables, relationships, queries, VBA... that's the easy stuff. The real challenge is getting inside the users' heads and figuring out how they actually work versus how management thinks they work.

Back when I did consulting full time, I'd always tell the client: if you want a system that actually works well, I need to spend time watching your people work. I'd walk through their process with them - whether that was scheduling, order entry, billing, or inventory - and take notes on everything. Sometimes it was a couple of hours, sometimes a couple of days depending on the size of the project and the budget. But that's what allowed me to see where the inefficiencies were, what pain points they had, and what they were doing manually in Excel or on paper that could be automated.

You're basically acting as an interpreter. Your job is to take the messy, often poorly-defined workflows and translate them into something clean, efficient, and database-driven. And you're absolutely right - often nobody wants to give you feedback until the system is "done," which is why I always built in early demos and iterative prototypes. I'd say, "Here's a rough version - tell me what's wrong with it now, before I build the whole thing wrong."

If you haven't already, check out my page on advice for consultants. Even if you're not working freelance, it has some useful tips on gathering requirements, managing expectations, and staying sane when clients are vague.

What you're doing is exactly what separates an average database from a great one. Keep at it.

Great. Now I have to add this conversation to the "advice for consultants" page. LOL.

Thank you for the responses, this is very encouraging.

Learning Microsoft Access (predominantly from your classes) has been one of the best tools added to my career which helps myself and others with their jobs.  It is a completely under-rated tool that not many people know how to use, but is significantly better for so many tasks typically done in Word or Excel.  Part of me really wishes more people would learn to use it and apply it, while at the same time... it's been one of those things that's really made me stand out when it comes to solving problems and implementing robust solutions that work.  So many thanks are owed to you for the programs you create.  :)

Yeah, you hit the nail on the head. Access is one of the most underappreciated tools in the Microsoft ecosystem, but for the people who do learn how to use it properly, it becomes a real career booster. I've always said it bridges the gap between Excel and full-blown software development better than anything else out there.

I really wish Microsoft would give it a bit more love - especially in terms of web integration. If they could finally make it easy to deploy robust Access apps online without needing a whole SharePoint or Dataverse stack, that would be a game changer. I've been working on some ideas to help bridge that gap myself, but it's still a side project for now and definitely not turnkey yet.

But in the meantime, guys like you who know how to use Access well are always going to be valuable in the workplace. Keep doing what you're doing.

Raymond , In my experience, most manufacturing plants operate on a reaction principle.  If you can get them to sit down beforehand, they are still only thinking about the unit that is down or the motor that caught fire last night.  It is difficult to get them to look forward toward something that isn't broken.  The plants I have worked in know this of themselves, though.  

When starting with a new client, you might include a specified and finite amount of start-up time in the quote and a happy-happy billable rate for "extras".   Make sure it is enough that you are happy to be doing extras but also happy if there are none.

When presented honestly and directly, many of the clients should be understanding.  Your database probably won't be the first item they have bought, only to completely rework it, to fit it into their system.

Matt Thanks Matt.  I am interested in learning how to venture out with database development.  I have learned a lot from taking Ricks classes, Microsoft Templates and doing many projects at work.  There are not a lot of database references to assess my knowledge and skills as to what is needed or used outside of my field.