Just as…

Just as playing a musical instrument or singing musically is far more important than playing or singing accurately (indeed, a friend of mine sings the right notes only rarely, and most of those accidentally, but his musicality is profound – imagine a male version of Florence Foster Jenkins), and just as a good consultant needn’t know anything about anything in particular (it’s more important that he or she should look smart, ask good questions and listen well, than spout dry technical truths), and just as sales is more about being liked than knowing something about what you’re selling, and just as speaking eloquently is more important for a politician than having anything useful to say, so what software actually does is far less important than how it looks.

Well, perhaps I exaggerate, but there’s an iota of truth in some of this nonsense and I’ve reluctantly accepted the view that what’s called the ‘functionality’ of software (how I hate that word, but continue to use it) is by no means the only thing that matters.

I design a configurable software system called time@work. It’s designed for Professional Services Organisation such as lawyers, engineers, and consultants, indeed any organisation that needs to record the time and expense incurred on projects. We have nearly 300 customers around the world, and we meet our customers requirements without needing to change the underlying software code – we click and build and configure the basic software to do millions of different things.

Of course, we bring out new versions from time to time, and most of the changes we make are inspired by our customers’ needs. We add new options and checkboxes and functions, and I doubt that we or our clients will ever run out of such ideas, but we keep fast to the rule that we’ll only have one version that’s ever more capable. I was once a programmer (and yes, once a programmer, always a programmer (it’s like being a Roman Catholic, I believe)), and it has often seemed to me that adding more ‘functionality’, ever greater capability, is more important than anything else. More important, for example, than that the system should look attractive.

But of course I’m wrong about that, though less wrong than I used to be, and I have to remind myself from time to time of that old adage in the business software implementation that projects fail more often for other reasons than that the software doesn’t do exactly the right thing.

That doesn’t mean that you can use Microsoft Word as a manufacturing requirements planning system, or Microsoft Excel as an airline booking system, but there’s a grain of truth in the idea. Configurable software such as ours, however brilliantly conceived (!), doesn’t always do exactly what customers want, and there must always be flexibility and imagination and compromise on all sides if an implementation project is to succeed. You can concentrate on nothing else but ‘functionality’ and you’ll never produce an infinitely capable system. A year of software development work might take you from a 94% fit to a 94.5% fit.

The problem is that if you concentrate only on capability, you’ll neglect those things that sometimes seem more trivial to you if you’re a programmer – the graphical look and the ‘usability’ of the system. If there was a road to Damascus for me, it was in the development of our iPhone App. Developing the systems@work App was a great lesson. The world of Apps is unforgiving and to succeed you must meet higher standards of attractiveness and usability than in the kind of software that’s used in the dark corners of accounting departments.

And so, in the recent version of systems@work’s time@work, expense@work and forms@work we’ve spent time and money on making the software look a lot nicer and easier to use. I don’t regret it. We released Version 6 a few weeks ago and it’s been received with enthusiasm by customers and resellers alike, and I, too, find it a greater pleasure to use.

This took months!


There’s still more to do. Weeks of programming time can be consumed in making paging controls and field lookups look consistent across the system, but we’ll continue. That’s not to say that checkboxes here and there that add to the capability of the system will be entirely neglected, but for a few weeks ‘functionality’ must take a back seat.


systems@work Version 6 -We’re Nearly There!


We hope to release systems@work Version 6 in the coming days/weeks. Today was the first day of the gradual release process – a first release of a pre-release version to me and to a few of my colleagues.

The next step will be the upgrade of our LLP Group system on Friday, so between now and then we must iron out the most alarming and noticeable bugs.

But I’m already pleased with what I see.

My first step, on receiving the new version this morning, was to upgrade a standard time@work demonstration database. The new Home Page looks like this:


We’ve narrowed the page header to allow the display of more transactions. We’ve arranged all immediate actions into a To Do panel and an Approval panel, we’ve provided a Shortcuts panel, and we’ve arranged the functions of the system into a tab strip.

It is easier to work with and it looks more modern.

Reports can now be arranged into Custom tabs (such as Timesheet reports, Utilisation reports, Realisation reports, Audit reports, and so on).


