1. Scope out a detailed plan. Describe what the system must do for users and how you will measure the performance of the system and its output.
2. Watch out for bad RFP bids. A low number of bids or bids that are not within an acceptable range suggest that the requirements have not been properly communicated or are unrealistic.
3. Plan ahead. Line up subject matter experts who know the business processes for the new system and can provide guidance to developers and programmers during buildout. Assign a business expert full-time, or nearly full-time, to the implementation. Create a steering committee that includes subject matter experts and developers, and meet frequently.
4. Find the bottleneck. You can develop a system only as fast as it takes to build the most complicated component. Many times the delay is not from writing code, but rather something else, such as finding time with a subject matter expert. So, resist hiring more programmers to speed up the development process until you analyze what is slowing down the project and focus resources there.
5. Do not cut corners on testing. The last thing you want to do is ignore critical pilot tests and end-to-end tests. Ultimately, such corner-cutting will result in longer delays later. If you need more time, ask for it, and defend why you need it.
6. Develop a backup system. If replacing a legacy system, make sure the users can fall back to the old system if the new system fails and needs to be reworked.
7. Prepare other contingency plans. As part of your backup plan, be prepared to communicate with system users so that they can use the backup system and know what is expected of them.
8. Train, train and train. Provide frequent training for internal staff on new business processes and system requirements, including what must be done in case of a system failure. Train call center staff on how to manage users’ questions. Train users on how to use the system and what they should do in case of failure.
9. Honesty is your best policy. In case of failure, provide honest answers to users and staff. Do not make promises that you do not know you can keep.
10. Triage fixes. In fixing a flawed system, prioritize fixing those requirements that have the biggest impact on users and that provide basic, needed functionality. Come back to the bells and whistles later.