A good hockey player plays where the puck is. A great hockey player plays where the puck is going to be.” – Wayne Gretzky, “The Great One”.
Software appears to be moving at the speed of a slapped hockey puck. Currently, the established players and their offerings are good. However, these days, software evolves rapidly, and it is more important to know if the software will keep up and adapt in a year, two years, or even ten years down the road. And making the right purchasing decision is yet more critical because once purchased and installed in an enterprise, it is hard to change.
â€
This was not the case in the past. The pace of software development was slow. For large software suites, it was the norm to have a release every year or two. The software user interfaces were complex and required long training sessions. The users did not want rapid change either. It was settled and the software industry was pretty much like the auto industry – you waited for the new model. It was not hockey, it was more like Tai Chi.
Today, new versions of software roll out almost continuously – my version of Firefox is 45.0.1. Our current version of Veoci is 122. Facebook updates its app what appears to be every other day. They fix bugs and bring in new features at a rapid pace. They try new ideas on a subset of users and if they fail, two weeks later they are on to the next idea. They deliver twenty six versions over the period of a year. A user need is coded and implemented in weeks. New requirements are delivered almost as soon as they are recognized. No modern software vendor has a two or three-year release plan.
The best ones are all SaaS (Software as a Service) operations: one giant system that can be updated for all users all at once. In short, it is the brave new world, completely different from the past. It is Wayne Gretzky time for software.
When deciding which software to buy, here are seven rules to guide procurement. It is no longer the gathering of detailed requirements and a checklist of functional needs. While functionality is still a part of the evaluation – where the puck is today – it takes on a lesser role in light of knowing that a product can be quickly updated to cover gaps, and will accommodate future changes without radical reinvention – where the puck will be tomorrow.
- SPEED – How fast is the software evolving? Check the changes from the last version to the current version and the time between the versions. Lack of speed equals spaghetti code base. How Agile is the software development? How long have they been Agile?
- TEAM – What is the team behind the software like? What is the CTO all about? Test the CTO with your ideas.
- SECURITY – How well is security done in the software and its underlying systems? Does it pass a basic security test? Did it undergo an external security audit? Keep in mind that on-premise software is usually not as secure as the cloud software.
- QUALITY – Is the user interface intuitive? Is the software error-prone?
- MOBILE – Does a mobile version(s) exist? Does it include core functionality and is tailored for mobile use cases?
- CLOUD – Today, there are very few reasons left for on-premise software. For on-premise installations, the cost is much higher as numerous versions have to be supported. The puck is now on the cloud.
- MINIMUM FUNCTIONAL PRODUCT – do not load up with a detailed check list that may include wish-list items.
#7 is a carry-over over from the past that most buyers of software have a difficult time accepting. Most products do not change as fast and do not get outdated as fast as software, which should be an exceptional consideration for any purchasing department. While there may be value in meeting ALL the minute and detailed needs today, it is clearly a net negative if it cuts off the option of meeting tomorrow’s changing and new needs. It is easy to build a product to a checklist. It is hard to build software that is flexible in how it is built and will adapt to future needs.
In the traditional mode of procuring software such as an RFP process, collecting user requirements and translating those requirements into something parseable for potential vendors takes a lot of time. For on-premise software, installations take time. And after that, there are integrations and customizations that take even more time. By the time the end-users are trained, their needs may have changed and any improvement is a year or two away.
Software should be “Gretzky-like:” attentive to where the puck is so that user’s current needs are satisfied, and able to get to where the puck will be with minimal time and effort so that tomorrow’s goals can be achieved.
For those who must follow the procurement process as mandated by their organization for every purchase, the RFP needs to be radically different.