There are also new ‘Static Data’ reports that enable you to list Employees, Clients, Projects, Tasks and Analysis Values, and you’ll be able to use Ledger Export (and Task Scheduler) for exporting such data to external systems.


We’ve also revised the way in which destination email addresses can be defined for invoices. You may define one or more roles (such as Project Manager, Client Project Manager, and Company Accountant) as the default recipients, and also allow the editing of the recipient list at invoicing time.

During the next forty-eight hours we will correct the most obvious problems, upgrade our own systems on Friday, and then prepare an official release for mid- to late July.

Why the delay?

  • Help Text
  • Documentation
  • Standard Demonstration Databases
  • Bug Fixes
  • Release Notes

There’s still a lot to do.


Announcing systems@work Version 6


Version 5 of systems@work’s time@work, expense@work and forms@work was released at the end of 2015. It contained a number of enhancements, most of them enthusiastically received and put to use.

Version 6 will be released in early July. It seems soon for a new major release, but the radical revision of the browser-based Professional Services Workbench warrants it. Gone are the variously muddy-coloured lists of functional options, to be replaced by dynamic tabs, panels, links, and shortcuts.

Our aim has been fourfold:

  • To comply with current standards and graphical fashions
  • To present the user more clearly with To Do lists for data submission and approval
  • To enable navigation with fewer clicks
  • To make navigation pages responses to the user’s device (responsive design)

The result is a Home Page (for time@work) that is more pleasant to look at and easier to use.

Version 6

And list pages that look more modern:


Version 6 will also contain the following enhancements:

  • A new reporting option that allows you to report on and export static data (such as Employees, Clients, Projects and Tasks). This will be of particular benefit for integration.
  • Credit Notes in the browser-based PSW
  • Enhanced emailing options for Invoicing, including an option to select an Employee as a destination and to allow emailing to multiple email addresses
  • Workflow Control for Timesheets to allow diversion of a timesheet from one authoriser to another


Fixed Price and Agility

I’ve come to love ‘agile’ systems implementation methods, and they are rightly fashionable in the nerdy circles in which I move.

But when I was trained on business software implementation methods many decades ago, I was told that it had to go like this:

  • find out what the customer wants, and write it all down,
  • get his sign-off on the requirements document,
  • design the system, and write it all down,
  • get his sign-off on the system specification,
  • build the system,
  • get his sign-off on the system,
  • and so on.

It didn’t work well. In the first step you might get it nearly 95% right, though there was still a danger that the customer didn’t know what he wanted until he’d seen what he might get.

But the second step was usually the dangerous one. If you’d gained the customer’s trust by the time you’d put the specification in front of him, he’d usually sign it off, even if he had no idea what it meant. System specifications are usually written in an inhuman language using the terminology of the target system. Crucially, they convey nothing at all about what it might be like actually to use a system.

The system build would often happen somewhere far away in a software laboratory, to which, of course, the customer would usually be denied access.

And then the last step didn’t happen, because when he saw what you’d built he wasn’t usually very happy.


This was the old-fashioned ‘cascade’ method and it’s rightly out of fashion. The ‘agile’ method involves more frequent meetings, discussions and demonstrations, so that the customer sees what you’ve understood, what you’ve designed, and what you’ve built and can quickly tell you if you’ve got it wrong before it’s too expensive to change course. When you’re implementing highly configurable software systems such as our time@work, expense@work or forms@work products, or Infor’s SunSystems, prototyping is relatively easy and this method is perfect.

At systems@work we’re doing a big implementation project for a fund services provider. It involves expenses, vendor invoice management, billing, timesheets and lots of workflow and reporting, and all the accounting that goes with all the transactions that are implied. Yesterday we conducted an important  prototyping session, and I’m happy to say that it went well. There are a few things that we must change, but there are no fundamental misunderstandings.

But what about the agile method when a project is a fixed price one? Isn’t it potentially a recipe for disaster, in that changes of course are unpredictable and there’s no single moment when you can pin down the project scope in a system specification and treat all subsequent changes as separately chargeable?

