I was reading an article the other day that referenced the
80/20 rule
with regards to software. For those of you that haven’t heard of it, it
states that 80 percent of users only use 20 percent of the features of a
software product. We have all used Microsoft Word at one point or
another, but what percentage of Word’s features do you really use? Of
all the software packages you have, do you really use more than 20
percent of any of them? And more importantly, how much does the 80
percent of the features that you never use get in the way of finding and
using the 20 percent that you do use?
The 80/20 rule has me thinking of software development and how vendors go about addressing organizational needs and developing enterprise solutions. I have been on the vendor side of enterprise software for a number years. I have seen firsthand how a large number of established vendors and some startups approach the process of developing enterprise software solutions with regards to functionality. While each vendor solution generally starts off with a modest feature set, from there they generally begin furiously adding functionality to their products on a regular release cycle in a functionality arms race to be crowned as vendor with the most functionality. The functionality requests, for the most part, come from individual customers or from the vendor’s own development group with little or no vetting in the marketplace. Rarely is any functionality ever removed because they are afraid a customer – even one customer – is going to complain.
With each new release, the new functionality must be integrated into the existing product not only on a technical level, but also into the user interface. As more and more functionality is layered into the products they become slower, more complex to use (as in harder to find the 20%) and difficult to maintain with some becoming unstable. The result is a user interface cluttered with a mishmash of selections making them complex and hard to navigate. Addressing the end user’s needs was the point of developing the solution in the first place, but now the end-user experience perversely ends up getting lost in the “process.”
While software vendors most certainly have their share of the blame for this situation, the user organizations are not completely blameless. Have you ever read an enterprise software request for proposal (RFP)? When user organizations create RFPs, they generally throw everything including the kitchen sink into them. Because IT budget is so hard to come by, they ask for capabilities that they don’t need and will probably never use (the 80%), which in turn obscures the ones they will use (the 20%). The vendors are then judged on responses based on their ability to deliver the kitchen sink, and these responses are in many cases yes or no answers. So if you are the typical enterprise software vendor, what choice do you have? You are compelled to answer “yes” to as many questions as you can, which essentially enters you into the functionality arms race whether you intended to or not.
User organizations’ requirements don’t evolve into long functionality laundry lists by accident. This is a result of the way in which enterprise software solutions are delivered. You have to make sure you get everything you can possibly think of in there because you generally have one budget approved for the solution you need to solve the problem you have. Once you select the solution, that’s it, you’re stuck with it, and you’re not going to be able to go back for a redo.
So what’s the solution? At some point there must be a paradigm shift for delivering enterprise B2B solutions. Instead of continuing to deliver bloated solutions that users will only leverage 20 percent of, the functionality needs to be broken down into bite-sized, more easily consumable pieces. Smaller pieces of functionality that are more narrowly defined that allow organizations to more easily target specific requirements. Customers can then request specific functionality that best fits their requirements. The result is more successful implementations where you no longer have to pound a square behemoth solution into a round focused problem.
Here are 5 guidelines to help you avoid the software bloat pitfall and have better implementations:
What is your take on this problem? Have you been privy to an implementation that took longer than expected, had more speed bumps than expected, and was difficult to use? This blog is the place for feedback so sound off if you have been a part of a large software deployment that you use only 20 percent of.
One of our goals for starting Vallum Software was to provide problem-solving solutions at the lowest possible cost with the quickest installations. We believe we have accomplished that goal with the Halo Manager solution and our plug-and-go Halo Apps from the Halo App Store. Our focus is on the end user experience in the network monitoring and management market. Find out more at http://vallumsoftware.com.
I hope this information has been useful to you and as always, I welcome any comments. Please check out Vallum and our partner the GMI-Foundation.
About the Author:
Lance Edelman is a technology professional with 25+ years of experience in enterprise software, security, document management and network management. He is co-founder and CEO at Vallum Software and currently lives in Atlanta, GA.
The 80/20 rule has me thinking of software development and how vendors go about addressing organizational needs and developing enterprise solutions. I have been on the vendor side of enterprise software for a number years. I have seen firsthand how a large number of established vendors and some startups approach the process of developing enterprise software solutions with regards to functionality. While each vendor solution generally starts off with a modest feature set, from there they generally begin furiously adding functionality to their products on a regular release cycle in a functionality arms race to be crowned as vendor with the most functionality. The functionality requests, for the most part, come from individual customers or from the vendor’s own development group with little or no vetting in the marketplace. Rarely is any functionality ever removed because they are afraid a customer – even one customer – is going to complain.
With each new release, the new functionality must be integrated into the existing product not only on a technical level, but also into the user interface. As more and more functionality is layered into the products they become slower, more complex to use (as in harder to find the 20%) and difficult to maintain with some becoming unstable. The result is a user interface cluttered with a mishmash of selections making them complex and hard to navigate. Addressing the end user’s needs was the point of developing the solution in the first place, but now the end-user experience perversely ends up getting lost in the “process.”
While software vendors most certainly have their share of the blame for this situation, the user organizations are not completely blameless. Have you ever read an enterprise software request for proposal (RFP)? When user organizations create RFPs, they generally throw everything including the kitchen sink into them. Because IT budget is so hard to come by, they ask for capabilities that they don’t need and will probably never use (the 80%), which in turn obscures the ones they will use (the 20%). The vendors are then judged on responses based on their ability to deliver the kitchen sink, and these responses are in many cases yes or no answers. So if you are the typical enterprise software vendor, what choice do you have? You are compelled to answer “yes” to as many questions as you can, which essentially enters you into the functionality arms race whether you intended to or not.
User organizations’ requirements don’t evolve into long functionality laundry lists by accident. This is a result of the way in which enterprise software solutions are delivered. You have to make sure you get everything you can possibly think of in there because you generally have one budget approved for the solution you need to solve the problem you have. Once you select the solution, that’s it, you’re stuck with it, and you’re not going to be able to go back for a redo.
So what’s the solution? At some point there must be a paradigm shift for delivering enterprise B2B solutions. Instead of continuing to deliver bloated solutions that users will only leverage 20 percent of, the functionality needs to be broken down into bite-sized, more easily consumable pieces. Smaller pieces of functionality that are more narrowly defined that allow organizations to more easily target specific requirements. Customers can then request specific functionality that best fits their requirements. The result is more successful implementations where you no longer have to pound a square behemoth solution into a round focused problem.
Here are 5 guidelines to help you avoid the software bloat pitfall and have better implementations:
- Clearly define the business requirements and group them into smaller functional groups that make sense.
- Break down the technical and functional requirements into understandable elements and align them with the business requirements. This will help you understand the requirements better and help eliminate those that do not contribute to the business need.
- Don’t boil the ocean. Group the requirements into several functional groups and implement a priority weighting on each requirement and each functional group, then attack the problem piecemeal.
- Avoid the behemoth “everything is in there” solutions. Select smaller more specific solutions from vendors that are better suited for addressing each group. If you have a new vendor that you have not worked with before, have them prove themselves on lower priority items first before the higher priority ones.
- Identify all integration points between solutions early on and clearly define them. If you have more than one vendor, bring them together as partners early in the project.
What is your take on this problem? Have you been privy to an implementation that took longer than expected, had more speed bumps than expected, and was difficult to use? This blog is the place for feedback so sound off if you have been a part of a large software deployment that you use only 20 percent of.
One of our goals for starting Vallum Software was to provide problem-solving solutions at the lowest possible cost with the quickest installations. We believe we have accomplished that goal with the Halo Manager solution and our plug-and-go Halo Apps from the Halo App Store. Our focus is on the end user experience in the network monitoring and management market. Find out more at http://vallumsoftware.com.
I hope this information has been useful to you and as always, I welcome any comments. Please check out Vallum and our partner the GMI-Foundation.
About the Author:
Lance Edelman is a technology professional with 25+ years of experience in enterprise software, security, document management and network management. He is co-founder and CEO at Vallum Software and currently lives in Atlanta, GA.
No comments:
Post a Comment