Developing a Software Package – Sometimes the Nightmare Ends

I’ve posted two articles on what you need to think about if you’ve decided to develop a business software package. You might have a fantastically good idea, but developing, marketing, selling and supporting a package isn’t as easy as you might suppose. There’s far more to worry about than logical design.

The Nightmare

The Nightmare Continues

Have you thought about quality?

If you’re building parameterized software then it’s going to be capable of millions upon millions of permutations. Have you any idea how you’re going to test a sufficient number of these? Or even the most commonly used ones? The more that your package can do, the more ways it can go wrong. The quality level that you aim for is a matter of choice. Perfection is impossible, and near-perfection possibly unaffordable.

Have you thought about documentation?

You’ll need help text (and the capability of multi language help text), reference manuals, installation manuals, user manuals, training manuals, demonstration manuals, and so on. Your customers and resellers expect this (though don’t bother printing them). Electronic versions that can be accessed through a browser will do quite well enough.

How much of the product should you finish before you market it?

Your vision must be complete before you start, with an outline design for everything you intend to develop. You’ll want to sell your package as soon as you can, to make back your investment, but If you sell too soon, you’ll get diverted from your vision, and most dangerously, you’ll find yourself in obscure alleyways of customer-specific code. But if you sell too late, you’ll have used up all your money.

And have you thought of how you’re going to take your package to the market?

If you’re not yourself in possession of an international company, then if you’re going to sell beyond your domestic market you’re going to need distributors and resellers. You’ve got to see things through their eyes. How can they make money from your product? What will be their upfront investment, and their ongoing cost of sales? Is the balance between service revenues and licence fees the right one for them? Can they learn enough about the product quickly enough to be able to present the product and then implement it?

You need to think of the marketing material they’ll need, the return on investment arguments they’ll use, the contracts, the multi-lingual support service, the case studies, the training, the guidelines you’ll give on implementation duration and costs, and so on. If they can’t make money, then there’s no way you will.

And your pricing model has to be one that can, in theory, and even after discounts, return a profit.

But whatever you do, don’t try to set up a reseller network until you’ve won some deals yourself. When recruiting resellers, just as when selling to customers, references are everything.

How are you going to win your first customers?

Whether your first customer is your own or a reseller’s be aware you’re not going to make any money from the first few deals. Your first customers won’t buy your package, however unique, unless you give them a special deal and extraordinary service. It’s hard to sell without references. You have to ‘buy’ the first deals.

And have you thought about how you’re going to keep your development team happy during the long development period?

If you do lose a developer, is his code sufficiently well documented that another can take his place and maintain his code?

Have you designed a feedback mechanism so that your customers’ wishes are reflected in subsequent versions of your package?

If you don’t listen to your customers’ needs, they’ll soon stop paying for maintenance.

Have you made a prudent investment plan to take you from concept to sales?

If you can’t afford the long-term investment that package software requires – the employment, travel, technical and marketing costs that will take you to your goal – then don’t even think of beginning.

My company, systems@work, set out to develop software for professional services (and expense and forms management) more than a decade ago. Did we ask ourselves all these questions when we began?

Some of them, certainly, but by no means all. time@work is a ‘best of breed’ package for services organizations from accountants, engineers and lawyers, to architects, consultants and charity workers. It’s now used by more than 250 companies from Tokyo to Sydney, from London to New York.

If we’d known there were so many questions, we might never have started. During the first few years there were certainly times when we were close to giving up. But if there are two questions we certainly should have asked ourselves more aggressively, they are ‘How are you going to win your first customers?’, and ‘How are you going to take your package to the market?’

We’re securely profitable now, and my anxieties, if any, are operational ones rather than existential ones.

So, if you have a dream and you can answer these questions positively, and if you’ve got nerves of steel, then good luck. After all, someone has to write these packages.

Developing a Software Package – The Nightmare Continued

