How can we develop an IT change management program?

Hmmm. Well, this is not a subject that can be easily addressed in a simple response forum...in my opinion...since I would need to know what processes your organization already uses, what information is already available, etc...but I will give my two cents anyway.

Change Management is an ongoing process. It requires a commitment by the organization.

The basics needed are:
1) a means of submitting changes for approval
2) an approval board
3) authority to manage this process

In a small organization, this could even be paper based, but I think this should be electronic for most places. In the beginning, the requests should detail at least what system is changing, what the change is and when the change would happen. They should be centrally available and also be marked as completed when done (or other status as appropriate)...including completion date and time. As you go through the process you should change the list of required information as appropriate to your organization.

The approval board should be comprised of individuals in your organization who know the systems. These should be people who might recognize the system that is being changed and understand that it has impacts outside of the change...and to what. This should be a relatively small number of key people. The decision of the board has to have weight (so if they say no, the change doesn't go)...this is the commitment by the organization part.

As your processes mature and grow, then there are other things to consider:

A CMDB - this is a configuration management database. It should contain all of the systems (hardware and software), their owners, what they are related to...right down to something like server X is connected to switch b in closet y. The intent here is to identify impacts of changes without having to rely on the memory of a small group of people. The people are still involved, this just makes impacts easier to identify. Then this needs to be maintained over time...so changes to the CMDB need to be part of the change itself.

Incident/Problem Management and Call tracking - If you don't already have incident management or problem management processes, you should. If you do, then you want to make sure they are integrated with Change Management. They should use the same CMDB. This allows you to see the ripple effect of changes and allows the people researching problems to identify what changes have happened.

Of course, you could start with a CMDB if that is appropriate to your organization. You may already have this as part of your incident/problem management or call tracking systems.