Most IT software projects are not successful — if success means delivering on-time and on-budget, accomplishing business objectives, and ongoing usage. According to the Standish Group Chaos Report, only 29% succeed while 19% are considered utter failures. To beat the odds, follow these best practices shared by myself and more than 100 fellow senior IT executives, all members of the CIO Forum.

  1. Assemble the right team through a disciplined hiring process. To ensure that you find high-performers, create custom forms for each job opening, and set up tests that measure specific skillsets. Only hire candidates that achieve unanimous buy-in from team members.

  2. Assess infrastructure and capacity. Before beginning a major software project, take full inventory of your infrastructure, considering the reliability, utilization, performance, capacity, and design of your servers, storage devices, networks, desktops, printers, databases, telephony, and data center resources. Then, plan for at least four times the “expected peak” load, and assume that any given piece of hardware, including motherboards and RAID cards, will fail.

  3. Begin with clear, complete requirement and engineering specifications. The requirement specifications should address a particular pain point, and describe the function of the project and the nature of the user experience. The engineering specifications should be comprehensive, unambiguous, and carefully reviewed. It should describe how the solution will work, complete with a “milestones” section. When custom coding is involved, it must also include an “architecture” section, laying out exactly how the requirements will be implemented.

  4. Leverage existing technology to avoid custom coding whenever possible. Custom coding introduces a significant level of risk and introduces bugs. Over the lifespan of a large project, the typical ratio of costs for bug-fixing or maintenance compared to initial development is a whopping 4:1. If custom coding cannot be avoided, set expectations that the project may take much longer than expected, and budget for ongoing maintenance costs.

  5. Stay focused on the user. The needs and requirements of the business stakeholders and end users should be carefully considered early in the process, and revisited throughout development via consistent communication.

  6. Clearly document the cost and impact of any change request. Make sure that those requesting changes take responsibility for these impacts.

  7. Establish a good QA process, and provide an early demo environment to capture feedback. Train users in a test environment before the system goes live. Gather feedback during this training, and plan on modifying the system based on input.

  8. When sourcing third-party software, thoroughly vet products for scalability, integration, security, auditability, and other critical factors. Look for solutions with a web interface, auditability, dashboards, automated backups, security, web services/REST APIs, reporting, searching, synchronization with other systems, data integrity constraints, and export/import capabilities.

  9. Consider negotiating with vendors. A good rule of thumb is $75,000. If the project cost is less than that figure, it should be ok to go with the vendor’s standard contract — as long as it is reasonably balanced (between the interests of the vendor and client) and compliant with industry standards.

For even more tips, read the full white paper: