It definitely does reduce the strength of the MAC, but it is okay if your security requirements require it. Keeping in mind that some generic birthday attacks already reduce HMAC strength to n/2 bits (IIRC), and SHA-256 has you down to 128 bits of security (with an online attack though).

Truncation is mentioned in RFC 2104. I quote:

5. Truncated output

   A well-known practice with message authentication codes is to
   truncate the output of the MAC and output only part of the bits
   (e.g., [MM, ANSI]).  Preneel and van Oorschot [PV] show some
   analytical advantages of truncating the output of hash-based MAC
   functions. The results in this area are not absolute as for the
   overall security advantages of truncation. It has advantages (less
   information on the hash result available to an attacker) and
   disadvantages (less bits to predict for the attacker).
   Applications of HMAC can choose to truncate the output of HMAC by
   outputting the t leftmost bits of the HMAC computation for some
   parameter t (namely, the computation is carried in the normal way
   as defined in section 2 above but the end result is truncated to t
   bits). We recommend that the output length t be not less than half
   the length of the hash output (to match the birthday attack bound)
   and not less than 80 bits (a suitable lower bound on the number of
   bits that need to be predicted by an attacker).  We propose
   denoting a realization of HMAC that uses a hash function H with t
   bits of output as HMAC-H-t. For example, HMAC-SHA1-80 denotes HMAC
   computed using the SHA-1 function and with the output truncated to
   80 bits.  (If the parameter t is not specified, e.g. HMAC-MD5, then
   it is assumed that all the bits of the hash are output.)