This is not an easy question to answer. Wise and experienced project managers will build in a large ‘contingency’ component and perhaps put more emphasis on getting the requirements document right (even this stage of the project can involve proof-of-concept prototype demonstrations). But if you allow changes at later stages it’s hard to charge extra for them.

There is no perfect method. I would only say that if you believe the old ‘cascade’ method is a better one for large fixed price projects you are probably deluding yourself. You may be able more easily to define what’s out of scope, but it will be no easier to obtain the customer’s agreement that he should pay for all the ‘mistakes’ and scope creep, whether they are demonstrably his fault or yours.



Keeping Up Appearances


Fashion can catch up with you without you even noticing it, until suddenly it’s nearly too late. I don’t mean skinny jeans, or leg warmers, or platform heels or first press extra virgin olive oil. Rather, I mean the way that software should look. What was modern and attractive five years ago looks worn and dated today.

Fashion creeps up on you gradually. At first there’s just a murmur, but as the years go by you hear it more and more – yuk, that’s not a very attractive interface! You ignore the criticism for a while, thinking that what software actually does is far more important than how it looks, but you’re foolish if you go on doing that for long. The problem is, of course, that it takes more than a few days to redesign and rewrite the surface layer of business software.

There’s also the issue of devices. We may still do most of our work on PCs or Macs but at times we’ll reach for our mobiles and tablets to do serious things there too. So interfaces must nowadays use responsive design techniques, so that a webpage will rearrange itself to suit the device it’s running on.

systems@work is a software author. We’ve developed a professional services management system – time@work , an expense management system – expense@work, and a forms workflow management systems – forms@work. All are different ways of configuring the same underlying systems@work software. It’s mostly browser-based software that runs on any browser with some configuration work managed through a back-office desktop tool.

We’ve been successful. The UK’s MPs use our software to record their Parliamentary expenses (we’re the solution not the ‘scandal’ that happened seven or so years ago). Consulting, IT, legal, pharmaceutical, financial, NGO and software development firms use our software all over the world. We have more than 40,000 end-users.

This is the browser Home Page that our current users use and love:


Yuk?! Well, not entirely. The options available to the user are clearly laid out in sections related to the functions of the system. Everything is more or less one click away. I hardly notice the interface when I do my timesheets, expenses and run my reports. And that, perhaps, has been the problem. I’m so used to it I haven’t noticed that by today’s standards it’s a bit dull and out of date.

I’m the software designer and I’m confessing that in this respect we’re not up to scratch because now that we’ve released Version 5, we’re working on a redesign, hoping to release Version 5.1 in about three months’ time.

We’re changing buttons, fonts, and other bits and pieces, but the big changes will come in the way the system can be navigated.  As well as adopting a more fashionable style, we’re going to ‘advertise’ the system’s options more noticeably and provide configurable shortcuts to diaries, skills databases, and reports. And instead of scattering notifications of things you’ve got to do across the page, we’ll list tasks, upcoming consulting allocations, and news in one easy to read ‘Today’ tab.

The Home Page is going to look more like this.


I think it’s better, but it’s work in progress, and I’m open to suggestions.


Why Consultants Love SunSystems


There was a time, many years ago, when the future of SunSystems was uncertain, though everything looked wonderfully rosy at the time. Systems Union, the British company who developed the product, was still in friendly private hands, and sales were booming. SunSystems was the best (as it still is) international financial software system on the planet. Those of us whose lives depended on the product were prospering. Actually, Systems Union’s  P&L looked good. The problem, the company’s balance sheet, was probably one of inattention. The sails were billowing, the sun was shining. They just didn’t notice the rocks beneath the surface.

Resellers such as our company (LLP Group) enjoyed unusually comfortable payment terms and Systems Union’s dunning style was gentle and ineffective. It was a cosy, successful, touchy-feely company and we were all one happy family. They even took all of their employees on expensive foreign holidays, and, on one occasion, some of us resellers too.

They had also embarked on huge enhancements to SunSystems, both functional and technical. GUIs were new and improving rapidly (yes, we’re talking about many, many, years ago) and COBOL, which they were using them, was an impediment to some of this. All these development projects were late and ever more expensive programmers were being thrown into the development den.

