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.


The Agony and the Indifference


It’s often said that no news is good news, and in the software business, when it comes to system upgrades, no news really is very good news indeed  True, after months of intense creative work (for, after all, software design is an art), one might hope for a little adulation, but I’ve long ago learned to hitch my emotional needs to more dependable areas of life. A well-judged cheese soufflé will almost always inspire acclaim, or a nicely burned bitter-sweet tarte tatin.

As we grow, we learn to avoid risking our feelings. If I were to attempt a novel, or learn the Strauss Oboe Concerto all over again, and play it at the Proms with the Berlin Symphony Orchestra, then I would be suicidal if the best response I got was indifference. But I’ve learned that in the world of business software, silence is the best you can hope for. To the experienced ear it can sometimes sound like adulation.

I was thinking these regretful thoughts in view of our impending release of Version 6 of time@work, our software for Professional Services Organisations. We’ve completely reworked the GUI (Graphical User Interface) so that it looks much nicer, at least by today’s fast-changing standards. How long it will be before we must change it again to avoid new sneers of disapproval, as its look and feel fall from fashion, I cannot predict. And it may be that the early 2010s will make a comeback (as the platform heels and long swirly skirts of the 1970s have done) and we’ll simply have to change it back to what it was. But you have to keep up, and we certainly left it a little longer than we should.

‘That’s not cool enough for our users,’ was the kind of remark I was having nightmares about hearing from potential customers, and existing ones. Business software has too look as nice as Facebook if you want anyone under thirty to use it. Or worse than the overt sneer or the snide remark, there’s just never hearing from potential customers again.

But now with Version 6 we’ve put that unpleasantness firmly behind us. At least I think we have. At least for a while. But the thing is, you can never really know. The sneers and snide remarks need no longer be feared but you can’t expect a warm shower of praise in their place. Silence and indifference are as good as it gets.

We’ve done some early upgrades of the system for our own company, and for an important client. Only two out of our 100 plus users at LLP Group provided any unsolicited feedback – very positive, as it happens. Others, when pressed (by me, and therefore under duress) admitted that we’ve produced a much improved interface, though none of them used the word ‘cool’. As for our clients, they simply remarked that it’s okay.

But, then, that’s all that one can expect, and I take it as ‘admiring with faint praise’ rather than ‘damning with faint praise’. When I think about it, I’m probably as ungenerous as the next man about similar things, so it would be hypocritical to complain. The fact is that IT and Business IT are invisible and unremarkable when they’re working well. A new version of time@work will never be like the latest video game, or a new model of iPhone. Timesheets have yet to become a pleasure for anyone, even if they’re a necessity for a professional services organisation. If the software isn’t actually unpleasant to look at, or isn’t actually difficult to use, that’s a very considerable achievement.

So, lovely though acclaim may be, I know it’s a great achievement to have achieved indifference, and I mean that seriously. We all know how badly software upgrades can go. That there are no complaints, that nothing went wrong, can feel, after thirty years in the business, almost like ecstasy

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.



Timesheets and the Internet of Things


The Internet of Things is creeping closer, or so we’re told.

The idea reminds me of a cartoon in one of the Molesworth books, that satirise and celebrate the awfulness of British boarding school life in the 1950s and 1960s.

Nearer and nearer crept the ghastly THING.


School certainly contained its horrors. Unimaginably ghastly THINGS might creep up on us in the classroom, the boot-room, or the tuck shop, or lurk on the playing-fields, or in the subterranean corridors where we spent our lives queuing for a spoonful of cough mixture. It might be the headmaster’s dog, Spongebag, or Matron, or even an errant dumpling or prune.


(On one occasion at Molesworth’s St Custard’s the prunes (a staple component of school food at the time) revolted.)


But the Internet of Things holds no such horrors. We’re encouraged to welcome the possibility that everything we own will be connected to the internet and to us. We’ll be able to control our homes remotely, turning the heating up or down, and letting the plumber in, or the postman. We’ll water the plants, feed the cat, and even empty the cat tray, from the other side of the world. We’ll tell our driverless car to come and get us.We’ll even be able to watch our house being burgled through the webcams we’ve installed in every room. We’ll be able to remonstrate with them as they do their nasty work.

