Feature Creep
7th February 2018
Feature Creep
7th February 2018
- 3 minute read
Projects, like all things, evolve over time and inevitably at some stage during the course of a project there is a request for an addition or change that is outside the the project scope. This is known as feature creep and it happens for a wide variety of reasons.
While feature creep is more often than not blamed on poor planning or inadequate requirements gathering, often clients simply wish to change something because the project has evolved, or an external pressure has acted upon something within the project which forces a change of direction.
So how do we approach requests for change that fall outside of the project scope? We as a company never want to limit a clients ability to change their mind so we work hard to accommodate change requests. That said, before we move forward with a request for change we will always talk through the change request and its implications in detail with the client. It is as important for us to understand how the request will impact upon the future of the project and its development cycle, as it is for the client to understand the market value of the change. If the change adds or subtracts from the quality of the product, how it will influence their priorities and the consequences of change upon the various project factors, not least time and budget.
Where we see a more streamlined, efficient or alternative solution to an addition or change we will present those as options before we commit to the revised project pathway. While we try not to encourage feature creep because it can lead to an over complication of a product, or result in a product that is hard to use, we acknowledge that feature creep does happen and we have to be realistic in accepting that its our responsibility to take the time to sit with the client, discuss the implications and issues that arise, and offer our best advice. Because ultimately our expertise and experience is why we were hired for the job - and we’d be selling ourselves horribly short if we didn’t.
Some changes can be accommodated within the originally agreed project costing, sometimes they fall outside. Where they do fall outside we make this very clear to the client and we’ll present revised costings for the project.
We would far rather deliver a product that does fewer things exceptionally in a targeted end user focused way, than lots of things less well, which is what we’ll have set out in the original project scope. If we deliver a robust, well designed solution to our client, their delivering in turn to their customers reinforces their reputation and by extension reflects well upon ours. For us it is about delivering on quality and not simply a numbers game.
The words feature creep do have a habit of instilling a certain sense of trepidation. Some would say that any deviation is detrimental, however we think feature creep shouldn’t be regarded as purely negative. Sometimes ideas come along that no matter how much scoping and planning you do were simply not visible or viable at the time and are possibilities now. If the value of the change outweighs the implications and the long term return outweighs the short term, surely its a change worth accommodating.