For many who have been around the software programming industry or even worked with a programmer for any length of time, the term "war" may be an accurate metaphor for trying to get the expected results out of a paid software project. More often than not the reason for this disconnect is the failure to understand how and why software programming and IT in general are different from other business units.

For all the strenghts of the business community, understanding how and why IT and software programming is different than any other business group is not one of them. When setting budgets or evaluating solutions, the business community is only concerned about one bottom theme: How much is "x" going to cost? The problem here is that one assumes the final cost is indeed determinable up front, which in the case of almost all software programming projects does not hold true.

To assume that any kind of cost range is determinable in advance, one must assume that the end product is precisely known down to the very finest detail. This is known as the assembly method, similar to the way in which auto manufacturers create automobiles. By taking the end product, such as an automobile, one can fairly easily trace each step of the process needed to create one. While many business groups may attempt to accomplish this with reams of requirements documents and specifications that would make the space shuttle look simple, the fact is that this approach is inherently flawed for software programming projects.

Using this assembly method the business community is focusing on building the product right, which is to say that if you build a product with everything outlined in the requirements document you will have built the product right. The flawed assumption here is that the business community already knows precisely what it wants, how it works, and how it will interract with every other system of consequence. This also assumes that all technology will remain static throughout the duration of the project, when the reality is that technology is ever-changing and its affects must always be accounted for in the final product. Just imagine if you were a BetaMax VCR manufacturer in the early 80's and you paid no attention to the shifting trends at the time. The difference is instead of one major trend shift for VCR manufacturers - from BetaMax to VHS, software programming trends change frequently and constantly.

What usually happens is once the project is underway, new details emerge, new ideas come forth, and suddenly the business community starts adding or changing requirements. It is also possible that new details can show that some requirements simply aren't possible or at least are not advisable. The choice IT and software programmers face is to stick precisely to the requirements and watch the project go off the cliff, or slip into an abyss of shifting goals and changing requirements - all while the allocated budget remains defiantly rock solid. Either choice leaves IT and software programmers ultimately on the hook for absorbing additional costs or taking the blame for them, and utlimately the blame for project failure and poor relations with the business community.

There is an old saying - "Even the best plans don't survive enemy contact". When fighting a war, one can easily state that the goal is to "win the war", but what that means and how to get there are not known. The result of each strategic move will dictate the next move, and the process repeats until the end goal is either victory or defeat. As the process moves along strategies are ever-changing and adapted as new situations arise and new opportunities - or new pitfalls - present themselves.

Just as an army general can't have every step of a war precisely planned out beforehand, neither can a business unit have an entire IT or software programming project scoped out to the last detail. As the project moves along the results of the previous step will determine what the next steps are. This can be thought of as building the right product rather than just building the product right. The end product will end up being something that smoothly transitions into production use rather than a large clunky solution that must be "birthed" into production and ultimately rejected as unwieldy and hard to use by its users.

Venture capitalists have used this method for ages. When a startup company comes to a VC firm asking for millions to fund an idea, no VC is going to cut a check for the full amount and send the business owner on his way. If the idea has sufficient merit, the VC firm may choose to fund a small amount and then review progress once that amount expires. If progress has gone well an additional even larger amount might be allocated. If progress is poor then the VC firm can pull out of the project without having wasted the entire amount up front. What it really boils down to is proper risk management for both sides by using iterative processes to reach a particular goal.

This is the precise approach that would work well for IT and software programming projects if only more people would use it. As IT and programming professionals we should not be focused on trying to determine the most we can bid without loosing the project, leaving the consequences until after money has changed hands. Instead we should be approaching every project with a risk management mindset similar to that of the VC model. The IT group and software programmers will not be left on the hook for promises or requirements, and the business community will not be left warring with IT and software programmers trying to get results that they were lead to expect when writing the check.