And then there came huge devaluations in Asian currencies and debtor and cash values at Systems Union’s successful Hong Kong offshoot had to be revalued down. All in all, the balance sheet didn’t look good, however bright the operating profit.

So, many resellers looked for lifelines, just in case. We looked at SAP R3. As it turned out, this was an expensive and very instructive mistake.

barbie and ken

It would be wrong to suggest that I had thought of SunSystems as a toy. Its simple and elegant building blocks come in a relatively small kit, but, just as with Lego, you can build nearly everything with them. But I had certainly thought of SAP R3 as a ‘grown up’ product, and just as when we’re young we dream (foolishly) of getting ‘grown-up’ versions of toy cars, toy guns and Barbie dolls (or Ken), so I had assumed that our consultants would enjoy the upgrade to SAP R3, a chance to become adult in the ERP consulting world.

SAP was then trying (it still is, perhaps) to come down in the world by selling to mid-sized companies rather than only to the largest ones, so they leapt at the opportunity to work with a company such as ours who knew how do deliver projects in under hundreds and thousands of days.

So we sent out best SunSystems consultants on SAP R3 courses. This one would learn about the inventory control module, this one about the sales module, that one about the asset register, and so on. And therein lay the problem and the reason why our consultants, unexpectedly, hated the whole experience.

Their worlds shrank, and their horizons shortened.

The wonderful thing about working with SunSystems is that you can know the whole product, understand the whole of the company you’re working for, and design a complete solution. You can see from one end of an organisation to the other, from sales discount policy to the resulting debits and credits, and the management reports that international managers need. This wasn’t the case with SAP R3. You just couldn’t know everything.

And the style of the product turned out to be different too. It may be an imprecise analogy, but if SunSystems is like Lego, a small number of small components from which you can build just about anything, SAP R3 is more like a vast array of very large fixed-purpose machines that you have to put together, joining up all the wires and cogs and panels, unsure if they really fit together. The consultant who knows this machine, doesn’t know the others.

Those of us who work with SunSystems love its simplicity and the infinite possibilities that follow from it. Consultants can use their imagination to configure what the customer needs, albeit sometimes with workarounds (equally necessary in SAP R3 I believe). There’s no coding to do, unlike with SAP R3, and in any case coding isn’t possible.

Customers love it too. In some cases they’ve even ‘downgraded’ from SAP to SunSystems. In other cases, when they’ve grown and ‘grown up’ into SAP R3 they express nostalgia for the flexibility and relatively low cost of ownership of SunSystems.

SunSystems is an ideal consulting product. If you’re proficient in it it’s like a musical instrument on which you can play any tune. I’m happy to say that all of those SAP R3 consultants we thrust into adulthood are back in the SunSystems world, and all the happier for it.

See LLP International.

And when I came to design our own products – time@work for professional services management, and expense@work for expense management – I took inspiration from SunSystems and not SAP. I designed it as a set of building blocks, like Lego.

systems@work App – A New Version


Learning how to develop and manage Apps has been a difficult and essential experience for our development team at systems@work. ‘Mobile’ is the buzzword these days, even if last week it was ‘Cloud’.

We recognised three or more years ago that we needed to develop an App for our largely browser-based ERP software – time@work for Professional Services Management, expense@work for Expense Management, and forms@work for forms workflow management. In some ways it’s not easy for traditional ERP developers and consultants such as we are to learn the new tricks of the App world, but if you’re in the business of packaged ERP software you’ve got to keep up with technology and be near the leading edge, if not quite at the edge itself. Just as the browser revolution demanded that we think in a different way both technically and in terms of user experience, so the App imposes new demands. Apps must be even easier to use, indeed almost a joy, manipulable with a single finger or thumb. But making the complex seem easy is always a challenge with complex business applications.

The tradition with Apps is always keep it simple, or, rather keep it looking simple and easy to use.  Specialist terminology must be avoided, and functions must be intuitive and easy to use. The space you have to work with is small, but nothing must look cramped. Obviously there’s no point in crying RTFM when users complain that they don’t know what to do next. If your Granny can’t use it, you’ve probably failed the keep it simple rule.


