While many IT organizations embark on CMDB projects.   Few succeed.   Why?   The obvious answer is that their CMDB turns into a junkyard and cannot deliver any meaningful value.

Why does this happen?

The first part is that a lot of CMDB projects start out without a clearly defined problem that they are trying to solve.   Instead, they focus more on the supposition that ITIL says a CMDB is needed, and the vendors say a CMDB is needed, so a CMDB we shall have!  Or alternatively, they try to be the silver bullet for all the ills in the IT organization.   These projects are doomed from the start.

The second is that they often over complicate the CMDB.   Instead of populating it with just enough data to solve that original problem, it becomes a dumping ground for every piece of information that they can possibly dig up - e.g. doing SNMP sweeps of the network and dumping port or NIC card information in the CMDB..   Are you going to create a change request on one NIC card?  No.. you would do it on the server, so why have it in the CMDB?

A third problem is how the CMDB is populated and updated.   A totally manual approach is also a sure route to fail except in the smallest shops because nobody can keep it up to date, and even if there is a process, during busy times people will ignore it.   Dependency mapping technologies are also not the complete answer as they are not 100% accurate and can over populate the CMDB with junk too?   So what is the answer?   Probably somewhere in the middle.    At least identifying the key infrastructure components and the software that runs on them is a good start.   Your existing monitoring tools can probably tell you this to start with.   Maybe a network scan can also identify infrastructure that is not being monitored too.   But this information should be reviewed before its just dumped into the CMDB.

In summary then, if you don't want a junkyard in your company, consider the following:

1. Do you really need a CMDB?   What is the problem that you're trying to solve?  Is there another way?     Don't listen to the CMDB vendors here.    To a man with a hammer CMDB, every problem looks like a nail sales opportunity.   
2. Clearly define the problem and make sure that its agreed and the expectations are set. 
3. What is the minimum set of data that I can populate the CMDB to solve the problem that was defined in #2
4. How can I automate the data in my CMDB in an accurate way?   Even minor inaccuracy in the CMDB makes it a junkyard
5. How can I measure the benefits and costs of the CMDB to make it worthwhile?