Most IT projects I have seen suffer from the low-estimate syndrome. I take full responsibility for projects I own and execute, since I behave like an idiot and be too aggressive when it is not required. At the same time, I have seen plenty of reviews (both internal and external to our organization) dashing any hopes of providing for unexpected problems during the course of the project. There have been a few instances where the project looked like completing before scheduled time, but we always used to find work to fill the time. That about gets work for every penny allocate, eh? Though it hasn’t really happened for me, I have seen projects that complete work before the promised date. Now that’s an interesting case study for me since we hardly see IT projects like those. With the typical thought process projects finishing early is a good thing. This is akin to getting back more than 100% while most get < 80% results. Or, is it? Go-live dates have to be always carefully planned. No IT project is an island. IT is after all solving a business problem, not deploying a system in isolation. For the project to be called successful:
- You need users who are ready for the system
- This implies users are told about the system, prepared for what is in store, and made to feel all excited about it
- Provide plenty of time for users to adapt in training
- Make deployments incremental where possible. Roll out changes by divisions, user groups, or departments
- You need market that is timed to address an issue. This is embedded in the business issue for the most part
- You need to ensure all aspects of IT in position and ready to rock. That includes infrastructure, IT support streams
Carefully plan the deployment date much ahead in time. If you are a fortunate few who complete development ahead of time, take time to validate whether any further enhancements can add substantial value in the available time. Evaluate risks of early go-live for business, users, and for IT. Early go-live may not be a good thing for everyone at all times.