Tag Info

If they really are reusable methods / classes, you could write them into a small number of 'Swiss Army Knife' libraries. We do this quite often at my company; we call them framework libraries:
Framework.Data - Utilities for working with database queries.
Framework.ESB - Standard methods for interacting with our enterprise service bus
Framework.Logging - ...

Change.
Especially, unmanaged, uncontrolled change are a huge risk. You can embrace or control change but don't ignore it.
Edit: Extended answer with example (as the OP asked for one)
As I said in the comments, software is abstract, especially to people who don’t work writing it. With something physical it is easy to see the progress and barriers to ...

The three points you listed seem fair:
It is a fairly important project so it has to work - a C# solution would not be as stable or work as well as the existing a VBA-based solution.
Indeed, later, you tell: "I would like to take this opportunity brush up on my C# skills as I am currently not as competent in C# as I am VBA" (emphasis mine).
In other ...

Assumptions are the biggest risk.
You assume that you know what your team is doing.
You assume that your team knows what they are doing.
You assume that your team would tell you if they no longer know what they are doing.
You assume that you're doing what the customer asked for.
You assume that what the customer asked for is what the customer wants.
You ...

What you suggest is fine from the point of view of the Systems Engineering purists.
(There will be a few Agile devotees who think its all way overt the top... and you should just get out and do stuff with the usual reviews, etc).
However, you need to take into account what you are doing, and who you are doing it for.
Doing a project for yourself is ...

I disagree with the accepted answer for many reasons.
In my experience, when I see "miscellaneous" libraries like the accepted answer, they're an excuse to reinvent the wheel (or not invented here(NIH)) - a far greater sin than violating Dont Repeat Yourself (DRY).
Sometimes violating DRY can be a reasonable compromise, it is better than introducing tight ...

You need to keep a close eye on your dependencies on third-party components, particularly if they are specialized ones that may have very few other users who are doing exactly what you are doing, and that may be difficult or impossible to replace.
If there are any bugs or gaps in the features you need for your system, you will be at the mercy of the ...

I would support going to C#. Others have covered your points very well, so I won't rehash what they've said. There are definitely a lot of good reasons to stick with VBA.
However, one of my employers did an impeccable job at creating meaningful documentation. So much so that design decisions were actually written down with justification - if only all ...

Since this could be a long ongoing project, I want to get the structure right from the beginning
It's pretty tricky to know up front what the correct structure for a collection of code should be, especially where the project is essentially an R&D effort (for which read: you haven't personally built such a system before1).
So don't bother; instead, ...

I'm not sure if the customer really "made a mistake": They had a solution which started with a very small initial investment, which could be maintained in-house, which grew together with their reqirements and which just worked. If the current solution "works for the scope now", the argument that Access is completely unsuitable for a project of that scope ...

Organizations that treat talent (not just programmers) as resources that can be swapped in based on job title. This is really quite common, although it's almost never as 'coarse' as my description. The common manifestation is: We're running late, if we add these 5 guys who have never even seen this project, I'm sure we can pull it off!
Orgs that think it ...

I hate to say it, but your arguments just don't hold water.
Unit testing.
This has been a solved problem for a very long time. There are many Unit Testing frameworks out there. Pick one. You should have been doing this already. I recommend ours, because it integrates into the IDE and provides other great features.
Source control
This one is a bit ...

People & Communication
The programmers need to be able to program. The analysts need to be able to communicate to the customer in a way that pulls out what the customer really needs. Then the analysts need to be able to clearly communicate this to the programmer.

I think the list should include:
The non-technical requirements (there was such a document, right?)
The technical requirements
A "decisions" document (if there was one) explaining why some decisions were made over others. This might already be in a different requirements or architecture document, but we usually do this separately for Big Decisions.
The ...

New, new to us, and known technologies used in new ways.
You can minimize these risks by doing proof of concepts apps in the design phase. These small projects will also serve as a communication tool in the future on how something should be done.

anything you don't understand is a risk factor; this includes things that aren't specified well and things you've never done before and things with insufficient documentation etc.
mitigate the risks by planning for and doing - up front - investigation and prototyping (a "spike" project in XP terms)
be prepared with a fallback plan if the initial direction ...

except for the fact that it would alter properties and input variables to functions/voids inside the Business Logic class to provide a different set of data for another completely different user
That's just a design mistake. Nothing more.
Fix it first.
Then simply share the business logic between the two web applications.
Should we maintain two ...

I have never been a fan of including existing projects that belong to other solutions. There are too many variables where making an edit to that project for 1 solution completely breaks something in another solution. Then by fixing that problem you end up breaking the original solution. Lather, rinse, repeat.
When this kind of dependency leaks into multiple ...

Some "Formerly Commercial-Only" Projects
The IntelliJ IDE was originally closed-source
A lot of Id Software games, old (like Wolfenstein 3D) and not so old (like Doom 3)
A lot of projects released as open-source by Sun Microsystems started as closed-source experiments or products:
the JDK and JRE themselves,
NetBeans (interesting crossing history lines ...

Stick with one TFS Team Project, having multiple becomes a pain when trying to upgrade and has some limitations when it comes to cross team project work items. Instead you should be making heavy use of Areas and Iterations.
Split your VS Solution into multiple solutions, one per major application. This will speed up local builds a lot, as well as the ...

For small bits of code -- say a single class with no dependencies -- we tend to just copy and paste the code into projects. This sounds like a violation of DRY, and I'll admit it can be at times. But over the long term it has been much better than having some sort of massive, multi-headed commons project for a few reasons.
First, it is just simpler to have ...

You'll want to read up on the term "technical debt".
If time & resources permit, it is much better to do any code clean up immediately while the problem is fresh in your mind.
Leaving clean up as a to-do item for others can turn into a very bad habit. These to-do items are rarely addressed, and after many years can lead to such a horrific mess that ...

It is 100% OK that your customer (in this case your Dad) doesn't want to bother with interviews to gather requirements as interviewing is but one method useful for requirements elicitation.
A few methods immediately come to my mind in this situation. If it were me, I'd probably pick and choose pieces of each of these to figure things out.
ARM - ...

Some people use Maven or similar solutions that automatically download libraries from various repositories as needed. It may be convenient, but then you're dependent on repositories maintained by some 3rd party. Getting some less popular libraries updated may be sluggish, and of course, most commercial libraries aren't available in public repositories.
...

Qt was originally a commercial project by Trolltech, then when they were bought by Nokia it was released as a dual (commercial/LGPL) project.
The value to Nokia of having it as the default GUI toolkit of programmers all over the world was more valuable than the extra license fees from a few commercial customers ( or it would have been if Nokia could ...

First point of fact is that the solution file pretty much magically becomes a MSBuild file when MSBuild executes it -- which is what happens when you build the solution in visual studio. In addition, all those project files are just msbuild files managed by visual studio. In fact, the project files handle most of the real dirty work here no matter if you are ...