Friday, January 1, 2010

The Ghosts of Computing, Past, Present and Future

I hope you enjoy this little piece of poetic (?) foolishness to mark the New Year:

Last night I read a Christmas Book
By Dickens, Charles, I think.
But all at once I fell asleep -
It must have been the drink!

Methought I saw a vision strange
Come slowly into view,
Of IT past and present
And of the future too.

I saw the ghosts of IT past,
I shudder just to say,
With paper tape and overlays,
And punched cards by the tray.

I saw the mighty IBM
With mainframes in profusion,
In massive data centres
Where all was pure confusion.

A multitude of programmers
Their duties never shirked,
Writing Cobol programs
Which never ever worked.

Some users too I also saw
In poses not so quaint,
Looking quite unhappy
And making loud complaint.

And last I saw the CIO.
With worry bent and stooped,
His eyes were glazed, his hair was grey,
And he looked truly pooped....

Then suddenly the vision changed
As stormclouds crossed the skies,
And present-day computing
Appeared before my eyes.

I saw the mighty Microsoft
With Governments pursuing,
And Oracle and S-A-P
Their profits large reviewing.

That multitude of programmers
Still worked there with a will,
Writing C# programs now,
Which did not function still.

The users too were still around,
Unhappy to the bone,
Serving up their loud complaints
In strident, querulous tone.

The CIO was there as well,
And clearly wasn't winning.
His face was lined with worry
And his hair was white and thinning.

And then my vision changed again,
And in a shadowy haze
The future of computing
Appeared before my gaze.

I hid my eyes in abject fear
And hoped to end the night -
The future of computing
Was not a pretty sight!

Web 10.0 was all the rage,
Bill Gates had done a flitter,
And everybody's ERP
Was set to run on Twitter!

A multitude of programmers
Still worked 'till they turned pale,
Using abstruse languages
On programs doomed to fail.

The users now were very quiet
And kept their words at bay,
Because they knew, no matter what,
They'd never get their way.

The CIO was there, in tears
And climbing up the wall.
And in the gloomy light I saw
He had no hair at all.

And then at last my dream had gone
And I from sleep awoke.
A nightmare foul it all had been,
Enough to make you choke.

The ghosts have gone, the gloom has cleared,
I'm filled once more with cheer.
Computing really helps the world,
It's still a great career!

The future's really looking bright,
The past was not so bad,
And we can make this great New Year
The best we've ever had.

So, on this happy New Year's Day
Regards I'd like to show
To programmers, to users,
And the good old CIO!

Have a great 2010!!!

Wednesday, October 21, 2009

In Search of Simple Business Applications

My company is currently developing a very simple, easy to use software package which we hope will enable companies to communicate more easily internally. It will cost very little and be VERY user-friendly.

I mention this, not in the hope of selling it to you, but to highlight a problem. Our market research has identified that a number of major corporations and government agencies could really benefit from this little package, but probably won’t ever take it up. Their IT management say that they already have similar functionality built into their ERP and therefore don’t need it.

The Problem with ERPs

The problem comes from the fact that, while IT management might be theoretically correct, the majority of users within the organisation avoid much of their ERP’s functionality..... because it is too complex.

For me, the term ‘ERP’ always conjures up a picture of a large, amorphous, elephantine suite of applications functions which are very cleverly integrated but too complex – and expensive - to implement properly. And, once installed and the price paid, it then becomes too difficult to justify taking on anything else which might in any way compete with what the ERP offers. ERPs also tend to be expensive and slow to enhance, so meeting the changing needs of users becomes that much more difficult.

Consequently, many users are turned off by the complexity of the ERP. They only use the bare essentials of the ERP’s functionality – enough to meet the corporate requirements of the organisation, but avoiding using other parts of the system as much as possible.

The irony is that the concept behind an ERP is that it should be able to model all, or at least a major part of, the corporate operation. Different functions can be integrated within the ERP, so that data and data processing redundancy can be avoided. Yet I suspect that users miss out on a lot of the benefits because of the complexity problem.

The alternative to the ERP, the “Best of Breed” approach, often simply means selecting a number of different, smaller, ERPs, each servicing a smaller part of the organisation’s functions. And bringing these together can keep the IT group busy for many years, and ultimately results in a bigger, even nastier, overall ‘ERP’!

The Alternative

These days users have PCs with email, word processing, spreadsheeting and other stand-alone applications provided. These applications are designed to be easy to use, and they do not require the discipline which is called for with an ERP. It’s much easier to use these facilities in their daily work than using the comparatively pedantic processes offered by the ERP. So the staff, being human, will inevitable opt to use their PC applications rather than the ERP whenever possible.