Last week I wrote some notes on what you need to think about before you start designing and developing a business software package (see Developing a Software Package). I suggested you shouldn’t even consider it if you’re of a timid or risk averse disposition. You’ll need more courage, more determination, more time and money than you ever imagined. You’ll need a thick skin, impervious to the disappointment and impatience of customers, colleagues and managers. It’s all much harder than you think.

I asked three questions:

Who are your customers?
Who are your competitors?
How are you going to make it simple enough but flexible enough to fit a broad range of customer needs?

Here are a few more:

Have you thought of the linguistic, national and currency issues?

If you’re ambitious and you see yourself selling to an international market, then think of what this means before you’ve written much code. The cost of trying to get this right at any later stage is terminal. So if you aim to provide multi-language capability, make sure your technology supports UNICODE (double-byte representation) at the database and software level. Find a Japanese friend to prove this aspect really works. Make sure you can handle transactions in more than one currency. In fact, think in terms of representing every transaction in your system in at least four currencies simultaneously (transaction currency, local currency, reporting currency, customer/supplier currency). And don’t forget to build sufficient flexibility to cover all the idiosyncratic national tax reporting issues you can think of.

Have you thought about technology?

In this area, don’t try to be too clever. Make sure you choose uncontroversial but up-to-date technology. Be cloud ready and design the software so that it can run in multi-tenant mode (one copy of the software serving multiple clients safely and securely). You can’t go far wrong MS-SQL, IIS, Internet Explorer/Chrome/Firefox/Safari and Windows. Don’t, whatever you do, let your programmers seduce you into using something ‘better’. Don’t be on the leading edge, hitching your wagon to some promising technology that might fail to win market share. Your customers don’t want to be pioneers. Be just that little bit behind.

How important is technical perfection?

It’s a cliché, but in software development, as elsewhere, ‘perfection is the enemy of the good’. If you aim to do things perfectly it’s going to take far too long, and you’ll always fail. So be aware of that when you’re starting. Set yourself guidelines. Have the good sense to know when something’s good enough.

Have you thought about how you’ll manage the technical aspects of licensing?

If your package is modular, and you’ve priced it accordingly, then you’ll need a mechanism for restricting access to components of the system, even if your installation program installs the entire software suite and database. And you’ll need a way of limiting a license period, so that you’ve got some way of making your customer pay you.

Have you thought about the techniques you’ll use for installation and upgrade?

Installation has to be fool proof. Don’t depend on your software falling into the hands of IT specialists. It has to be consumer proof too. Don’t depend on the user having to download additional components from Microsoft or other vendors to make it work. They won’t read the manuals, they won’t understand the error messages and they won’t do it.

Version control is also essential. So is easy upgrade. You’ve got to provide new functionality and bug fixes with easy installation and guaranteed forward compatibility.

Some final thoughts next week….

Developing a Software Package – Dream or Nightmare?

In the world of business software development there’s nothing more fun and more challenging than designing packaged software, software that’s designed to adapt itself to the particular circumstances of each customer, without software modification. Basically you’re building software that’s packed with parameters and switches to make it work one way or another. This can be elegantly and well done if you get it right at the start, but if you’re led this way and that way by the demands of each particular customer, you can end up with a dog’s dinner.

Either way, it’s an expensive venture. It costs more to develop this kind of software than code that’s designed for just one purpose, because it takes a lot more time, but the reward, when it comes, is that you can sell the same package time and time again. There’s just one body of code to look after. So, if you’re an expert in a particular area of business, and if you’ve got the right logical imagination, it’s surely an opportunity not to miss.

Or, so you might think.

I’ve done it myself. I’m the designer of systems@work, a single software package designed for professional services management (time@work), expense management (expense@work) and workflow (forms@work).

I’m typical of many a programmer who spent years writing one-off programs for specific businesses. I developed a practice management system for Coopers & Lybrand, in Paradox, from scratch, and adapted another software package for KPMG for the same purpose. So it occurred to me, as it does to so many of us, that if I could only distil what’s common from all the code I’d written or adapted, I could design a single all-purpose package that would, with appropriate parameters and switches, do everything all at once.

