10 key characteristics that make IT projects succeed.

I have been involved, over the years, in a large number of successful and a number of unsuccessful IT projects.  As I have been helping other companies with projects, I can usually tell ahead of time, when a project will be successful or when it will be left wanting. 

What basic characteristics do successful IT projects have?  Why are they successful?
I have put together my list of the 10 characteristics that make IT projects successful.  

1. The project has a succinct definition. 
• This is a key ingredient.  If you cannot describe what the project is, it will be hard to measure its success. 
2. The project has a limited scope.  
• Projects that try to fix or change too many things at a time often fail.  If there is a need to change multiple technologies in an organization, then it is better to have multiple projects that do not go live at the same time.
3. The project has buy in from upper management and the affected business units.  
• This is key, no one likes to be surprised with change.
4. Communication.  
• The project has mechanisms in it to keep key people in the know, and also keeps the end user abreast of implementation time frames.
5. The project has a backup plan with a tested recovery process.
• A tested backup plan and recovery process is needed to get your production data into test (most of the time).  This is also key to any back-out plan and it should be part of the organization as a whole. 
6. The project is tested in a non-production environment when applicable.  
• This is another key component. Never take a vendors word that nothing adverse will happen in your environment, every environment is unique. 
7. The project has a change management process 
• Change managment is needed to put the project into production methodically.  There should be no surprises, and no thinking needed when doing the actual work.  
• The only time critical thinking will be needed is if something unexpected happens during the change process.  
8. The project has a set, well defined, back-out plan.
•  Sometimes with even the best testing in a great test environment, things outside of the projects control happen and necessitate backing out the changes.  
• Think power outage, new virus/trojan, etc.
• Make sure that there is sufficient time to restore data, if needed, before your maintenance window expires. 
9. The project offers a realistic time-frame to be accomplished.
• I have seen many small projects be under estimated.  This can cause unexpected issues with users, cause all night installations.  I like to use a real test scenario time frame, then add an extra 20 percent overhead to account for unknowns.  
10. End users have training on the project. 
• Before the project is rolled into production there needs to be a thought-out training plan. Is the project small enough so that an emailed document suffices for the training?  
• Is the project massive in scope for a certain department?  Then make sure that key individuals have had hands on training from IT or the product manufacturer. 
• Training is often overlooked, but performing it keeps your end users happy, and it keeps the help desk from getting inundated with support calls the day after the project has finished.