Feature creep and limitations

One of the first things I'd imagine a lot of freelancers experience is feature creep.

What is feature creep?

As the simplest definition, feature creep refers to the myriad small changes that go beyond the initial approved plan, introducing unplanned additions and cause the project to drag.
As a freelance developer, when a client has a list of features and a brief is prepared; that contract exists to protect both parties. The client is protected with a list of tasks that are required to be completed and the developer is protected with confirmed payment on receipt of said tasks.

When the required tasks are extended like the Sahara creeping into Nouakchot, this is feature creep.

Feature creep can exist in a number of ways - from seemingly the most minor (creation of new views/panels) to larger features such as an alteration in site architecture.

My experience

It’s all too easy to fall into the trap of going beyond the brief to supply just one more thing in the effort of staying on the good side of the client.
With that however, comes the risk of continually being expected to provide just one more thing.
For companies on a budget, start-ups, or those inexperienced with brief writing there seems to be a risk of trying to get the most out of contractors.
Care should be taken not to fall into the trap of going along with it to appease the client.

With one of the first clients who sought my services to speed up and augment site experience I almost instantly fell into that trap, despite the fact that I was more than aware of the risk.

Although a brief had been created, with a list of requirements and tasks, the company (a start up) were developing rapidly and had big ideas with rapidly changing requirements. Tasks started off well enough with everything completed to specification. One by one, items were checked off the list and signed off on the client end.

Close to their launch deadline however, things were getting frantic for their team. Funders and investors were on their back and since our working relationship was good, their troubles were conveyed to me in our biweekly catch ups.
With this extra pressure on their back, I found myself stumbling into the unfortunate situation of agreeing to help where they were behind. I regretted it from a business standpoint almost instantly since there was no plan/brief to protect me. However, because I too, was excited about their launch after working with them closely and consistently, it served as a form of consolation that I was helping them out.

How it ends

At an estimate, despite contracting 40 hours I ended up working about 45-50 hours. Despite release being on time, those 5-10 were lost billable hours however you look at it.

Easy as it is to simply agree to more work off the cuff and take up a verbal agreement, I can’t stress enough the importance of getting any further hours contracted. Empathy is almost always a factor when developers agree to work reminiscent of feature creep. Getting drawn into the work isn’t a bad thing but it’s always worth taking a minute to check that you, as the developer, is covered for the work.
Luckily for me, subsequent to the completion of the project I was asked about the extra hours and compensated accordingly.

As a developer, it’s almost inevitable that you will experience feature creep in one of its forms. As long as work is agreed to in writing prior to continuing then there is no creep and you’ve done as you’re expected to do!