SMOP

"SMOP" is an acronym that I learned about early in my career. It stands for:

"Simply a Matter of Programming".

It highlights one of the major differences between hardware projects and software projects.

In just about any hardware project, a new enhancement or change inevitably involves some sort of extra payment to an outside company. If you are manufacturing vacuum cleaners and a customer asks for an exta long power cord, it's more than likely that you will have to purchase that cable from another manufacturer.

In other words, your company will have to write a check to another company.

Software development using an internal staff (which is nearly always the case, especially for custom development) isn't like that. In most cases it only involves having one or more programmers spend a few extra hours writing some more code and one or more testers testing that code. It's just a matter of SMOP - no purchases outside of the company are needed.

If, for example, the customer decides that they would like a new report, and the data needed for that report is already in the database, it might take only a day or so to add that report. Possibly it may take even less.

Customers know this as well as anyone.

What they will often do is actually talk to the individual programmers in order to try to get them to add such features. Such things are particularly common during an installation.

It is up to the Project Manager to make sure that the customer and the Project Manager's own managers don't allow this. Changes require change control. They must be paid for. If you don't do if for every single change then you will lose control.

A problem comes up because there is an administrative cost with documenting a change through the standard change control process. With some minor changes the cost to write up the change request, estimating the cost, having it approved and then updating the speciffication might exceed the cost of making the change itself. That is a solvable problem as well.

Just as companies open puchase blanket orders with vendors in order to allow a large number of smaller purchases without the normal administrative overhead, you can do a similar thing with software changes. You can have the customer agree to have a "blanket change" cost and track costs against that. If the entire budget is not spent, then the customer gets money back at the end of the project. If the "blanket" cost is exceeded then the customer needs to write another check. Even in this case the specific changes need to be tracked. At a minimum the specification for the project must be updated so that it accurately reflects the solution that was delivered.

It is important to emphasize that "bug fixes" don't fall into this category. If the specification for the project says that something must work in a particular way and the customer can demonstrate that it doesn't work that way, then the vendor is obligated to make it work that way at no additional charge.

But an enhancement is something that is different from what the spec says. All of those must be paid for.

The key point is to establish this understanding at the very beginning of the relationship between the vendor and the customer. The software developers need to understand this as well as the customer does.

If this is not understood by everyone, there is a very real possibility that the project will overrun its budget.