People like me dream of a few months’ fervent coding, and then, almost immediately, a crowd of buyers. We dream of license and maintenance revenues rising exponentially, and finally, at the end of the rainbow, a buy-out proposition from an enormous corporation (preferably beginning with M). The rest is a pleasant after-life that won’t involve work.

We know we can do this. We, alone, have that very special idea. We’re up to date with the latest technology. Why not begin at once?

But if you wake up one morning in the after-glow of a dream like this, then close your eyes and dream of something more sensible, like winning the Singles Title at Wimbledon. Only if the dream returns incessantly, and if it survives all the scepticism you can throw at it, should you begin to take it seriously.

But before you spend every last penny of your own or your company’s money, have another cold shower or two and ask yourself some questions – at least sixteen of them.

Here are the first three:

Who are your customers?

There’s a world of difference between the package software market and the market for custom-developed software. Your customers are going to be those who realize that there’s ultimately more security in a general purpose package that’s going to adapt and grow with their business, than in a piece of one-off code for which support may not be eternal.

They’re going to be customers who understand that they won’t use everything the package does, and who will compromise their own needs if the fit is good enough. They are simultaneously buying more than they need, and less. So be ready to sell the idea of compromise. Beware of promising a long list of enhancements to every customer who’s interested, because If that’s the route you choose, you’ll end up with an ugly amalgam of cobbled-together code.

Who are your competitors?

If your customers have decided on a package, then they’re not only going to look at yours. Let’s face it, most software markets are pretty saturated already. At the top end there’s Oracle and SAP, and if you’ve got enough money to buy them, those systems will do just about anything you need. But even if your customer is in the mid-market, then there’s still a crowd of mid-market systems for him to choose from. Does Navision, or SunSystems, or Great Plains, or Exact, or Scala already do exactly what you’re thinking of? Or nearly do it? It’s unlikely that you’re going to write a complete system that covers a company’s needs from payroll, to accounting, CRM, manufacturing, and distribution.

You’re insane if you’re going to embark on a completely new package that fits the ‘integrated’ model. Rather you’re going to be going for the ‘best of breed model’, with the idea that your piece of software is so special that your customers won’t mind fitting it into a tangle of other modules from other package systems. So whatever else you do, make sure you design open interfaces to a broad range of third-party products.

And keep asking yourself, do you really have some special knowledge that will make your software special?

How are you going to make it simple enough but flexible enough to fit a broad range of customer needs?

This is the difficult part to get just right. If you’re going to appeal to sufficiently large numbers of customers to cover your investment, your package is going to be complex. It’s going to have screens of parameters that make it work one way for one customer and another way for another. After all, if it’s a package, you’re only writing one piece of code. If you end up with multiple versions for multiple needs, then your dream will become a nightmare before you’ve even sold five copies. So, think about your market, and choose just enough of it to make your coverage sufficient whilst making it possible for your customers to understand the software they’re buying.

Designing systems@work – with a little inspiration from SunSystems

I’ve spent the last few years designing systems@work’s time@work (for professional services management), expense@work (for expense management) and forms@work (for forms and workflow management), three highly configurable software packages all inspired by SunSystems financial and business software.

SunSystems was developed by colleagues of mine who formed Systems Union in the 1980s. It’s still the mainstay of LLP Group, a SunSystems reseller and consulting group which I founded in Prague in 1992.

SunSystems’ excellence lies in a few remarkably simple concepts:

