Software development is a complex and difficult task, particularly from the perspective of estimating how much time and money it will cost to implement a desired system. I've chosen very general words in the foregoing sentence for a reason.

For instance, often a software development effort is intended to deliver a system to a customer. Yet determining exactly what the customer wants -- and strangely the often different things the customer will actually accept or be able to use successfully – can itself be difficult and time consuming. Most developers are familiar with constantly changing requirements, or the reaction of a customer who sees the product and says that's not what they wanted at all.

And this is just one small piece of the larger development effort! Even before the challenge of actually constructing the software is considered, a business has to determine if the business case for implementing a new software system is good. Is there value, and is the value worth the costs? What are the time constraints, and can they be met?

Standards, like the ISO / IEEE 12207-2008, aim to reduce the uncertainty and improve the quality in software development efforts by exhaustively listing everything which needs to be considered, and specifying processes, tasks and/or responsibilities to cover everything the standard writers have imagined. As a result, such standards tend to be large and complex, themselves.

Implementing a software development project which meets the selected standard, e.g. ISO/IEEE 12207, becomes itself a monumental task, excluding the actual software development. This one important way such prescriptive standards run into human nature, and hence become dramatically less effective, right from the start.

The introductory paragraph of the Overview section of the ISO/IEEE 12207 reads:

This International Standard establishes a common framework for software life cycle processes, with well-defined terminology, that can be referenced by the software industry. It contains processes, activities, and tasks that are to be applied during the acquisition of a software product or service and during the supply, development, operation, maintenance and disposal of software products. Software includes the software portion of firmware.

The standard continues in this manner for 138 pages. The amount of effort to implement and use such a standard is significant. Retail businesses know that the higher the friction in making a sale, the fewer sales they complete. This is why Amazon "invented" the one-click checkout. The more effort a potential customer has to expand to buy something, the less likely they are to actually buy it. Software developers are human, just like those customers. If a set of standard processes requires too much effort – has high friction -- they're less likely to make effective use of them. At best, a large amount of efficiency is lost, making each project take longer and cost more. More likely, the effectivity of the standard to help deliver high quality on time will suffer, as well.

I also believe ISO/IEEE 12207 and similar standards (though perhaps not all standards) focus on the wrong things. The focus is on processes, tasks and activities.

The properties of a project instead of the procedures followed are more important. The properties better determine the health of a project. Properties include things like the following: Is there a mission statement and a project plan? Do they deliver frequently? Are the sponsor and various expert users in close contact with the team? Is there automated testing? Are the developers allowed to focus?

A better methodology focuses on a project's properties. There are two primary motives for this shift from procedures to properties.

Most standards miss the critical feeling of a project that separates a successful team from an unsuccessful one. A methodology which includes a focus on the properties which capture the feeling is a more successful choice.