IT Laws of Physics
Context
The IT Laws of Physics were written by Norm Brown, David A. Bulkin and Frank McGrath in July of 2008 to represent key constraints that impact large
scale Government IT Projects. On 31-July-2008
Norm Brown, Executive Director Center for Program Transformation, testified
to the United States Senate Subcommittee in a hearing
titled, "Off-line and Off-Budget: The Dismal State of Federal Information Technology Planning." His testimony included the 11 Laws of IT Physics.
Subsequent to the hearings, many reviewing the testimony sought out this site, blogged, and commented on the 11 Laws of IT Physics. We have received
acknowledgements on the usefulness of these laws, and more importantly, we have received constructive criticism.
We want your continued feedback on these laws, so please send comments to
IT_Laws@uscpt.org.
IT Laws of Physics for Government Projects
| First Law |
Planning is a continuous process, not a one-time event. |
| Corollary |
A Project Plan cannot survive past contract award and must continually change based on
actual experience (requirement additions or modifications count as actual experience).
|
|
| Second Law |
Complexity kills IT projects since defects and security vulnerabilities increase nonlinearly with increased complexity. |
| Corollary |
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. Government Project Offices
should ensure that the complexity of system architecture, each lower level of design, source code,
and task activity Networks is minimized.
|
|
| Third Law |
Schedule and project chaos cause projects to collapse on themselves and create Event Horizons, from which a project cannot recover. |
| Corollary |
Compute Schedule Compression and Monte-Carlo simulate the Task Activity Network to ensure the project is do-able within the time and budget constraints.
|
|
| Fourth Law |
The initial requirements for any large system will be incomplete, independent of the
resources expended to develop them. |
| Corollary |
Ensure planned requirements can be delivered within cost and schedule estimates and
include budget for requirements change; include check points for re-evaluating and changing requirements; rigorously test, accept, and
track requirements as they are met.
|
|
| Fifth Law |
Unvalidated requirements pave the road to project failure. |
| Corollary |
Test and validate requirements as early as possible, with actual end users, before basing significant projects upon
them; use pilots where possible before fully committing; and make frequent releases to production so that requirements can be incrementally vetted
via real world usage.
|
|
| Sixth Law |
You can’t manage what you can’t see. |
| Corollary |
Track status and progress against small, testable, incremental product deliverables
and use quantitative project parameters, such as Earned Value, to make projects visible and manageable.
|
|
| Seventh Law |
Not controlling the right things assures failure. |
| Corollary |
Use well established best practices such as Risk Management, Requirements Management;
Defect Management; and Integrated Baseline Reviews to control projects.
|
|
| Eight Law |
Poor defect management causes high rework and leads to project failure. |
| Corollary |
Use automated testing and continuous integration to prevent defects, and continuously
identify and correct the root cause of out of phase defects.
|
|
| Ninth Law |
Ineffectually implemented and overburdensome processes destroy IT projects. |
| Corollary |
Root-out and remove processes that don't add to the bottom line results; simplify overly complex processes;
and fix processes lacking critical essential detail needed to achieve bottom-line objectives.
|
|
| Tenth Law |
Development Contractors will do what is in their financial interest, and government
organizations may be led toward a project Event Horizon. |
| Corollary |
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.
|
|
| Eleventh Law |
Thoughtful, knowledgeable, committed people operating as a team are critical to IT Project Success. |
| Corollary |
Treat people as the valuable resources that they are; take actions to create and maintain
“jelled”, integrated, teams.
|
Baseline Ver 2.1, Updated 28-Nov-2008