Software Inventory

How much money will the organization make or save by having a new software feature in use?

The process of prioritizing the selection of proposed software features based on business value and determining the business value of software features can be as much an art as science. Beyond the more obvious examples of forecasted new sales or cost reductions that some software features somewhat easily map to, most features and their underlying business value are harder to determine.

Return on investment (ROI), Payback Period and a number of other approaches attempt to assign a tangible value to software features for purposes of making decisions on what to build next and in most cases, entire projects or release items. While these methods do work in a number of circumstances and are getting better in aiding business value prioritization, often times it comes down to the intuition of business domain experts. The people that are closest to the business problem the software features support can often see the value of a feature, at least relative to other features.

Having done software development and consulting in Kansas City for some time, one of the most important points of analyzing the business value in our opinion has been to have the discussion in the first place. Regardless of the analysis and approach used (ratios, intuition, etc.), merely spotlighting the need to make decisions on software features to build based on the value they'll add to the business (and how soon they'll add it) is a significant positive step. Another important point is to continually revisit the value discussion throughout the project not just in the beginning. Learning is a part of any software development (or any R & D process) project and a lot can change and be learned during the course of development efforts. Learning also takes place as business stakeholders see software features in action so getting working, tested features in at least a staging area to promote feedback is important to revisit business value discussions. Having business domain experts (armed with the latest intelligence about their domain [market changes, organizational changes, etc.]) reviewing features is critical for moving software out of inventory and into the business and adding value.

Take a look at your software inventory. Some say that any software development item not being used by your customers/users is considered to be in inventory and therefore doesn't have any real (tangible or intuitive) business value. Some items such as certain project artifacts (documentation, models, etc.) will never leave inventory status so carefully decide their importance in understanding what needs to be built or perhaps create throw-away artifacts, spending just enough time to reach an understanding about a particular issue and moving on.

The goal is to put things in inventory that will ultimately be valuable and then move them out of inventory to begin delivering value to an organization as soon as possible. And, if you're wondering what's valuable (working code, certain artifacts, etc.) to your customer or how they would like you to spend their money -- ask them.