Control will be complete, and we’ll spend even more time crouched over our PCs or Macs, controlling THINGS. No more getting up to switch a light off, no more wands to wave and click at the TV, the Skybox or to fire up the microwave. Everything will be at the click of a mouse. The browser will be omniscient and omnipotent.

Initially these THINGS, I suppose, will just do what we tell them. But perhaps in time they’ll become autonomous, able to answer back, and converse. The fridge and the cooker will together conspire to cook our dinner, optimising the leftovers into a stylish, healthy and eco-friendly rissole. And then they’ll switch off our pacemakers if we’re insufficiently appreciative. Our bodies, too, will be made of THINGS all wired up and controlled by other THINGS.

But, as it happens, the Internet of Things will solve a challenge we’ve always faced with timesheets. For the last ten years, when presenting and extolling the virtues of our professional services software, time@work, I’ve been asked repeatedly how we can make people submit their timesheets on time. Late timesheets are the bane of every service director’s life.

Submit me, or else (but, sadly, something our system doesn’t do).

timesheet fist

I would tell them about our Workflow Status reporting tool that can produce a list of overdue timesheets for every manager in the company. I would talk about the reminder emails that can be sent as often as required, both to employees who are late with submission and to managers who are late with authorisation.

‘But I can’t actually MAKE people do things,’ I usually say.

‘OK, but can’t you prevent employees from doing other things until they’ve submitted their timesheets?’

Yes, I say, we can prevent submission of expense forms, and so on, until all outstanding timesheets have been submitted, but we can’t interfere with Word or Excel or Google or Facebook to disable an employee’s PC or Mac. Microsoft and Apple won’t let us. Nor can we deliver electric shocks, however much they’re deserved.

Well, the Internet of Things is creeping closer, and times are changing. One of our latest customers, ConnecTec, makers of the devices, and developers of the software, that render THINGS animate (at least in the Internet of Things sense) has asked us to link our timesheet reminder module to their employees’ domestic devices. (They encourage their employees to link their devices to the internet for free, but only in return for indemnity from the consequences.)

internet of things

So, just as you can link a scanner and a barcode reader to our expense management system, we can now link time@work to any compliant domestic device using a standard communications protocol.

ConnecTec are adopting a somewhat ruthless policy on overdue timesheets:

  • One day: set the fridge to defrost.
  • Two days: disable the TV and other entertainment devices.
  • Three days: activate the burglar alarm every hour from three o’clock in the morning.
  • Four days: disable the garage door.
  • Five days: electrocute the domestic pets.
  • Six days: shut the whole house down and lock everyone out.
  • A week: Activate a black hole and consume everything in the vicinity.

If you’re interested in putting time@work at the heart of the Internet of Things, contact your support desk.

But be warned!

exploding house

If it can go wrong, it WILL go wrong


You can never predict how customers will use computer systems, but one thing is certain, everything that can happen, will happen, whether you like it or not.


My company, systems@work, is the author of specialist software for expense management, and for the management of professional services organisations. Ours are highly configurable systems that can be used for a very wide variety of purposes. Even the terminology can be modified by the customer to suit the customer’s needs – one organisation’s ‘project’ is another’s ‘engagement’ or ‘case’, and yet another’s ‘investment fund’. Timesheets, attendance forms, expense forms, purchasing forms, absence request forms, planning, invoicing and reporting – these are some of the system’s possibilities, but each of our customers will set these up and use them in different ways. There is no right way to use our software, and however they set it up and use it, our customers must expect it to work.

Some years ago a few of our customers asked us to develop a new feature. Especially because end users might be scattered across the globe, they needed their administrators and first-line support staff to be able to log in ‘as if’ they are another end-user. And no, such end-users wouldn’t do any updates, they’d just be looking at the system as if through the eyes of the user they are trying to help, and yes, they wanted the end user to stay logged in whilst the administrator did his or her diagnosis, so both users could look at the same screen together.

