Once, social landlords used software applications that had been developed inhouse or as bespoke solutions by contracted developers. At first these systems delivered huge advances in productivity and were well regarded. However over time, they became unwieldy, difficult to maintain and, in the worst cases, impossible to develop.
Lack of documentation and staff turnover could result in a phenomenon known as SOUP (software of unknown provenance), an application which the owner dares not alter for fear of unknown and possibly catastrophic consequences. The chief cause of this problem is that the understanding of the purpose and workings of the application is concentrated within a few developers; people who are notoriously averse to documenting their knowledge for others to share and who may no longer be around to ask.
The applications themselves would also reflect a single organisation’s attempt to solve its perceived problems without reference to other practitioners, thereby entrenching existing business practices, however arcane or perverse, when seen from outside.
Packages arrive
In response to this unsatisfactory state of affairs, during the 1990s commercial off the shelf (COTS) software emerged promising:
- Lower total cost of ownership due to the development and support costs being shared between many customers;
- Quicker implementation and easier maintenance due to documentation and vendor best practice learned from previous projects;
- Design input from many sources resulting in welldesigned and highly-functional solutions, with market competition continually driving development and improvements.
These products dominated the scene throughout the nineties and early noughties and some suppliers became dominant players in the market.
Maturity
The demands of competition law have historically led to procurements being conducted as ‘beauty parades’, in which a specification is published and bidders are pressurised to tick as many boxes as possible. This can become a ‘wish list’ in which (often dubious) requirements are included in order to get bidders to commit to as many features as possible. This has caused some ‘feature creep’, compounded by the commercial necessity of parameterising everything to enable the client to retain preexisting processes and codes.
Complexity brings challenges
The development of complex applications is prone to undesirable behaviours termed ‘antipatterns’. When the vendor tries to accommodate many clients without exerting strong leadership, ‘committee compromise’ can result and the product fails to be sufficiently useful to anyone. ‘Groupthink’ can arise from an overwhelming desire to achieve consensus within the ‘in-group’ and legitimate criticism from the ‘out-group’ is suppressed, resulting in irrational decisions. Uncritical thinking can also be manifested as ‘cargo cult’ development, in which dysfunctional or useless software can persist because nobody has the knowledge or courage to challenge it.
Perhaps the most familiar antipattern is ‘vendor lockin’. Enterprise software is not a commodity. Demand is inelastic due to the cost of switching and reluctance to lose the investment already made. Lockedin customers may experience many disadvantages: they must comply with the vendor’s chosen technology platform (and if the vendor itself is locked in then it’s likely that this will be out of date and expensive to support); integration and reporting may be poor; the vendor may not be able or willing to develop the application to respond to the customer’s needs or industry changes, particularly if it is driven by corporate concerns rather than any specific consideration for the housing sector.
Some vendors deliberately seek to lock customers in and even to remove escape routes; a certain global leader was found during its US anti-trust trial to have internally described its strategy for open standards as ‘embrace, extend and extinguish’. They can continue to make money from customers by taking care to stay below the tipping point at which the customer decides that the cost of replacement is worth bearing. This behaviour is sometimes unconscious and is manifested itself as the supplier attending to customers reactively and often only when the relationships become seriously damaged.
Vendors can manipulate the tipping point by improving their own offerings so as to foment dissatisfaction among their competitor’s customers, thus lowering their tipping point and creating a chance to win them over. This is true competition at work.
A customer who has reached the tipping point usually wants to ‘wipe the slate clean and implement newer, simpler solutions which correct the perceived errors built into an existing COTS system. They may opt to switch suppliers, commission a bespoke solution, partner with a new market entrant or even go down the build it yourself (BIY) route. How might these approaches work out?
Economics of software development
The main commercial rationale for COTS software is that the development cost can be shared between customers, and should therefore be more costeffective than bespoke solutions. This would not be true if the vendor price was distorted by lockin, or if somehow it were possible to develop a bespoke solution much more efficiently (usually articulated as ‘we have a really good IT department’). Products can be priced using different strategies, but price will usually change as the product moves through the adoption lifecycle (see figure 1). During early phases, the vendor invests in development in the hope that they can successfully transition the product from enthusiasts and risktakers to the more pragmatic Early Majority. This is known as ‘crossing the chasm’ after Geoffrey Moore’s seminal work on entrepreneurial marketing.
Another way of illustrating this is shown in figure 2, which illustrates cumulative spend vs. cumulative revenue. At the minimum viable product (MVP) point, the product contains essential features and at optimum viable product (OVP), it is fully featured; further spend is wasted unless it is exceeded by RoI which would result in the revenue curve continuing to rise. For COTS software vendors, the RoI traditionally comes from recurring support and maintenance, and maintaining competitiveness in the new business market.
Social housing is complex and it requires sophisticated solutions. Time-to-market for such a product is long and the initial spend before reaching MVP is very high indeed, so it is a brave supplier with deep pockets that attempts to break into the market. There is no magic way to develop solutions more cheaply, and this spend has to be subsequently recouped from customers.
Some simple word maths: the margin a vendor makes is the difference between its total revenue from multiple sales minus the development cost. For the product to be viable, the margin must be positive. With a bespoke product, there is only one sale and so the margin is simply the difference between the price and the development cost, so the price must be much higher in order to balance this. In a BIY project there is no margin to pay, but the development cost is borne entirely by the housing provider; it is hard to see how a product that has cost the vendors millions to develop can somehow be replicated significantly more cheaply. A bespoke or home-grown solution requires the same level of ongoing development and maintenance and worse still, inevitably begins to resemble SOUP (see above).
Some would say that the incumbent HMS products in the housing sector are overly complex, but one needs only to read any ITT specification to debunk this; the drive for ever more functionality and flexibility is unrelenting. It is easy to characterise the operations of housing providers as a simple business of maintaining properties, letting them and charging rent, but when examined more closely, there are myriad automations provided by the existing solutions which are relied on daily and without which productivity would suffer drastically. It is unsurprising that independent consultants usually advise housing providers to leverage their existing IT investments and to work better with their current supplier rather than spend huge sums of money buying something they probably already have.
Suppliers fit for the future
To paraphrase Heraclitus, ‘change is the only constant’, and the perfect IT solution can never be reached, regardless of whoever creates it. What is important for suppliers is that they continually strive to keep up with industry’s needs, demonstrate a longterm commitment to the sector and work in true partnership so that risk and reward can be shared. Commercial models may have to change as housing providers increasingly engage in commercial activities; SaaS, open source and licensing based on alternative scalars such as revenue or transactions may be useful alternatives.
The IT solutions for housing providers can be broadly summarised thus:
- Housing core business: tenancy management, income, allocations, and maintenance;
- CRM: communications and contact management, service management, and sales and marketing;
- Back office: finance, HR, payroll, workflow and collaboration;
- Information management: reporting, business intelligence, and business planning.
It must be cloudenabled, mobile, flexible and customisable. It must support any platform, including those chosen by your staff and customers, and must support open integration standards.
This is the list today. Who knows what will be added tomorrow? To be ready for change, the solution must be agile, but more importantly so must its supplier.
Aidan Dunphy is head of product strategy at Orchard.
