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

I don’t believe in the Cloud


There, I’ve said it. I know it’s a heretical view, but I’m no follower of fashion, whether sartorial, gastronomic, linguistic or professional.

the cloud

But it’s not a simple issue, and I will qualify my views very carefully.

I’m talking of course, of the IT Cloud, that somewhere-nowhere place where software and data are held for private or corporate use. I don’t doubt that it’s a safe, secure and cost-effective place, (and if it’s not yet those things, it could be). And I don’t doubt that when it comes to certain kinds of ‘utility’ applications – word processors, spreadsheets, simple databases, and so on – it makes it easier for people to share data and ideas. There are plenty of benefits when it comes to certain, limited, kinds of Cloud. My objections are confined to the Cloud as it’s promoted for business applications, a field I’ve worked in for more than 35 years.

Business applications are at the core of all medium-sized and large organisations all over the world. Without them things don’t get made, sales don’t happen, deliveries fail, customers become unhappy, profits don’t get calculated, and vital things don’t get bought or just don’t arrive in time. I’m not sure if they save on paper, but they save on labour, doing those repetitive, communicative and administrative things more accurately, consistently and rapidly than humans can ever do them. They reach out across the internet to enable us to order pizza from our living rooms, or buy tickets for flights from one continent to another. They touch are lives hundreds of times a day.

They are immensely complex. The largest of them, such as SAP or Oracle, contain millions of lines of computer code, and trillions of possibilities, and they’re developed by thousands of programmers over millions of man-days. The largest (and most expensive) of them also do absolutely everything that a company needs its business systems to do- from procurement and purchasing, engineering simulation, to distribution route-planning, payroll and career-planning.

The best of them are configurable and don’t need source-code modification to make them work well for a particular customer. Take Infor’s SunSystems, for example, a beautifully designed accounting system that is easily adapted for all sorts of purposes, or systems@work’s time@work, a professional services and expense management package that works for a wide variety of professional services organisations, from consulting and engineering, to law or oil and gas exploration. Neither system comes with source code, so ‘one size fits all’ and each organisation’s quirks are managed through configuration of the software’s parameters. My company – LLP Group – has worked enthusiastically with both of these products for more than twenty years. We love them, but except when life is very simple, I don’t seem them perching entirely comfortably on the Cloud.

The reality is that there is no core business system in the world that does all the mission-critical things that a company needs only through configuration (those vital things that enable it to be competitive). And there’s no core business software system in the world that does everything. There’s usually a need for the integration of several business systems –  time@work with SunSystems and Microsoft CRM, for example – to cover 95% of a company’s needs. Some of these systems, particularly those that bring a particular competitive advantage, may even have been written specifically for one company.

Integration is difficult to do in the Cloud. I take the Cloud, in this context, to be a place where a single instance of a business software system is installed and used by multiple organisations of different kinds – one software version, but configured differently for each organisation. That’s ‘cloud cuckoo’ Cloud in my experience, certainly if we’re considering those essential systems at the heart of a competitive business.

The Cloud is best when it offers either a peripheral function that isn’t mission-critical and is more or less standard across a wide variety of sectors (expense management, for example) , or a function that is essential but can be configured sufficiently to suit most organisations (CRM systems such as Salesforce, for example). But it’s no good for those idiosyncratic areas that make one company stand out from another or when an ambitious fashion-following IT or Operations Director says, ‘I want everything in the Cloud.’

I’ve seen Cloud implementations fail at the first hurdle, especially when it comes to the almost always necessary integration of multiple systems. Integration code is rarely usable by more than one organisation, and as soon as you need something special up there in the Cloud alongside the ‘one size fits all’ copies of your core business software, you’ve descended from the purest Cloud to something that’s merely ‘hosting’, because no one else can use the particular combination of software and integration code that’s been installed and developed for you.

And, even if you’re in the purest Cloud, you’re still vulnerable to what can seem like the arbitrary upgrade of the core software, which is entirely out of your control. Sadly, business software contains bugs, and most companies want to test very carefully before accepting a new version. In the purest Cloud you don’t have that option.

So, no, I don’t believe in the  Cloud. I love the idea that you don’t need your own IT department, that to others can be delegated the responsibility of procuring IT infrastructure, and of ensuring safety, security and performance. That’s hosting or the ‘private Cloud’. But when it comes to the mission-critical functions and very specific integrations on which your organisation depends – forget the Cloud in its most idealistic form.


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.

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.


Undergoing Analysis


It’s a well-worn truism of business systems that there’s no point in a report if it doesn’t change what you do. If you’re to control something you must measure it. Conversely, if you don’t need to control something, then there’s no point in measurement.

Even so, for nerds like me, there might be some pleasure in measurement. Analysis for its own sake.

I love statistics. I am an out-of-the-closet nerd. At school, although I was no genius at mathematics, I wasn’t bad at it either, and I took particular pleasure in statistics, the art of deriving meaning from apparent chaos (yes, and lies too, as they suggest). Whilst I’ve forgotten most of what I knew (nowadays I don’t know my mean from my median) I still love the idea of distilling something interesting, if not useful, from vast reservoirs of data (I think the fashionable term is BIG DATA).


Over a decade ago my company LLP Group sponsored a music competition in the Czech and Slovak Republics. We traipsed around both countries with a jury of four distinguished teacher/musicians, one from each category (strings, woodwind, brass and keyboards) and we listened to nearly two hundred young musicians. We had a relatively simple scoring system that delivered a single number between zero and ten for each player, and at the end of the tour, we promoted the top four from each category to the semi-finals.

I ran the scoring system using an Access database of my own devising, and every morning after I’d crunched the previous day’s numbers I’d produce a report for each juror, laying bare the unconscious stirrings that influenced his or her preferences. I was particularly keen to analyse these biases – a preference for Slovaks or Czechs (nationalism is always a danger in this part of the world), a preference for their own category of instrument, a preference for men or women (numbers I didn’t make public) and their average score and standard deviation. In the case of average score I had great difficulty in convincing them that the lower the average the less influence they might have on the final result. As for standard deviations, they didn’t like the sound of that at all.

Nationalism was a clear bias, unsurprisingly, but I found that each juror was biased not for, but against his or her category of instrument, as if he or she knew exactly where to find fault. As for bias towards men or women, this was fascinating, but I was careful to keep the sometimes surprising results to myself.

The systems@work part of LLP Group produces software for professional services management, which I design, and we’ve implemented the system across the group. In idle moments I speculate on certain questions such as ‘Is utilisation different on different days of the week?’ and ‘Is realisation related to the length of a client engagement?’ Utilisation is a measure of how much available time a consultant spends on client-directed work. Realisation is a measure of how much client-directed work is finally billable. I’m not sure that one can do anything with this knowledge, but it’s fun, and when I looked at all the reports in our system the other day I came across some of the reports I’d idly written a year or two ago to answer these two questions (it must have been a rainy winter weekend).

Here for example, you can see that utilisation is slightly lower on Mondays and Fridays. No surprise there, I suppose. What could one do about it? Well, maybe make Monday and Friday six-hour, rather than eight-hour days, making the midweek days longer ones?



And here you can see that average realisation is not significantly a function of engagement length.


time@work can do all of this (and less!). And no doubt more. Utilisation by nationality, by sex, by age, by client sector? Average engagement length by season? Hmmm…work to do!


For me this is fascinating, but perhaps it is I who should undergo analysis.