But ERP systems are complex, and our systems@work software is highly configurable. It’s all about forms – forms for expenses, forms for absence requests, forms for recording time on projects, forms for stock movements, forms for this and that. You can configure a form to do any number of things, offering different fields with different lists of items, calculations with different rules, and so on. You can also attach photos and record voice memos and use forms in any number of different languages. You can also set up any number of form types and control who sees which ones.

All the lists, labels, definitions and rules that form types need are held by our system in a central database. So we have to make everything work with a single App, an App that can read and download these rules and interpret them on your mobile device. Moreover we need to make this download work swiftly. You can’t keep Granny waiting.

Apps must also work whether you’re online or offline. Actually, that’s not a necessity, but given that the rules that govern forms must be downloaded to the simple database that sits inside your mobile, then why not? Some of our users have been clamouring for years for a way to enter their expenses offline whilst flying, for subsequent upload in the Arrivals Hall. So it was part of our plans to produce an App that could be used offline as well as online.

We set ourselves these objectives:

  • Our App must be easy to use
  • Our App must look good
  • Our App must work with any configuration of our software
  • Our App must work offline and online
  • Our App must be fast in terms of upload of data and synchronisation

iPhone technology is very different from the Microsoft technology we were used to, and we had a difficult choice, either to find an iOS expert and teach him or her how our system works, or retrain one of our programmers on iOS technology. We chose the latter but had recourse to App expertise when we needed it. Even so, it took nearly 18 months to develop the first version of our App, together with all the server-side web services we need to serve it.

Take up is gradual but accelerating, and yesterday we released Version 2.0, taking account of immediate feedback from our users. We’ve improved usability, extended the use of the App to include form authorisation, and improved graphics. In the coming weeks we’ll release an Android version, and in the coming months a Windows Mobile version.


There’s also one more challenge that ERP software authors face – how to manage the release of App versions. The problem is that ‘delivery’ is uncontrolled. Release an App to the App Store and everyone gets it almost immediately. It’s got to work first time for every Client who’s already using it irrespective of their configuration, and without a chance to run in test mode. This also implies that each new version must be compatible with prior versions of the core software. We’re still thinking about how to do that in the best possible way.

Just Three Days After Two Days to Go


Yesterday we finally released Version 5 of time@work (expense@work and forms@work to follow shortly), just three days after we were only two days from completion. As I wrote on Monday, estimating and predicting in the area of software development is immensely difficult (Two Days to Go).

At systems@work we develop specialist software for professional services management, expense management and workflow. Our software is used all over the world.


Version 5 includes many improvements, though, inevitably, not as many as were on my list when we began our development work a year ago, and some improvements weren’t on my list at all. Priorities inevitably change from one month to another in response to the demands of customers and potential customers.

With every new release we must make advances on at least four ‘fronts’:

  • The ‘functional’ front. Every new release must be more capable than its predecessor.

We’ve made the calculation algorithm more powerful by enabling parallel sequences of calculations.

We’ve made it possible for invoices to be emailed directly to clients in Word, Excel or PDF format.

We’ve enabled drilldown ‘sub-reports’ from timesheets and forms.

And more.

  • The ‘technical’ front. Every new release must work with the latest operating systems, browsers, and devices.

We’ve added time capture to the capabilities of our App.

We’re shortly releasing an Android version of the App.

We’ve made some processes faster, such as invoicing and data import.

We’ve provided invoicing and data import capability in the browser. This means that end-users of time@work can now do everything in a browser:

Timesheets – submission and authorisation

Expenses – submission, authorisation and review

Forms – submission, authorisation and review




Skills Matrix


Data Import

Data Export

We’re therefore ever more ‘cloud’ ready.

We’re investing in ‘mobility’ by providing more options through our iPhone and Android Apps.

  • The ‘graphical’ front. We have to keep up to date with graphical fashion.

