An organization providing IT solution delivery to a business, be it as an external third party or an internal IT department, is primarily driven by the requirements of their client. Ideally these requirements are generated through a process of business analysis directed towards an overarching vision such as "how can the cost of identity management be reduced?", "how can the efficiency of service delivery be increased?" and "how do we more closely meet our compliance and auditing needs?". I said 'usually' as I have come across many supposed critical business requirements' in my time that almost certainly came about by a process of 'business analysis by mood'. In such a situation as this where the rationale for a given requirement is difficult if not impossible to justify, what course of action should the conscientious and well experienced solution delivery partner take?
Where such requirements increase the complexity of a solution, the minimum that can happen is scope creep which can result in an increase in project resource and time requirements, thereby driving up the overall project cost and the time required to gain return on investment. At the extreme, a bloated set of requirements can result in the project being impossible to deliver due to an inability to hit deadlines and show any real value to key stakeholders. Where the 'additional' requirements introduce extra middleware, processes and customization the result can be a solution that is difficult to use, maintain and extend. Regardless of their intention and ultimate delivery path, ill-conceived business requirements included within a project can ultimately lead to it's untimely end. With this is mind, it would be easy to say that all client requirements that have no purpose or business benefit should be refused or pushed out of scope. In reality the relationship between the solution delivery party and it's client is that a relationship must exist where the provider is receptive to any and all requirements, regardless of their conception, impact and intention.
So for the sake of increasing its billable time and perhaps software license sales (I'm excluding internal IT departments here), should a solution provider accept every ad-hoc business requirement and 'back of a post-it design'? The 'right' answer here is of course no, although this can be regularly seen in IT departments across every industry sector. By giving an organization the 'moon on a stick' what happens ultimately is that neither party in the relationship benefits. The client organization ends up with a solution that poorly fits their true requirements whilst also costing more then could be ever justified. Organisations that have been through several projects delivered in this manner commonly adopt a 'rip and replace' strategy to purge themselves of a solution that (in their mind) is not fit for purpose. By not working with their client in a responsible manner the service provider can eventually lose credibility, a referenceable engagement and any repeat business. Where the service provider is an internal department this can result in the outsourcing of large parts (or all) of an solution delivery team. Where a solution provider has outsourced some or all of the solution delivery tasks to another solution provider, such as software development, the need for effective and transparent project management is even greater, principally due to lack of visibility regarding roles and responsibilities within the partnership.
In conclusion, the most effective solution delivery projects will be those where the solution provider is able to listen, understand and respond to all customer requirements, whilst also be responsible and strong enough to raise objections and concerns over requirements that would endanger the project delivery process or deliverable. On the client side it is critical that they understand their own business model, drivers and technology before they start interacting with a solution provider. Any feedback from the provider on the defined list of requirements list should be accepted in an open and unbiased manner by the client. Finally, in addition to requirements management, it is of paramount importance that an open and trusted relationship exists between the two parties as both have goals that they are trying to seek.
