Proving the Concept with Access
Committing to a major custom software development project is fraught with risk. Reduce that risk by prototyping in Access first.
Let's say you're an IT director with a $100,000 development budget. Four departments come to you with a project request. Each project will require about $100K to develop using a traditional, compiled language approach in Java or .NET. Which do you choose?
You could ask each department to make their case and choose the most compelling one. The risk you run there is that the project gets awarded to whichever department is the best at preparing presentations, not the project that is most valuable to the company. Even if all departments are equally adept at presenting, you will still be choosing based on future projections of how the application will be used. Anyone who's ever completed a custom software project can tell you some of the most important features end up being those that were not even imagined at the outset.
Option E: All of the Above
With this in mind, a better option is to implement a minimum viable product (MVP) for all four projects. Let the projects evolve over time. Chances are one of the projects will prove out its value above the others. At that point, you can commit additional resources to that project to bring out its full potential.
Access excels at prototyping
Microsoft Access is a rapid application development environment. Development costs for an Access application are much lower than with an enterprise-level custom software project. Chances are that you can use that hundred-thousand dollar budget to implement all four projects in Microsoft Access.
Know its limitations
Access does have its limitations. If your project is entirely web-based, you'll want to use something else from the start. But if it is a desktop application, you will almost certainly be able to implement all of your required functionality. And if you use a client-server database like SQL Server to store your back-end data, you sacrifice almost nothing in terms of scalability (the limiting factor is the skill of the Access development team).
Making Access part of your IT strategy
Access is the business application that many IT departments love to hate. It doesn't have to be that way, though. Access can serve an important role in an IT strategy as long as it's intentionally included in that strategy. Where companies get into trouble is when Access applications are ignored until one day they're "too big to fail." That's when the pain starts. Refer to my article, MS Access Risk Management, for more information on that particular topic.