In this respect, we’ve still got some work to do. I have many faults, but one of them is certainly to think that in the end what matters most is what software DOES. I do believe that, and I probably don’t give enough weight to graphical considerations. But over the last months I’ve heard too many comments that our software is looking old fashioned, so over the next two months we’re going to modify the browser interface radically to bring it up to date.

  • The ‘usability’ front. We have to make our software ever easier to use.

We’ve made it possible to work with forms in ‘page’ mode as well as in ‘grid’ mode.

We’ve made it possible for end-users to import data into forms from Excel spreadsheets. This means that expenses, for example, can be entered into a spreadsheet offline and then uploaded.

We’ve added search capability and two-column lookups in the App.

But in this area , also, there is more to do. We’ll be looking at improvements in Planning and the provision of responsiveness in search tools so that searches are conducted as characters are typed.

I have a list of hundreds of suggestions from customers and colleagues, and I have lots of ideas of my own. Plenty of work to do!

Countdown – Two Days to Go


Building software isn’t necessarily more difficult than building a building or a tunnel. You don’t get wet, or get mud on your boots. You don’t work with dangerous machinery or risk falling from a high place. You don’t need a hard hat to write software, you just need a chair, a warm place, a mug of tea and a computer.

building site

You would think that there are fewer unpredictable things in the logical space in which we software developers work (barring the malfunction of other pieces of software that form part of the system – equivalent, I suppose, to malfunctions in materials that form part of a building). It’s not an exploration of unknown conditions, either. You don’t unexpectedly discover that a logical turn takes you into more difficult ‘logical’ space, whereas the digging of a tunnel might take you into muds of different textures and load-bearing capability.

Assuming that requirements don’t change, there should be nothing unexpected when you’re programming, and nothing should get in your way.

So, why is it so difficult to finish software systems on time?

Perhaps the answer lies in the fact that whereas a building is conceived fully before construction starts – its outline, its height, its weight, and all its components and how they’re to be put together – the details of a software system are ‘worked out’ as it’s developed. A full description of it would be the system itself. Perhaps it’s like the development of a mathematical proof. The destination, the theorem, may be known in advance, but the tortuous path towards it has yet to be described. The full description is the solution.

We’re just two days away, we hope, from releasing a new version of time@work. We’re late, of course. We should have been two days away some weeks ago (perhaps months, if I’m really honest). But I’m not complaining. This is the way development goes. We’ve moved the goalposts a little, we’ve found some things more difficult than we’d expected. We’ve reversed out of wrong turnings when the ‘final’ version of a new feature wasn’t as easy to understand and use as we’d imagined. We’ve sometimes not anticipated that a change in one part of the system would cause logical problems in others. Who can eliminate such issues from the software development process?

It happens every time. Even after years, our estimates are sometimes wildly inaccurate. I hesitate to abandon estimation, since in software development you must choose between priorities, and knowing how long something will take and therefore how much it will cost is an important component of that judgement. I’m still not ready to shrug my shoulder and go down the route of ‘It will take as long as it takes.’

But it’s wonderful to be just two days away (or three, or four, perhaps) from Version 5. It’s been a year since we produced a major new release, and this one contains some exciting new features. I’ll list them when we get there in a few days time but for the moment we’re doing final assembly and a bit of cleaning up.

  • We need a revised demonstration database to issue with the new version. Not only must all the data be updated from 2014 to 2015, but changes have to be made to illustrate the new possibilities in the software.
  • We need to update the system help text with text from the new complete reference guide to the product.
  • We need to make some final graphical adjustments (consistent fonts, colours, styles, new login screens).
  • We need to fix some final bugs.
  • We need to  run a ‘release check’ across the entire product to test as many functions as possible in as many permutations as time allows (testing all of them would take longer than the lifetime of our solar system).

We do this with a series of iterations of the product. The problem is that this means we’re tilting at a moving target. I received a new iteration on Friday and worked on it over the weekend. Everything that wasn’t working before worked, but one thing that worked in the previous iteration didn’t work in this one.

Perhaps just one more iteration, today or tomorrow, and we’ll be ready to release on Wednesday. Fingers crossed.

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.

software package

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:

  1. 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.

  1. 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?

  1. 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.

More questions in a day or two…