A single ‘unified ledger‘ handling accounts payable (AP), accounts receivable (AR), general ledger (GL) and fixed asset ledger transactions. Accounts of types Creditor, Debtor, Client (both Debtor and Creditor), Profit & Loss, Balance Sheet, and Memo accounts all co-exist in a single chart of accounts. The unified ledger idea actually spawned at least two well-known accounting software systems – CODA, and SunSystems, both British.
The use of transaction analysis codes instead of structured general ledger codes for the purposes of management accounting and statutory reporting (VAT reporting, for example). An analysis code need be set up only once, and then selected and posted during journal entry to any account that is defined as requiring it. The chart of accounts thereby remains simple.
The option to set up additional analysis on other entities (such as Account Codes and Asset Codes) for reporting purposes (this makes the translation of reports from corporate to local account codes easy, or vice versa)
The use of parallel ledgers for budgeting or alternative treatments (e.g. alternative asset depreciations). Each user-definable budget ledger has the same structure as the ‘Actuals’ ledger.
The option to enter ‘other amount’ and ‘currency code’ values on any transaction in any ledger (in the latest version of SunSystems you may enter five amount fiels and four currency codes)
The use of additional ledger fields for asset codes, etc.

The result is an extremely simple, easy to understand, ‘flat’ structure (reflected in a non-normalised database) that is nevertheless extremely powerful and flexible. In terms of database tables, the essentials include:

A Chart of Accounts table
Ledger tables (an ‘Actuals’ ledger and a number of parallel ‘Budget’ ledgers)
Optionally, a Fixed Assets table

Everything else is merely supportive.

The advantages are many:

