You already have two correct answers; you can't literally have a constructor with parameters in VBA.
Oorang's workaround is basically right - have a separate "init" method. When I do take an object-oriented approach to something in Excel/VBA, I prefer to hide both object creation and init in a regular function. So I'd have mkFoo(parm) and call it to get a Foo instance. mkFoo() would create a New Foo instance and call Foo.init(). If you only ever create instances that way, you don't need to check if your instance has been initialized over and over again.
Speaking of Excel, you could relocate the Foo class into a .xla add-in and make the class PublicNotCreateable. The Public Function mkFoo(parm) could reside in a standard .bas module in the add-in and therefore called a bit like a static class in C#. This forces client code to use mkFoo as the only way of creating a Foo instance. No doubt there is a MS Access analogy to Excel's .xla add-ins.
If you're really trying to be correct and not supply an object with a maybe-now-dangerous init() method exposed, you can have an IFoo interface (with no init method) that is implemented by Foo. Then mkFoo() returns an IFoo, and any users of the actual Foo never see the init() method at all.
Of course, now you have a bunch of modules just for Foo - one for IFoo, one for each actual Foo class, and one for your "Foo factory" function...thus my comment that this is one of many reasons why OOP in VBA is a PITA, even if it is useful sometimes.