I was recently involved in a project in which the goal was to streamline and automate a manual software deployment process using Electric Cloud’s product ElectricCommander. The Scope of Work was laid out, development was underway, and my coworker and I felt very confident that the UI we were developing satisfied the design specifications presented to us. Everything was great and there was much rejoicing throughout the land!
Then….the dreaded monster Feature Creep reared it’s multifunctional head/tail/can-opener!
Inspired by the well-intended goal of providing a superb user experience, the number of “necessary” features ballooned and the scope of work (SOW) seemed lost somewhere in the shuffle of ideas.
In this article we’ll talk about the ways to limit feature creep and how as a contractor, you can deal with it if it’s already happening.
Methods of limiting feature creep before it happens:
- Regularly refer back to an official, written, mutually agreed upon description of the project requirements. The key words being; “written” and “mutually agreed upon”. After hashing things out over meetings, phone calls and emails there needs to be a single document that captures the requirements. People may recall different things from a conversation so it’s important to have a common source of truth with regards to deliverables. This may be a built in to most organizations, but freelancers and contractors (especially ones new to the business) may not keep such documents or may not keep them up to date.
- Have clearly defined processes for modifying an existing SOW or conditions for triggering the creation of a new SOW. Sometimes, you do need to add or remove project requirements during the middle of development. Make sure everyone on your team knows how official changes are made to the SOW document and when it’s more appropriate to move additional features into a completely separate project/contract.
- “Content is King”. This phrase typically finds itself in web design and “starting your first blog” discussions, but its application is much further reaching. The point is to make sure that you present the user with something of actual value to them. It may be impressive the first time they load up your application and it sparkles and shines, but take the time to consider if it is really necessary and whether it help them accomplish their task. .
- Understand the actual use cases for your product. In my scenario, we started talking about all sorts of things that would be “nice to have” without consulting the end-users. It’s important to remember that what you may consider useful may not be what the customer considers useful and that the customers needs must always come first.
Obviously, stopping feature creep means identifying core functionality and removing excess. That’s pretty simple to understand, but carrying it out and managing how your team responds to it is a little more tricky.
Here are some tips for contractors trying to steer a project back on course while trying to maintain a sense of win-win for all involved:
- Recognize that people like feeling that they have good ideas and that they are making important contributions to the team. When you suggest cutting a feature provide objective reasons as to why it should be cut and give credit where credit is due.
- Depersonalize the conversation by referring back to the SOW. People will very often try to get as much out of a contractor or freelancer as they possibly can. If you’re a contractor, politely remind your client that you’re 100% committed to their success and providing a quality product, but that you have specific guidelines laid out in your contract as to what you can provide. This depersonalizes the conversation by shifting it away from “you” and “them” and onto the impersonal “contract”.
- Make sure that good ideas find their proper place. It could be that a feature deemed excessive really is a good feature, but maybe it just adds too much clutter to the current setup. People will be much more receptive to leaving their “baby” out of the current project if they understand that it could be better incorporated into a different context.
Next Steps:
- Contact SPK and Associates to see how we can help your organization with our ALM, PLM, and Engineering Tools Support services.
- Read our White Papers & Case Studies for examples of how SPK leverages technology to advance engineering and business for our clients.
David Hubbell
Software Engineer
SPK and Associates
