October 9, 2014Doug Hadden
the FreeBalance experience
Doug Hadden, VP Products
One of the byproducts of Washington DC environment of international donors, thinktanks and development NGOs is an education in economics. The notion of “incentives” that motivate actions has become very familiar. And, many within this larger development and public financial management ecosystem make very quick decisions related to perceived incentives. Or, assumptions.
One of the most persistent assumption is that all software manufacturers within the “enterprise” space behave similarly because of the same incentives. The general view in the ecosystem, is that firms like FreeBalance do not have the proper incentives to provide objective advice to governments. The perverse incentive is that FreeBalance, like ERP vendors, wish to keep product development costs down. Therefore, we will recommend that governments use features that our software possesses. And, we will recommend against trying something that our software does not do.
Government professional often think the same thing.
But, the reality is much different. It might be reasonable to conclude that large ERP manufacturers may wish to keep feature requests down. A specialist firm like FreeBalance seeks to learn about functions that our software does not have. Why? Our value is predicated on reducing code customization to almost nil. That means that we seek, within our product group, to uncover government needs to share with all of our government customers.
This does not mean that FreeBalance is willing to build something that ought not to be built. Some governments wish to “pave the cow path” by including inappropriate functionality from previous versions. One does not implement a new information system to perpetuate what wasn’t working before. Some governments wish to implement advanced functionality that is inappropriate given current capacity. (Many civil servants are familiar with the lack of agility from ERP systems and believe that they will not be able to “progressively activate” as capacity increases. That’s not a problem with FreeBalance.)
How do we handle this? We seek to understand the underlying problem that needs to be solved. That allows us to adapt our product roadmap based on customer input. And, to be “customer-centric” does not mean doing what customers ask, but what’s best for the customer. This includes recommending to not use features that are in the software.
Our top incentive is to have successful implementations that achieve goals. Unlike large ERP vendors, we can’t afford failures.
Latest posts by Doug Hadden (see all)
- The (IT) Project was a Success, but the Patient Died [Part 2] - September 21, 2016
- The (IT) Project was a Success, but the Patient Died [Part 1] - September 20, 2016
- Have we over-complicated the ‘smart’ in smart government? - September 8, 2016
- Why PFM reform is integral to smart government - September 8, 2016