I have used this term many times over the years. Inherent Functionality is just a technical way of saying that a piece of software will function as intended without any additional hours of custom programming. What might seem like a simple change to a website might not be possible without a prohibitive amount of development hours. This seems to come up the most with shopping cart and custom web solutions. It is important to carefully examining the software strategy prior to making a commitment to any piece of software.
How to Determine The Best Piece(s) Of Software:
Properly Define The Business Goals:
Picking the right software solution will depend on the business requirements. The better defined these requirements are, the easier it will be to match the correct software based on these requirements. If the business goals are not accurately defined, it may be better to create a phase 1 project to define those goals along with the design. The amount of time the developer spends on defining the business goals needs to be factored into the overall project cost.
Reviewing the Complete List of Features:
With a well-defined scope of work or list of business requirements, it will then be possible to match the “Inherent Functionality” of that software to the business requirements. Making sure that the software functionality meets such requirements may need testing and researching. The amount of time spent in this phase will ultimately lead to a prolonged life of the finished product.
Getting the Client to “Sign Off” on the Software:
Spending the time to get the client to “sign off” on the software selection is a good way to prevent problems during the development phase. The client will need to be made aware on any limitation of the software and any risk that is associated with this selection. Just assuming that the software will support required functionalities without really knowing can lead to disaster.
Reviewing Potential Software Compatibility Issues:
It is important to understand the level of compatibility with all the pieces of the project. In many cases, it will not be one piece of software driving the final product, but many interacting together. Whether it is a shopping cart and a shipping module, a custom API or CMS and a plugin; figuring out how the software elements will interact is important.
Raise Potentials Alarms during all Phases of Development.
The developer has the responsibility of raising alarm when it comes to impractical requests. When a request is made that cannot be satisfied with the current software model, it is the developers’ responsibility to raise the flags.