Feature Creep in Corporate Software

The corporate world always has one more thing they need from of your application. This usually begins in the planning stages where all the stake holders are brought together to help scope out the project. A small feature request here, another critical functional requirements there, coupled with the most demanding stakeholder rallying for a specific feature, and pretty soon this becomes an bloated project scope.

Welcome to the Corporate world of Software Feature Creep

If the stakeholders and their respective reports are requesting for specific features, saying no is sometimes not an option. Especially if the stakeholder also happens to handle the budgetary strings attached to the project.

So what can be done?

Set Small, Well-Defined Initial Meeting Agenda

From the very first meeting, make sure that everyone knows the meeting scope. Keeping the meeting scope as precise and detailed possible allows you to stay on topic. If possible, email everyone ahead of the meeting with the agenda details. It will also set the precedence that you come prepared and promote the members to do the same.

Most importantly, it prevents feature creep from day one. The reality is that when presented with pre-planned meeting agendas, people tend to stick with it. However, the inevitable additional feature request will pop-up in the course of the meeting, regardless of how well-defined the agenda is set. In cases like this, allow the group to express their requests. Then note it down and tell them that you will need to plan this item out. This gives the members to think over their feature request until the next meeting.

Log the Meeting Minutes

Make it a point to log the minutes of the meeting. Before the meeting concludes, read them back to the group. This way, you get an verbal agreement consented by the group.

Here's a template that I usually use to take down the meeting minutes:

Download link: https://www.dropbox.com/s/zaaczhubr7owz7t/Meeting%20minutes.doc

After the meeting, email the document out to the attendees. At the very least, it will allow you to refer back to it in-case the agenda items start to differ.

Feature Creep in Future Meeting

For the preceding meetings, bring up the features requested from the previous meetings. This way, you actively acknowledge them.

Next is the tricky part: determining if the request is a creep or something you could truly accommodate. Often, there is an assumption that you referencing previous feature requests suggests that it'll be something you do build.

If you can accommodate the request, then leverage it for more time. There must always be a trade off. Blindly saying yes will lead to future feature creep and convince the client that te task is easy.

However, if this feature request cannot be done, or doing so will completely ruin the system, explain it to the client. Often the client will understand and accept it.

The "2nd Phase"

In the off hand that the client continues to insist, there is one final card you can play. Declare the feature as something to allocate for the 2nd Phase. This will immediately signal to the client that the task is simply too large/complex to accommodate with the given timeframe. The request here isn't denied, rather pushed to the future allowing you to really focus on narrowing the deliverables.

Bottom line: Keep the scope attainable by managing expectations, and don't be afraid to say no.

(Title Image Credits: acentre.com)
Previous
Changing Mac OSX Terminal Shell
Next
Simple Introduction to Model-View-Controller (MVC) Software Architecture