No issues reconciling AP, AR and GL
Reporting tools that can range easily across transactions on any type of account and in any set of ledgers
It’s easy to set up new analytical dimensions at any time
It’s easy to handle multiple currencies (typically local currency values that must balance, transaction currency values (e.g. foreign expenses), and reporting currency values (enabling consolidation of several ledgers in a single corporate currency)

The product was also designed with language translation in mind – all textual terms being held in files external to the program files.

It’s not surprising that SunSystems remains an excellent choice for corporations planning to use a single system across the globe. It can be rapidly implemented in a standard way, meeting corporate and local requirements simultaneously.

I spent many years implementing SunSystems in many parts of the world and came to appreciate the powerful simplicity of its design. In designing time@work I adopted many of these ideas and in some cases took them one, necessary, step further:

A single ‘Actuals’ ledger containing transactions of all kinds, whether originating in timesheets, forms, invoices, or attendance forms
Any number of parallel ledgers of exactly the same structure for planning and other purposes
Analysis values on transactions (the same set of 50 dimensions available for use on timesheets, forms, and invoices across all ledgers)
Analysis on entities (Clients, Projects, Tasks, Employees)
Multiple value fields on each transaction (20 values, and 20 ‘currency’ codes to identify the currency in which each value is expressed)
Reporting tools that can range across multiple ledgers
Data Dictionaries accessible to the end-user where different language texts are held, as well as industry specific textual alternatives (e.g. engagement, or case, instead of project)

Where I extended the design was to enable multi-company functionality in a single database, making it possible for an organisation to define one set of projects and one set of employees for use group-wide. In a professional services organisation this makes it easy for an employee belonging to one company to report time or expenses against a project belonging to another company, and makes it possible for an employee in one company to manage employees and projects in another, and to be involved in workflow regardless of the company to which an employee or project belongs.

Multi-company capability, though, implies at least the following:

The need to handle multiple base currencies (an organisation may be operating in several countries but may still need to see employees and projects as a single pool). Holding the currency code on each of twenty values in every ledger transaction makes this possible.
The need for multiple charts of accounts. When transactions must be sent from systems@work software to one or more finance systems the appropriate transactions for each company must be easily identifiable and must be constructed using the appropriate account codes for the destination ledger
The need for separate invoice sequences
The need for separate sets of expense types, each appropriately implying a general ledger code

Achieving all of this, whilst retaining simplicity on the surface has been our aim. The result is a set of simple components that can be assembled in millions of different ways to meet the needs of a wide range of organisations, without software modification.

systems@work works with any finance system, but it’s conceptual similarities with SunSystems makes it an ideal extension for timesheets, expenses, planning and billing. Contact me for more information.

Don’t Take the Source Code

The most difficult questions are the most open ones. What would you do if you were Prime Minister? Better to be asked specific questions: What would you do about school dinners, or Iraq, or capital punishment, or conscription, or food labelling or the railways? If the questions are more particular then you’ll probably have an opinion, or at least something to say.

I remember English composition lessons at school. Write a story, the teacher would say, and I wouldn’t know where to begin. Write a story about four-eyed Martians and I’d know where to start. Complete freedom is paralysing. When everything is possible, nothing comes to mind.

For somewhat different reasons, being able to do anything at all with business systems is also terrifying. Partly, perhaps, because you don’t know where to start, but ,mainly because you don’t know when to stop.

Although nothing falls entirely into one or the other category, you can roughly divide business systems into those where you get the source code, and which you can do anything with, and those where you don’t get the source code, where possibilities are constrained.

I like constraints. When there are constraints, possibilities are very many fewer, and there are clear choices to make. This is the better situation.

Of course, if you get the source code you can build something that does exactly what you want to do (well, what you want to do NOW), but it will take you forever and cost you an infinite sum. When you don’t get the source code you may get 90% of what you want at a reasonable price, and soon. Moreover, you will find upgrades immensely easier.

I worked years ago, as a consultant, with an oil company that decided to take one of the largest business systems in the world, adapt the source code and implement it globally. The project was immensely expensive, took far longer than planned, and when the system was ready it was already out of date and impossible to upgrade. The system was abandoned in favour of another even bigger one that needed less adaptation.

And at LLP Group, a software reseller, where I work, we had two divisions – one selling Microsoft’s modifiable Dynamics software, where our projects were often disastrous, and one selling Infor’s non-modifiable software, where our projects were manageable, satisfying and profitable.

Don’t touch the source code!

Too scared to visit the doctor

For many months, a year or so ago, I was scared to visit the doctor. Not because I feared an alarming diagnosis. I could never be afraid of my delightful and kindly general practitioner. Rather, I was afraid because my company, LLP, was fortunate enough, about four years ago, to win a contract to implement a CRM (Customer Relationship Management) system for the company that owns the clinic. And now they were using it. So I was petrified of the administrators, not the medical staff.

Medicine is a big and complex business and it has to be run commercially. Appointments must be managed efficiently and bills must be produced promptly and accurately. This is what they wanted help with. So we sold them software and consulting to handle the scheduling of appointments and the generation of invoices, holding all the variations in price that depend on complex combinations of factors.

The implementation of our software took several months, and was not unlike the progress of an illness – good days, bad days, some pain from time to time, anxiety, progress, and then, eventually, the launch. So when the system went live, visiting the doctor became my chance to find out, incognito, what the end-users (amongst them the clinic’s receptionists) thought about it.

The difficulty was that I could see them struggling. They didn’t look happy with it at all.

As we all know, there’s a predictable double fall and rise of mood from the moment of software sale to the moment a system works well.

When a system is sold, expectations are at their highest. After a few weeks of system implementation and the realisation that packaged software systems can’t do everything, the mood plummets. But then, with workarounds and modifications, and as ‘go-live’ approaches, the mood lifts once more.

But then, when the system is live and things immediately go slightly wrong (as, sadly, they often do, however much training and testing you do) the mood declines again. Finally, step by step, bug by bug, day by day, as problems are solved and users get used to the new software, the mood improves again.

So, for a while I could see them struggling, and if I felt brave enough I would ask them about the system. They were kind. There was some problem with printing, they said, (system crashes in fact, when they clicked the Print button) and there were other things they didn’t love. But they soldiered on, even if without joy.

But now I’m not afraid. I went for some physiotherapy just yesterday and for the first time I heard those very consoling words, ‘It’s really great, so much better than the system we had before.’

You don’t often get the chance to hear an honest opinion from the end-users of a system if you’re the supplier, and in my profession we often feel reluctant to hear it. But in the end, it’s important to know, and this story had a happy ending. The system was responsive to treatment, and now it’s been pronounced fit.

Adam Bager

Occasional thoughts on IT, Business and Other Matters

Tag Archives: software packages