This is a service problem. Some service is halting the shutdown process. And until we know which one, there is nothing to do but speculate.
So, how to start solving it? We can start by trying to identify the service. After you experienced one of those prolonged boot situations, be patient. When it finally shuts down, boot normally and then type on a terminal:
$ journalctl -rb -1
The above command will display the logs of the last boot in reverse order (with newer entries at the top). Paste the first 20-30 lines or so on this thread.
@Bill_MI, I don't advise changing that setting. For two reasons: you are just circumventing the problem without solving it and, what's worst, you are doing it on the wrong setting 
The DefaultTimeout{Start|Stop}Sec= and DefaultRestartSec= options govern unit start/stop timeouts globally during the whole of your runtime. And you wish to leave them at their sane defaults since some units could conceivably require more than your proposed 15s to start or stop and you would just be timing them out instead. Any change to these values should be only made on a per unit basis, on their respective unit files. Both service and non-service units have timeout options that override these global defaults and that can be defined on their respective sections of the unit file. So I could, for instance, configure the avahi-daemon.service to timeout at 10s when starting and 15s when stopping. What I wouldn't want to do was setting this for EVERY unit. Which is what you are doing.
The more appropriate way is to enable an hardware watchdog. There are two global watchdogs available. The one that interests you is ShutdownWatchdogSec= which you can set on your systemd.conf file for 15s. It will have the desired effect and will only affect unit stop operations during the system shutdown or reboot, not during runtime.
However, be aware that ideally you want to first identify the source of the problem. The unit that is hanging. Depending on what unit this is and what can be done about it, if nothing can be done you can set an hardware watchdog on that unit, or set its personal timeout as explained above, and that will be a better solution than setting it globally. However, more often than not identifying the unit should be enough to understand what is hanging it.