• Seilevel Team

    Here’s the Team

    Welcome to our Seilevel Photo Op.

What is the Value of that Feature?

Alright. You’ve just identified the features that your client doesn’t need going forward, the ones they can hold off on for now, and the ones that have to be implemented with the project. How did you come to that conclusion?
Were all the different group’s champions in a room with you giving the thumbs up or down? Did the project funder push their features through? Maybe the cries of anguish from users as you held a feature over the out of scope bucket let you gauge how much it was needed. Are any of those a sound business case for the need of a feature?
Depending on the grandeur of your project, maybe it is. My bets are that it isn’t enough. To really know what should or should not be implemented, every feature should be tied to a business objective. At the highest level you should have something along the lines of increase sales and decrease costs. From these you can have supporting objectives such as training sales, increasing client meetings, reducing cost of proposals, etc.
So did the project really need the feature to search for client information? I would imagine that kind of feature would be tied to an objective to allow for easier access to operational data, which ties to another objective to reduce costs of supporting client request. Given that, you should have a list of measurable KPIs (key performance indicators) for these objectives. This case might have a measure of the number of client requests for data per day and how long it takes to resolve the request with and without the search capability.
Now you will have to compare how strongly this feature affects the objective to reduce costs of supporting client requests. If there are a few other objectives that tie into this one, then you might imagine that the easier access to operational data could have a 20% correlation to the parent objective. From there you can take your current costs, multiply it by how important reducing costs of supporting client requests is and then multiply that against how important easier access to client data is.
So for example, let us say that our costs are $25,000. Turns out that reducing the costs of supporting client requests objectives is 30% of that cost. Now all the sub objectives are worth some part of $7,500. We said that the objective to provide easier access to client information was contributing 20% to its parent objective. This means that it is worth $1,500 of your costs.
Now you know that not having the feature costs you $1,500. You can estimate the implementation costs of the feature as well. If the implementation is higher, then arguably the feature should not be built. If the implementation cost is less than the value of having it, then you may want to build it, but at that point, you should compare the value of all the features in case you cannot build them all – choosing the ones with the largest value.
No comments yet.

Leave a Reply

Your email address will not be published. Required fields are marked *