Resisting Feature Creep

projectmanagementdelivery.gifWhile developing RADDroid I was reminded of the need to resist feature creep. Specifying, designing and implementing my own project made it even easier to add new features just because I could. However, I strictly kept to my original specification so as to prevent an excessively delayed release.

I have seen feature creep on many mobile projects I have worked on. Triggers for creep have included…

  1. Owners or project managers suddenly having a ‘great new idea’ mid-project
  2. New people coming onto the project mid-project and inventing something extra to fulfil some need to be part of the project
  3. Remote stake holders reviewing the project too late in the project
  4. A realisation that the user experience isn’t as good as it could be
  5. A realisation that the server side isn’t scalable

All these things jeopardise project delivery and increase costs. The first two are, in my opinion, unforgivable. It’s often the case that end users are better placed to suggest new features. It’s better to put mid-project ideas on hold for a later release within the context of user-suggested improvements.

Stake holders reviewing projects late is more of a process and project management problem that’s common yet preventable. It’s all about involving them early and making them part of the specification and an iterative review process. It might seem difficult to do so at the start of a project but if you leave it until the end it can come back to bite you.

The last two triggers are types that should be allowed to cause feature creep. Sometimes the suitability of things can’t be assessed until they are implemented. This is especially so in more complex projects. For the user experience example, typical problem cases include non-standard UI layouts, error UI flows and asynchronous tasks. In the server scalability case examples include batching up server requests into one request making the server interface less chatty, optimising data formats or even removing or bypassing features. In extreme cases I have even seen the server side completely re-implemented mid-project to use a different server side technology. Even with the best client-server architectures, changes in the server side can end up affecting features in the app.

The key thing is to have strong project management able to determine whether new features are being done on a whim or whether they are a necessity.