My premise is that it’s time for large corporations to come to terms with the reality of smaller applications, following the model which is now popular with PC users. Of course it is necessary to retain large corporate systems to process the organisation’s mainstream production and accounting tasks, but we should draw the line there. Give users smaller, independent PC- and Server-based systems to carry out the other tasks within the company.

This may seem to some to be a rather luddite-style approach, going back to the simpler applications concepts which were popular in the pre-online data base days. In some ways this may be true, but the computing environment has changed so much of late that a rethink is surely appropriate and desirable.

One could object that simplifying the computing environment and having more stand-alone applications will almost certainly result in some data and processing redundancy. My response is that, in return, it will free up a lot of staff time which is currently spent in dealing with the complexities of the ERP. On balance, I believe, users will actually become more efficient.

So my call today is simple. It’s time to simplify our business applications, take advantage of the greater flexibility which technology now provides, and make it easier for users (ie staff) to do their work.

Wednesday, August 26, 2009

The Importance of Following Up – One of Business Life’s Important Lessons

When I was younger I really enjoyed playing hockey (the field hockey variety, that is). I wasn’t particularly good at it, but it was something I got a great deal of pleasure from, and at school I played regularly for one of the school sides.

A number of us left school for university at the same time, and, since we didn’t want to give up our games of hockey, it was agreed that we’d carry on playing as a group during university vacations. I volunteered to organise the fixtures and selections - and over the next couple of years it became one of the learning experiences of my life!

I found that arranging fixtures with local clubs wasn’t at all difficult, and we generally had a game every week of each vacation during the season. The real problem lay in organising the players. After our very first game, all the players confirmed that they would be available for the following weekend’s game. However when the day came, to my horror only about half of them turned up!

I quickly learnt that this would be a regular occurrence if I didn’t follow up with them during the week before. Naturally I did this, since if the team didn’t turn up it could at the least be very embarrassing!

Before I knew it I was calling the players, not just once, but two or even three times in the week to make sure they were there on game day. Then, and only then, could I be reasonably confident that we would field a full team!

It’s a lesson which I have continued to benefit from in my business life. Of course, the promise of a paycheck makes it more likely (though not certain) that employees will turn up for work than was the case with my hocket team. But what they do when they get there is another matter entirely.

Over the years I’ve continued to learn that constant follow up is absolutely essential to make sure that jobs get done, get done well, and get done on time. This hasn’t always made me popular with my people, but it does make all the difference to our company’s performance. And if I don’t follow up regularly for some reason, the standard invariably slips.

Looking back, I’m grateful to the hockey team which taught me – albeit the hard way – one of business’s most important lessons at an early stage of my development: regular and consistent follow-up is absolutely critical to business success.

Arnold Cummins

Tuesday, August 4, 2009


My company recently developed a web-based system for a local government client.

The application involved people from a number of different external companies posting information directly into the client's internal data base. These same people were also providing similar information to other local governments, so they were unlikely to be using our system regularly. Under these circumstances, the users would never become truly familar with the operation of our system. It followed that it had to be easy to use.

The unusual thing about this project is that we had three different attempts at designing the system by three different designers before we felt that we had got it right:

- the first designer offered beautifully drawn screens, containg full colour pictures which the client really loved;

- the second design was very cleverly put together. It used only a couple of different pages, and it allowed an expereinced user to manoeuvre around the system quickly and access their data with minimal effort;

- the third design was incredibly simple. There were no pretty pictures, and very plain screen layouts.

Each one of the three was well thoguht out, and to a great extent reflected the personality of the designer. Any one of them might have been acceptable, but we ultimately opted for the third and most basic one. It was very simple, but it was entirely intuitive, and required no prior training on the users' part to be able to use it.

Of course, it cost us more to design the system three times, and it isn't something we make a practice of doing; but in the end we gave our client the best possible result.

It seems to me that there is a lesson to be learnt from this experience. When members of the public are going to use a web-based system, the critical thing is not the beauty of the page or the cleverness of the design. These are both valuable qualities, but ultimately it is simplicity, intuitive process flow and - above all - absolute ease of use which matter most.

I should make one other point: absolute simplicity does not mean that the system was easy to design. In fact, while all three designers were very experienced and highly competent, the one who developed the simple, intuitive design was the most experienced in the development of web-based systems. It was his prior experience in the field which enabled him to come up with such a great result.

Monday, August 3, 2009


Many years ago I learned a valuable lesson, which is as true today as it was then.

At the time I was employed as an IT specialist by an Australian Government department. The CIO was very concerned that his project managers were not performing well, and he was looking for ways to improve their performance.

After a good deal of thought and consultation, our senior management decided that the solution to the problem was to adopt a very powerful - and very expensive -project management software package which would keep track of everything they did. Since these were the days of the mainframe, the licence was certainly not cheap (in excess of $150,000, as I recollect), but the CIO considered that it was money well spent if he could get his project managers to perform better as a result.

