To avoid repetition, CIOs, VPs and Project leaders are collectively referred to as leaders.

• Know your people: Information Technology departments are usually loaded with bright, dedicated introspective resources. Inspire them and  improve their productivity by understanding their goals and meshing them with the organization's goals. Interview them with a view to understand their goals and not just their skillset. Re-interview them especially if you are walking into an existing department. Know and ask about their spouse, children, families and be genuinely interested and curious. They will be loyal to you. When you ask your people to stay late, it is not the project they think about but the effect on their spouse / child / family that they worry about.
• Use your people: Bring in consultants to solve technical problems but also listen to internal resources. Under  pressure of deadlines, many leaders ignore the advice of their own people and later on when the consequences of these decisions hit home, they look for expensive outside resources for "out of the box" solutions. Many times, you can stop cash from flowing "out of the box" by consulting with internal resources before going outside!!
• Focus your people's energy: Do not change priorities rapidly and reassign people under pressure from users. Software development is a creative process and like all creative activities needs the ability to focus. Rapid switching of people's focus is inexcusable and unforgivable. Even if your people forgive you for switching, the projects will suffer. For e.g. If your star programmer / developer is working on a project, shield him or her from routine maintenance requests on another project he had delivered in the past. Use a ticketing system and helpdesk analysts as first responders to help requests instead of wasting the time of your star resources.
• Celebrate your people:  Get Starbucks or bagels or have potluck parties to celebrate milestones. Generate team spirit and let them know that you care. IT projects have long gestation periods and even after they go live, support tasks leave no time to celebrate, hence it is really important to celebrate stages. 
• Invite inspirational speakers or stand up comedians: There are many organizations like toastmasters which can provide you with inspirational speakers. Invite one every quarter to keep up morale. If you are skeptical of inspiration, get a stand up comedian, let him make fun of you. When people laugh together or hear an inspirational speech, it generates an energy that will improve productivity. If you are in Los Angeles, check out: http://www.theatresports.com/corporate.shtml
• Create a bulletin board to compliment achievements: No matter how modest your people are and how old fashioned bulletin boards are, everyone loves to see their names in print on a compliment on the board. When people from other departments and visitors see this board they will know that this department is proud of its people. Caveat: If a customer compliments one of your people, just print it and put it up on the bulletin board, do not add your comments. The leaders at one company added their own comments for e.g. " Johnny's example should be emulated by everyone" to customer's compliments. This has an adverse effect at worst and at best muddies the customer's compliment!!
• Be quick to decide but slow to change your mind:  Ask a lot of questions till you understand all aspects of  software design and when you have all the information then decide quickly. This not only is good technically, it also inspires confidence in your people that you understand things at the technical level. If a design is completed and in production, be very careful about changing the design. For e.g. I was working on a project where a web application was delivered using Microsoft .NET + IIS + Oracle technology. A new developer with JAVA + Apache + Oracle skills was hired. A decision was made to use JAVA + Apache + Oracle this caused the developers to spend a lot of time redeveloping the application instead of on delivering additional features.
• Be the first to receive bad news: Make yourself approachable and accept bad news gracefully. Many IT resources do not feel comfortable bringing bad news to their leaders. You will look out of touch (incompetent) with the situation on the ground  if you are approached by non-IT people with IT problems.
• Your people will do what you inspect not what you expect: Software development is a challenging engineering field because the technology for software development changes rapidly and the requirements keep growing. Unlike other engineering fields like construction, it is difficult and inefficient to have all the specifications down before development. Under this constraint, it behooves leaders to "inspect" your people's work to make sure it meets expectations. It is more effective to inspect the actual deliverables and the user's reactions to the deliverables than the status because it allows your experience and intuition to judge the situation. Regular checking of helpdesk response times, repeat requests for the same issue will show the inefficiences in helpdesk processes and help fix them. 
• Encourage your people to notify the next in line about upcoming tasks: Imagine a relay race and picture what happens if the runner with the baton hands it over too early or too late. Most IT projects have your people working on different pieces and handing them off to the next person on the chain. Notifying the next person of delays or early starts of their tasks will reduce the time they have to spend in ramping up for their tasks.
• Encourage structured peer reviews: Most IT departments waste a lot of time fixing bugs that could be avoided by simple peer reviews. Carefully structure peer reviews for every project because  you are essentially asking one resource to criticize the work of another.
• Pairing a strong resource with a weak one WEAKENS BOTH resources: This goes against the general belief or rather hope that a weak resource will learn from the strong one.
• DO NOT give more grunt work to the most productive resource as a reward: Once I rescued a failed web application project and when it was delivered, my boss turned to me and said "Guess what happens when you do a really good job" .... "You get more of the job!!". He meant well and wanted to inspire me with more responsibility but unless done carefully, this could be counter productive. Good resources are way more productive than average ones and to keep them from burning out, give them only the toughest problems. Keep them away from the simple problems as much as possible. Maybe you can have them mentor average resources instead.
• Listen to your people: A lot of good ideas are expressed in the relative anonymity of the water cooler instead of the conference room for lack of trust. Create an anonymous BLOG / discussion board for your people to express their views and check it often. Build trust slowly by acting on the contents. Soon your people will trust you enough to speak in the conference room (Otherwise, move the water cooler into the conference room ;-)
• Roll up your sleeves: Software development has changed tremendously in the past 5 years. Developers have increased effeciency by sharing knowledge on blogs, websites and discussion groups etc.. Roll up your sleeves and work on a project, you will find new ideas. At the very least you can tell if your programmers are padding their time estimates!!
• Get hands on experience: Use every application in your organization regularly. The need for this is as obvious as it is overlooked. Unless you know the intricacies of the applications your department supports or creates, there is no way you can convincingly sell them to other departments. Even if you are not a "detail oriented" person, getting familiar with your applications will help you guide your team better.
• Allow and demand time for elegant, extensible and simple design: Make sure that your developers spend the appropriate time gathering requirements and creating extensible architecture. Ask for pictures / diagrams of the data design and data flow. For e.g. If your guys are creating an order entry application, ask questions like "Which table stores the order?" and which tables does it pass through during completion process? "How can an order be cancelled or modified at diffferent stages?" Look at the design as well as the developer's comfort while answering the question to get indications of whether all business situations have been considered in the design.
• For projects being executed by consultants, have the consultants share physical workspace with your team: Hand over or knowledge transfer sessions at the end of the project being executed by consultants  is usually not enough. If you have your team member constantly interacting with the consultant team, the project will flow more efficiently and you can be confident that your team member understands the whole project. Let the consultants have an area for private discussions but majority of their time needs to be spent in presence of your team.