So, we provided a highly restricted option called ‘Identity Switch’ that enables one end user, the administrator, we supposed, temporarily to log in as another.

Having two end users logged in to a system is uncomfortable. In our system, as in many, there are all sorts of temporary tables and sets of records that are identified by the end user’s name, and if two users are updating the same set at the same time you can create logical chaos. For that reason, we make it impossible for two users to login at the same time with the same user credentials. If they attempt it, the system says no.

Except, of course, for the administrator or support employee using the new Identity Switch function. We assume they will be careful, conscientious and that they understand the dangers of using Identity Switch to do updates in the system on behalf of the other user.

But you can never predict what users can do, and if there’s something you don’t want them to do you must prevent it, not merely advise them against it. Even if it’s more coding work up front, it will save you time later.

Over the last few months we’ve received a small flurry of reports of a few links between records getting lost.  It worried us, of course, and we spent many days investigating how it might have happened, finally discovering that it happened when Identity Switch was used. It turned out that Identity Switch was used for purposes way beyond those we had anticipated, not in exceptional circumstances, as we had recommended, but as part of the normal business process.

‘We warned you,’ we might say.

But what would be the point? We’ve still got to spend hours and hours diagnosing and repairing the problem.

There is no moral high ground to occupy if you’re a software developer. You can try to occupy it, but you’ll obtain no advantage. You simply cannot tell your users how your software ‘should’ be used, especially if you’re trumpeting its configurability. If it can go wrong, it will go wrong. If it can be ‘misused’ it will be.

In reality, there’s no such thing as ‘misuse’. If there’s something you don’t want your users to do, you must stop them doing it, not merely advise against it.

We’re working on it!

Keeping an Eye on Projects


Whether you’re a lawyer, an IT consultant, an engineer, or working in PR, architecture, or for an advertising agency, or indeed any other kind of professional service organisation, it is your time that is probably the chief determinant of project cost, and the fees that your firm will charge to your customers. Sometimes it’s a matter of adding up all the time you’ve reported in your timesheet and multiplying it by a fee rate; sometimes your firm will have estimated how much time is needed for a project and calculated a fixed price for a well-scoped piece of work. In both cases, it’s never quite as simple as you would wish it to be. Sometimes there’s time you can’t charge, and very often a fixed-price project takes more time (and very occasionally less time) than planned.

If you’re working for a professional services company and you’re in a position of responsibility you’ll be familiar with these month-end questions:

‘How much of your Work in Progress (the time you haven’t yet billed) will you be able to bill? How much is it really worth?’

‘How is your fixed price project going? Do you expect it to take more time or less time than planned? ‘

You’re asked these questions especially sternly by your firm’s Finance Director, since he or she is responsible for calculating revenue for the month that’s closing, and revenue depends on the value of the project time that you’ve reported for the month. This is not just a matter of multiplying time by fee rate.

At year-end it’s even more important, since it’s your annual P&L that statutory and corporate auditors will analyse, and if you’re not too careful your managers will defer serious consideration of the value of Work in Progress and the progress of Fixed Price Projects until then. That can mean unpleasant surprises in the last month of the year.

At LLP Group we use systems@work’s time@work to keep an eye on what’s going on. Adjustments to Work in Progress value and the value of time in Fixed Price Projects are tracked as discounts or uplifts to the values that are calculated from timesheets. We can track how these values are discounted or uplifted when billed or written off, and we can track when this is done.

It’s never pleasant to discount work, but it’s some consolation when it’s done steadily throughout the year, rather than all in the last month. Take this report, for example:

project virtue

This, from one division of the company, shows the month in which work was executed down the left y-axis and the month in which the  value of time was increased or decreased along the top x-axis. What we see is that the value of time is written up or written down in the month in which it is recorded, or a month or two later. This is virtuous. This division doesn’t execute many fixed price projects and doesn’t hold Work in Progress for long.

lessvirtuousThe matrix, above, shows data for another division, one which executes more fixed price projects. It’s clear that decisions about the write down or write up of time are made sometimes many months after time is recorded, and as year-end approaches large values are written off. This is less virtuous.