The licence was obtained, the package installed, and all the project managers were given extensive training on how to use the new system. It was then introduced to the organisation with a fanfare.

And the result? The project management didn't improve at all; if anything , it actually got a little worse!

The problem was that the project managers themselves weren't performing well. Instead of calling them to account, the senior management were trying to use a computer system to paper over the cracks, and it simply didn't work.

The moral of this story is loud and clear: a computer system in itself will never perform well if the people using it are not themselves performing well. Computer systems support people, they can never replace them, and the systems are only ever as good as the people they support.

And yes, the message is as tue today as it was then....

Saturday, August 1, 2009


A year or two ago we had the opportunity to carry out two consulting studies in two very different and quite large public sector organisations. In each case the objective was to assess whether the senior management within the organisation were getting the information they needed from the corporate systems in use.

The Problem
The basis for both studies was that most computer-based business applications today generally do a reasonable job of meeting the needs of operational groups within an organisation. They tend to be good at automating such things as:
· accounts and financial management
· sales
· inventory management
· production
· records management
....and so on – in other words, all the quantifiable tasks carried out by operating staff and middle management to get their work done efficiently and effectively.

The concern was that, good though these applications might have been, they all seemed to have been designed from the point of view of users from middle management down. Little effort seemed to have been made to properly identify the needs of senior management – generally, efforts in that direction were confined to providing multi-purpose report writers and other data analysis tools. In effect they had given senior managers some tools to work with and then left it to them to work out their actual needs. And most senior managers really weren’t using these tools at all effectively.

Our declared intention in both of the studies was to look at the system requirements from the top down rather than from the bottom up. In each case we looked first at the needs of the senior managements – from the CEO down to the upper middle levels – and then assessed the ability of the existing operational systems to meet those needs.

Study Outcomes
The results from both studies were interesting. After some searching interviews we found that senior managers had four distinct types of requirement:

(a) Regular day-to-day information on the performance of their organisation. We established that they were not always getting the information which they needed, and what they did get was frequently too detailed for them. In most cases the needs expressed by senior managers boiled down to information such as key performance indicators and ‘dashboards’, plus a few regular summary reports of overall operational data.

(b) Ad hoc information to allow them to handle unexpected problems and opportunities. This kind of need occurred irregularly, and very often led to completely unpredictable information needs. Managers complained that the tools available to allow them to get this information (report generators, data analysis tools, etc) were generally far too complex for them to use.

(c) Information which lay outside the operations of the business. Unlike more junior staff, their work frequently called for access to this type of information, which simply couldn’t be provided for by the corporate systems.

(d) To the above I should add that much of their work was not data-oriented at all (for instance, a public relations meeting with executives from another organisation probably needs little access to corporate information!)

As a result of our reviews we concluded that (c) and (d) were outside the scope of our studies, apart from recommending some corporate management training in the use of Google and other general-access systems.

We were able to fix (a), and identified some major improvements in the level of management information available. We were able to recommend some excellent KPIs and regular summary reports for ongoing use. We also picked up a number of operational problems within the two organisations which, once resolved, would clearly improve the flow of information to the management.

This left (b) as a significant issue. The problem is that there are many packaged tools available to allow users to delve into the corporate data base and analyse it in all sorts of ways, but they are generally far too complex for anyone but experts to use. Senior managers simply don’t have the time – and often the inclination – to play about with complex systems. True, they can, and do, ask other specialists to get information for them; but this can be quite restricting and is only a partial solution.

Need for Simpler Packages
The solution, I believe, lies in the provision of a simpler form of reporting/analytical tool. And herein lies the problem: the suppliers of software packages of all types have to provide very comprehensive facilities which are able to meet the needs of a vast number of different users – if they don’t, they fear that they won’t sell many packages. This however leads to much greater complexity, and in the case of management information tools it makes them virtually unusable for senior management users!

My personal belief is that packaged systems in general have become far too complex. The time is ripe, I believe, for a series of software packages which simply do the basics and are easy to use (the same is also true of mobile phones!). This is as true for data analysis tools as for other types of application.

My conclusions are two fold.

Firstly, senior managers do indeed know what they want, but the IT community usually isn’t giving them what they need. They really have been overlooked in the pressure to get the corporate systems in place. The sort of study which we carried out certainly assisted them in having their needs met more effectively.

Secondly, there is a real need for a simple, easy-to-use data analysis tool which readily allows the organisation’s data elements to be mapped and then used by senior managers to produce the ad hoc information they need from time to time. This need not be complete information – if the manager needs to massage the information a little, so be it. The main thing is to have ready access to it.

As a post script, we later developed such an ad hoc facility for another, very large, Australian corporate, and we found it to be well received. The need truly is there.