Software package implementation including EIM/SPM software can be a complex process and many projects are not successfully delivered or are done so over budget. One issue that often causes trouble on projects is the introduction of functional flexibility that is ultimately unneeded. Many times when a business owner is asked about a particular business function there is a tendency to overstate the need. For example plan sales compensation plan administrators often say they need the ability to change a particular commission rate or rule effective at any time, even multiple times within a pay period. In reality based on how the compensation plan is constructed, it may make no sense to do so and the practice may actually never be done this frequently.

Why should software systems implementers and the eventual owners worry about this unneeded flexibility? The simple answer is that if these requirements make it into the final feature set to be delivered, costs can increase dramatically. The direct relationship between feature addition and development and delivery costs is obvious. Additionally, in severe cases of unneeded feature bloat, the system may become undeliverable. Finally, unneeded flexibility may result in a system with increased complexity causing higher post implementation maintenance and operational expenses.

What drives the introduction of unneeded requirements for a software system? Several that I have experienced:

• Business owners do not want to restrict themselves – Business owners do not often find themselves being asked what they want in a new software system. Not wanting to blow this chance, they have a tendency to cloud attention to true practical business need with a kid in a candy store mentality. Additionally no business owner wants to be remembered as the one that gave in on a system requirement that down the road hinders business function. Erring on the side of caution for a business owner means always answering requirements inquiries with the most flexible feature rich driving answers regardless of true business need.
• Limited access to true statistics on business process – A well designed system should best satisfy the automation of business tasks that are most frequently performed and that are most critical to success of the enterprise. Often though, true data about the frequency at which certain business events or functions occur is not known; project timelines often discourage proper analysis which would provide data crucial to the best requirements set determination.
• Inexperience among requirements gatherers – Business analysts or others who have been assigned to gathering system requirements may lack the experience to ask the right questions of more seasoned business experts that will own the system being developed. Additionally, if these business analysts are not familiar with the workings of the proposed software, they miss opportunities to steer or corral functional requests into the most implementable options.

How can this issue be addressed? More education about system delivery process across all members of the project team can help. Business owners and business analysts can benefit from a better understanding of how the software works. Additionally these team members should not be isolated from the development and eventual operational costs associated with the decisions on requirements and feature set determination. Requiring business owners to justify requests with real statistics about the frequency of occurrence of scenarios driving their inclusion can help distinguish absolute from exaggerated need. Finally, understand going live with a system with the critical subset of all desired functions is an option; plan for additions but allow time for the evolution of business process that certainly take place with its introduction to dictate their priority. Encourage all parts of your delivery team to keep these ideas in mind; sacrificing some functional flexibility is well worth avoiding a poorly designed, difficult to operate, or undelivered system.

-Michael Stus