Leadership

11 'Laws of IT Physics'

During testimony before Congress, Norm V. Brown 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.

This is a guest post from Michael Krigsman of TechRepublic's sister site ZDNet. You can follow Michael on his ZDNet blog IT Project Failures, or subscribe to the RSS feed.

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 PhysicsTM."

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.

Related: J.Crew: Failed upgrade hits financial performance

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.

16 comments
bobk
bobk

To be honest, there's a bit of a disconnect between laws #4 and #10. I find it ironic that we can state that the requirements of a large project are incomplete at the beginning, which I believe to be true, but the supposed "team" that includes as System Integrator pushes the SI, especially in public sector contracts, to bid fixed price engagements and then spends more time arguing about and/or insisting on what was 'in scope' than trying to reduce complexity (see law #2)

wrgriffjr
wrgriffjr

True, perhaps, but omitted a basic one. Whoever said "An idiot is someone who does the same thing twice and expects a different result" never worked with computers.

dave.greenwood
dave.greenwood

1. All of this has been well understood by project professionals for the last several decades. Why are leaders (business and political) only too keen to hear this kind of stuff coming from management consultants, but deaf to the same messages from practitioners within their own organisations? 2. Leaders have been told all of this many times over, from various different sources and in many different ways, and the corroborating evidence of bad practice leading to failure continues in a steady stream. So why do they continue to command their organisations to do the wrong things? 3. Why do management consultants feel the need repeatedly to misappropriate terms from scientific disciplines, and why are they largely allowed to get away with it? None of this has anything to do physics, and "event horizon" is not a helpful metaphor, it's just pretentious and ridiculous.

Tony Hopkinson
Tony Hopkinson

We are techs, we know this stuff. Just not allowed to do any of it..... Anyway can't stay, got a deadline with no basis in reality to meet.....

wdperry
wdperry

Seems very familiar. Presents thoughts and concerns which were part of the project management philosophies and operational procedures followed by myself and others in the 70's. Good to see they still are very pertinent 30+ years later, or not so good if it's being somewhat realized 30+ years later.

robin
robin

These indeed are 11 key project success/failure factors, but they are not independent. Rather, underlying all of them is an initial inadequacy in discovering the REAL, business requirements which must be met to provide value. Without such awareness, which indeed is not likely or need to be 100%, planning and all the rest cannot take place meaningfully. Complexity is frequently a result of focusing on a product/system solution without understanding the REAL problem/opportunity/challenge; and of course, nonsensical budgets and schedules cast in concrete stem from wishes without suitable understanding of what the appropriate product/system solution is to meet the needs, which of course can't be defined without first adequately understanding those REAL, business requirements needs.

seanferd
seanferd

Copyright, patent, and trademark the most entirely ridiculous things. Then start filing lawsuits.

CharlieSpencer
CharlieSpencer

Or on the desk of your most clueless clients. Maybe put one of those 'read and initial' distribution check boxes in the corner.

bernalillo
bernalillo

an occasional laugh isn't a bad idea either.

patmurray12
patmurray12

I am currently working in a large firm gathering requirements. LOL, I'm only permitted to gather them from the developers who are writing the program. My manager didn't seem to understand why I would want to speak to a user... no, I'm not kidding!

Tony Hopkinson
Tony Hopkinson

To get something good enough in place with as little effort as possible using the existing kit, yesterday. Then not be left holdng the bag when what you said you wanted, wasn't what you REALLY wanted then and definitely isn't now. The only thing you must understand for IT in business, is as simple as it is scary. Change is a given. Accept this or fail.

mgray
mgray

Agreed. Many organizations want super-simplistic solutions. Often organizations claim to not have the time (so the foundation never is laid) or, because those in charge are novices at this specific area, the claim will be "we know all the requirements" (when it's clear they don't know). The research on expertise has some great explanations for this phenomenon.

Tony Hopkinson
Tony Hopkinson

large sheets of thick paper. After the users have had their first look. Fold it up, put it down the back of your trousers. At least that way it will have some use.

cegolightly
cegolightly

I find that many people know the mechanics of what they do, but very few people REALLY understand the actual Business Requirements of why they do it. This could explain why many new systems do the same thing as the old ones. If the Business Requirements were well understood, the new system might be radically different.. Can't have that now, can we? Tony's statement that "Change is a given. Accept this or fail." is very true. Projects need to devote more time into figuring out how to accommodate this inevitable change.

Tony Hopkinson
Tony Hopkinson

can be a reasonable answer in a rapidly changing environment. Even if the environment was initially static, producing software changes it. I'd be the first to admit that when RAD came to replace the obviously failing waterfall type approach, a few babies were thrown out with the bathwater. Far too often oncentrated 'expert' effort is misplaced. How often do you see the data model constructed on the back of a post-it and then 90% of the development resource spent changing colours and shifting things about by the pixel on the UI. The only way to know all the requirements, is to put an arbitrary limit on how many and which ones and then cross your fingers.

Editor's Picks