The macro is probably being blocked by security  settings in the
user's desktop. Try getting the user  to change  his/her macro
security settings  in Word from High to Medium. The user should then
see a warning when opening the document asking whether to run  the
macros in it.

You can't override that setting from SharePoint. There are a number
of possible workarounds, including putting the macro code  into a
template installed in a trusted location on the user's desktop
computer, or signing the code with a certificate recognised by the
desktop.

No, it has nothing to do with security. The Word document must be
uploaded as a .dot file  in order for users to see & run  the macros.

I'm glad you got it to work. Without more understanding of how the
macros and documents were stored and used, I can't say exactly why
making the document a .dot file  fixed your problem.

And in fact, it's best practice to put macros  into .dot files. Many
people regarded it as a step backward when Office 97 enabled macros
in documents.

But I stand by my belief (based on limited testing) that if you
upload a document containing a macro into SharePoint, nothing in
SharePoint itself removes or disables that macro if you or another
user downloads the file. (Of course, it's possible an anti-virus
product installed into SharePoint or the client desktop  would do
that, apart from security  settings in Office.)

What I said was right for a document in a library. But for a
document uploaded  as the template for a content  type in a library,
something in the process on the desktop  that turns it into a new
document disables any macros  in it. They are still present, and you
still get the warning when the document is first opened if security
is on medium, but even if you say "enable", or have security  on low,
they are (seemingly permanently) disabled in the new document.