11 "Laws of IT Physics"
Given high rates of failed IT projects, it's helpful to examine first principles that underlie successful technology deployments. Even though devils live in the details, understanding basic dynamics behind successful project setup, execution, and management is important.
During testimony before Congress, in a hearing titled "The Dismal State of Federal Information Technology Planning,” Norm V. Brown, Executive Director of the Center for Program Transformation, an IT failures think tank, presented what he calls "Laws of IT Physics™."
These "Laws" highlight hidden pitfalls the hurt many projects, and help explain why some projects succeed while others fail. They recognize that successful IT project delivery is primarily about managing people, process, and deliverables. Yes, technology is important, but the people side comes first. Here's the list, with slight editing:
1. Planning is a continuous process, not a one-time event. A Project Plan cannot survive past contract award and must continually change based on actual experience (requirement additions or modifications count as actual experience).
This is the silent killer! Lewis Cardin, senior project portfolio management analyst at Forrester Research, calls this "first number syndrome," where senior management becomes tied to initial estimates and refuses to accept change.
It's completely unreasonable not to expect that lengthy projects will evolve over time. Change isn't necessarily bad; for example, business needs may evolve and force a corresponding project adaptation. Balancing shifting priorities through scope changes is the difficult part of this equation.
2. Complexity kills IT projects since defects and security vulnerabilities increase non-linearly with increased complexity. Minimizing and controlling complexity are key to successfully achieving a large-scale system development success both in the development of individual releases and in the cost and schedule of downstream upgrades to operational software.
3. Schedules and project chaos create event horizons, from which a project cannot recover. Avoid the Project Event Horizon; Compute Schedule Compression and Monte-Carlo simulate the Task Activity Network.
According to Wikipedia, in general relativity an event horizon is a boundary inside which events cannot affect an outside observer. Combine a complex technical environment with byzantine project scheduling and workflow, and meltdown becomes likely. Simplify wherever and whenever possible.
4. The initial requirements for any large system will be incomplete, independent of the resources expended to develop them. Ensure planned requirements can be delivered within cost and schedule estimates, but also include budget for anticipated and actual requirements change; rigorously test, accept, and track requirements as they are met.
5. Unvalidated requirements pave the road to project failure. Test and validate requirements as early as possible before basing significant projects upon them; use pilots where possible before fully committing.
Requirements planning is an absolute foundation for successful project delivery, which is always rooted in well-defined user requirements and carefully managed estimates. If you screw up here, failure is inevitable.
6. You can’t manage what you can’t see. Track Project Status and Progress against small, testable, incremental product deliverables and use quantitative project parameters, such as Earned Value, to make projects visible and manageable.
7. Not controlling the right things assures failure. Use well established best practices such as Risk Management, Requirements Management; Defect Management; and Integrated Baseline Reviews to control projects.
8. Poor defect management causes high rework and leads to project failure. Use automated testing and continuous integration to prevent defects, and continuously identify out of phase defects to correct their root causes.
Yes, testing matters a lot. Just ask retailer J.Crew, which lost the ability to ship product to customers after deploying a new web site and content management system without sufficient testing.
Testing isn't rocket science, but it must be performed in a disciplined and consistent manner.
9. Unknown and untreated vulnerabilities originating in ineffectually implemented processes destroy IT projects. Automate vulnerability identification and prioritize fixes which root-out and fix processes lacking critical essential detail needed to achieve bottom-line objectives.
10. Development contractors will do what is in their financial interest, and government organizations may be led toward a project event horizon. Incentivize well and wisely, trust but verify, and use Award-Fee type contracts; carefully construct the Award-Fee criteria to address principal project objectives over the near term; identify what Award-Fee structure will sufficiently motivate the development contractor.
Every major IT project consists of a partnership I call the Devil's Triangle: customer, technology provider, and system integrator working together to achieve a common goal. These groups have interlocking and sometimes conflicting agendas, which makes management a balancing act of priorities.
Related: Consulting's dirty little secret
Most consulting companies are honest folks doing the right thing for their customers. Still, you need to protect yourself from bad apples by carefully controlling contracts, incentives, and penalties.
11. Thoughtful, knowledgeable, committed people operating as a team are critical to IT project success. Treat people as the valuable resources that they are; take actions to create and maintain “jelled” teams.
Although these 11 laws are oriented toward government projects, the lessons are equally applicable to projects in the private sector. The list is worthy of your thoughtful consideration.