If you’re running a professional services organisation this is the kind of tool you need if you want to avert unwelcome surprises.

When it comes to Fixed Price Projects you might also track the estimates that your project managers give you and track time recorded on the project (green), planned time (blue), and evolving estimated time (orange).

In this case, below, the project manager has seriously underestimated the number of days’ consulting that the project requires. As the project progresses he or she estimates more and more work. The result is that the achieved project rate is nearly 40% lower than the planned rate of 500. It’s probably loss making.


In the more complex case, below, the project has been ‘sold’ on the basis of ‘planned’ time, and as the project progresses the client adds additional scope and additional planned time (though not at the same fee rate). Time estimated by the project manager for the whole project gradually exceeds planned time. The Rates graph shows how the planned daily rate for the project is reduced as the scope of the project increases, and the actual achieved daily rate also declines.

FPP changing project

Whatever kind of service you’re selling, it’s essential that you keep track of the value of Work in Progress and the progress of Fixed Price Projects every month of the year.

systems@work for Android


We’ve just launched our systems@work App for Android mobiles, so (with a little configuration and an upgrade to the central server application) our users all over the world can connect to their company’s systems@work database and submit and authorise forms through their Android mobiles.


It’s hard to find reliable statistics on relative market share for Android and iOS in the business sector (precisely those who might use time@work, expense@work or forms@work), but it’s clear that Android has won at least half the market, and in some areas of the world, much more than half. When, at a recent LLP Group company get-together, I asked my colleagues which of the two they use, a clear majority put their hands up for Android. A couple rather sheepishly owned up to Windows Mobile, but, with apologies to the two of them, for the moment I’ll ignore that opportunity. And the Blackberry one too.

At least Android phones can be cheap. When we reached the final stages of testing the Android version of systems@work a couple of months ago, I went out and bought myself one for just 40 GBP (with about ten minutes of free local phone calls thrown in to sweeten the deal). It took me some time to get used to the different style, but once I got inside our App it seemed like familiar territory and our App worked just as well. I was able to submit the invoice for the Android phone, as a legitimate business expense, using the App itself just twenty minutes after I bought it. (That’s logically equivalent to driving home a car salesman in the car he’s just sold you. Or something like that.)

Developing apps hasn’t been a painless experience. The problem for App developers is that the technical environment for App software is utterly different for iOS and for Android. And when it comes to Android you have the additional worry that you must make sure that what you’ve developed will work on the most ‘vanilla’ version of the operating system, because Android can be ever so slightly different on different devices. Apple’s iOS, on the other hand, is always the same (barring new versions).

So, App development is expensive. It took us more than a year to finish the iPhone version and around six months to complete the Android one. At least the web services that read and update the systems@swork database are the same for both Apps.

Our App is complex, though very simple on the surface. When you connect it to your systems@work database, it takes the forms that are defined there, and which are always very different for every one of our systems@work customers, and renders them in your mobile, together with all the lookup lists, date fields, numeric fields, and so on. that you need to fill in.

You can have as many forms as you like – for time entry, for expense entry (in local or foreign currency), for mileage calculation (with the distance between two place names or postcodes being automatically calculated by Bing if that’s what you need), for absence requests, for just about anything. You can photograph a receipt (or the Tower of Pisa for that matter) and record a voice memo. When you’ve finished entering data (online or offline) you can upload your transactions, photos and voice memos, to the server, sending forms for immediate authorisation or feeding the data into forms and timesheets that you can finish off in the browser.



I dream that one day there might be a single programming language that will work for both iPhone and Android, even if we’d then have to write a third version of our App. Stepan, our development manager, tells me that there’s talk in the technosphere about a new language or development environment called Swift that might solve just this problem. I look forward to it, but not tomorrow.

For the moment, and for some considerable time to come, we’re happy to have launched systems@work for Android as a separate App. It’s functionally identical to the one that works on an iPhone, so we’ll go on developing both in tandem, at least until we’ve finally caught our breath and have the stamina to begin again with Swift,

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.