Back to the beginning

This past month I've had the opportunity to meet up again with Jim Groark, the man who was influential in getting me where I am today in business. In the photo below, I'm on the left and Jim is on the right.

Background

In the late 1970's I worked for Ampol Petroleum, a large Australian oil company, as Procedures Analysis Executive. (Procedures Analysis was the Ampol name for what was generally referred to at the time as "Organisation and Methods".) I'll have more to say about Ampol in a separate post. Our team was responsible for all the manual systems and human aspects of computer systems throughout the company. Most of the effort was spent on systems analysis, procedure manuals and form design.

One of the staff who worked for me had been trying to talk me into leaving Ampol and to go into business with him as a consultant, but I had been rejecting the idea as a daunting prospect. Then in January 1979, I received a phone call from a man who introduced himself as the Managing Director of a large international consulting firm. This was a big enough surprise, but his next words were even more stunning. He said: "I'd like you to quit your job at Ampol and come and work for us". I decided to talk more and hear what he had to say.

The result was that I took his advice and entered into a partnership with my other work colleague and we subcontracted to the consultant. I need to point out that this is not the person I met this past month.

The project

The project was with the South Australian Police. They were developing a new computer system to handle firearms licensing and gun registration—a highly controversial topic at that time, just as it is now.

They had hired two specialist computer people who were experienced in such systems but had no one on the team with experience in the human side of the system—an issue that was very important given the emotive nature of the subject in South Australia. Jim Groark was one of these specialists. They also planned to use microfilm as an integral part of the system and had also hired Australia's top micrographics expert for the team.

They showed me the systems specifications and procedures that the Police had drawn up and it didn't take very long to realise that what they were trying to do was not going to work with the procedures they had written. I was able to convince them that the procedures needed to change. Fortunately, nothing had been done to develop the computer system at that stage other than some rough specifications.

So I rewrote the specifications and procedures in a radically different manner, handed them to the computer consultants to see if it would work for them. They agreed that the new specs were workable and I went ahead and wrote the manual procedures and designed the computer data entry forms that the public would have to fill in to register their guns or get a firearms licence—ALL THIS BEFORE ANY COMPUTER PROGRAMS WERE WRITTEN. This was a radically different approach to anything I had ever worked on at either AMPOL or at Amalgamated Wireless Australasia Ltd (AWA), my previous employer. I was also on the executive of the Australian Institute of Systems Analysts (later to become its Federal President) and I'd never heard of anything like it there either.

One of the issues we faced was that because of the highly controversial nature of the legislation, the forms had to sit in Parliament for a number of weeks to be approved by the politicians. The new State Government had decreed that all forms had to be in black and white. They didn't want anything that reminded them of the colorful activities of the previous State Premier. On top of that the State Emblem was a black and white "Piping Shrike" (a local name for a magpie), but we decided to design the forms in colour anyway and let them sit in parliament. The new colored forms were accepted.

To cut a long story short, the procedures worked—the forms worked—and the system was implemented with barely a hitch.

Below are examples of four of the forms we designed. If we did them today they'd be a lot different as we still had a lot to learn about good form design, but at the time they were a radical departure from what was normally available. The aim was to make them not only usable, but as attractive as possible to overcome resistance. Applicants were going to have to go into a police station to fill out the forms, pass a licensing test as well as to take their guns in for registration.

The keys to success
The major key to the success of the system was something that I've tried to get systems and computer people to do ever since—that is, to get the procedures and manual systems working BEFORE attempting to write the programs. But it seems that computer people generally think they know best and then they wonder why so many computer systems fail. And many computer systems DO FAIL because the human side is forgotten. Keith London wrote a superb book on this many years ago called "The People Side of Systems". It is technically out of date, but well worth reading if you can find a copy second hand.

Another key to success was the use of white data entry spaces on a colored background. Today this is common practice, but back then it was pioneering design. I don't recall ever seeing this practice up to that point. In fact, it was very rare to even see color on forms. I am aware that some designers in Canada and the UK were experimenting with the same basic approach around the same time. One US company (Moore Business Forms) came up with a different technique some time later where they had coloured data entry boxes on a white background, which they patented and named "Keytrack". The use of colored boxes hinders legibility whereas white boxes improve it.

The Project Team

Another key to success was the project team. When I look back over the past 30 years that I've been a consultant, this was by far the most successful project I've worked on. As stated above, much of the success was getting things done in the right sequence and making sure people came before technology. But another important key was the project team.

Below is a photograph of some of the surviving members of that team as they are today.

Left to right: Consultant Jim Groark — Chief Inspector Brett Woollacott (Seargent at time of project) — Seargent Michael Grant — Chief Inspector Bob Jolly (Seargent at time of project). All three police officers have retired from the Department.

The head of the team was Laurie McEvoy who was the driving force behind the project and one of the best team leaders I've ever worked for. Laurie retired as a Chief Superintendent in 1989 and passed away in 2002.

My most memorable recollection is that they were truly a team and an extremely happy team at that. Working with them was a real delight.

POSTSCRIPT
Well it was a great day to meet up again with my old colleague Jim and his family. I had been able to visit with them in Arizona on a couple of visits to the USA, but it was good to have them visit us back in Australia and for them to catch up with most of the old team we had worked with in South Australia. It was this project that got me started as a consultant.

Added two new entries to Rob's Perspective

The following short articles have been added to Rob's Perspective:

1. Failure to Learn - Anthony Hopkins - Lessons for IT and forms management

This paper is based on lessons learned from Anthony Hopkins in his books on gas plant explosions in Australia and Texas and how they apply to IT and forms management.

2. Procedures – Handling choices within a choice

This paper deals with a new Playscript approach to handling complex routing in procedure manuals.

Shana - FileNet - IBM - eForms - Major Decision

When specialised electronic forms software was introduced in the mid 1980’s it was fill and print only. Company’s such as Shana, Delrina, Jetform, Adobe, Apple and BLOC Development Corporation were all developing various types of electronic forms software. It was another five years before workflow-based electronic forms software became available when Canadian company, Shana Corporation, added the functionality to its Informed software. Shana was subsequently acquired by FileNet, which in turn was acquired by IBM with the name changed from Informed to IBM FileNet eForms.

In my opinion, IBM FileNet eForms is the best electronic forms software available. It lacks some of the features of other software, but is so easy to use and has so many built-in functions that it surpasses everything else overall. Shana even created a web-based server known as Forms Manager so that forms created in Informed Designer for their desktop Filler software could be run as HTML forms in a web browser.

Major decision by IBM changes eforms landscape

We’ve recently been notified by IBM that as of January 31 2009 they have decided to discontinue the Forms Manager server and no longer make the Desktop eForms software available to end users as a stand alone product. If you want Desktop eForms you have to purchase FileNet P8 content management software and then pay extra for the eForms software as an add-on feature. The decision doesn’t directly affect existing eForms users who may still be able to obtain support under existing contracts depending on which version of the software they are using. But organisations wanting a LOW-COST and VERY powerful electronic forms solution will have to look elsewhere.

About a year before acquiring FileNet, IBM’s Lotus Team purchased PureEdge, renaming it Workplace Forms and then changing the name again to Lotus Forms.

I've had a chance to look at the latest release and I want to thank the Lotus Team in Canberra for their co-operation. Version 3.5 is a vast improvement over the earlier version. The interface is still not as slick as the FileNet or Adobe products but it is way easier to use. It also has a much stronger array of built in calculations than I'd seen previously and that brings it more into line with the function list of FileNet eForms, which had the most comprehensive set of functions available.

Given that FileNet eForms cannot be purchased without also purchasing P8 Content Management (or other P8 offerings), Lotus Forms is a much more viable solution for organisations wanting only electronic forms.

Lotus Forms also has some great functionality that is lacking in the FileNet product since it uses XML and is able to create dynamic forms. I agree with many forms professionals that "dynamic forms" is often a sales gimmick and has its downside, but I've come across numerous situations where it would have been very useful. So I'm now looking forward to what we can do with it.

Lotus Forms now has a converter for both PDF forms and FileNet ITX templates. I did try converting FileNet eForms into Lotus and it brought over the layouts reasonably well, but at this stage not the calculations and intelligence. Much depends on how much intelligence is built into the FileNet form. I understand that the converter was mainly for converting fill and print forms, not the highly intelligent forms that FileNet can produce. Hopefully that will come in the future. It also brings across boxes that aren't fields as individual lines and these need to be replaced.

As we learn more about the product, I'll update the BLOG with more information. But at this stage I'm far happier with Lotus Forms than I was previously. Lotus also have a low-cost easy-to-use Designer called Lotus Forms Turbo which is a great idea for a small business, but it isn’t suitable for the complex forms that most larger organisations use as it is primarily for simple forms built using wizards.

My hope is that the IBM Lotus Team will step into the picture and do something concrete with Lotus Forms to make it even easier for ALL form designers to use without having to resort to “wizards” and simplistic designs. Combining the functionality and ease of use of FileNet eForms Designer with the XML capabilities of Lotus Forms would make the product FAR AHEAD of anything else available—and DEFINITELY the very best electronic forms software.

As a final word at this stage, I have another comment for the Lotus Team. Since Adobe and Lotus are both built on the Eclipse platform, my hope is that Lotus can make their product just as easy to use as Adobe's.

But is the Lotus Team prepared to do this? I don’t know, but I sure hope they take up the challenge.

Label field alignment and eye-tracking for online forms

I've just finished reading a paper by Das, McEwan and Douglas on a report of eye-tracking for label alignment in online forms. While it didn't really say anything new, I found it interesting that it confirmed what we'd already learned over the past 25 years through observational studies and usability testing. That is, it is faster for users to have labels for lists of ballot boxes right aligned to the boxes rather than left aligned with a gap between the label and the box.  It is effectively no different to what should generally happen with paper forms.

The paper title is "Using Eye-tracking to Evaluate Label Alignment in Online Forms".

It can be purchased here.

Why do IT people make forms and procedures an after thought?

After forty plus years in the business I'm still amazed at how many IT people think forms and procedures are unimportant.

Go to a meeting and talk to analysts and as soon as the subject comes up their eyes glaze over as if it is too childish to discuss. When we tell them we design forms and write procedures they generally aren't the slightest bit interested.

Sometimes I come across someone who understands as I did recently at a meeting at IBM, but that is rare indeed.

Yet how many systems have you come across that don't do what they are supposed to do because the data collection part of the system doesn't work properly. Most systems start and often finish with forms. They often need forms during the process as well. The trouble is that IT people tend to think that because it is on a computer screen, the form is no longer a form. Yet the same general principles apply as for paper forms. Even worse are the forms often created by web designers who think that they are different again. There are some technical differences due to the way people use the screens over paper entry, but these are only minor compared to issues such as getting the language and data entry sequence right.

I often tell such people that if they don't think forms analysis is a big subject then why does it take a 500 page text book to tell people how to do it?

You'd think that after nearly 50 years of business computing and having systems fail over and over again, that they'd learn some lessons.

When will they ever learn that if they want their computer system to work properly for the end users, then they should get the forms and procedures right FIRST—before they start writing code?

When will they ever learn that forms analysis and procedures analysis are specialised professions?

BFMA Forms Symposium

The Business Forms Management Association has issued the catalog for the 2009 Symposium to be held in San Antonio Texas in April. You can get a copy from our web site at http://www.RBAinformationdesign.com.au.

I wish I was able to go, but it won't be possible this year.

The Symposium is a fantastic place to meet other forms professionals and to learn the latest about forms technology and related issues.

Forms for Rudd Government new projects

I see from the weekend edition of the Australian Financial Review that the new Rudd Government is starting to introduce new projects such as the Dementia Services Pathways Project.

Like all such projects, it will have business forms as part of the services it provides, especially in this case as it involves not just people with dementia, but their carers and service providers.

Given the huge number of errors that occur in data collected on government forms as a result of poor design methodology, my hope is that the Department of Health and Ageing and the company that undertakes the project will consider the needs of the end users.

As I've said numerous times, there is no need for forms that collect bad data.

"We don't use forms in our organization!"

A strange state of affairs
On numerous occasions over the past few years our company has needed to phone organisations to find out whom we should talk to about forms. Many times, when asking to speak to the person responsible for forms, the reply has been along the lines: "we don't use forms in our company!". In one Australian study some years ago, most of the top 100 companies in the country were approached with a similar question and in over 90% of cases the receptionist either gave a similar answer to the above or didn't know who was responsible.

What is the cause of this strange state of affairs? Do these people really believe that they don't use forms? What does the answer mean anyway?

Ever since printed forms were introduced to the Western world by Gutenberg in 1454, they've been regarded as simple documents that virtually anyone can produce, and that idea hasn't changed, so it's no wonder that we get the responses we do. People, from management to the newest operative, just don't take forms seriously. Every forms analyst can tell you about the strange responses they get when asked what sort of work they do. if they tell people they "design forms" they normally get a puzzled look and a question like, "you mean to say someone actually DESIGNS forms?". I've often said that because we learn drawing in kindergarten, and since people consider forms to be just drawing lines, boxes and words, then form design is considered to be kid stuff. It isn't!

The real problem
Because we treat forms so lightly, business and government is faced with enormous problems that remain untouched. Repeated studies have shown that between 80% and 100% of filled out forms have one or more errors. The cost of correcting those errors is astronomical. In one study in Australia, we found close to 100% of a government application form wrongly filled out and needing to be returned to applicants. There were over 500,000 applications each year. Even using conservative estimates to correct the errors and process the paperwork as well as basing costs on wages only (without all the normal add-ons), we estimated that it was costing this department over 2 million dollars per year just to correct errors on that one form. Remember that this is not just an isolated case. It occurs in most organisations and with the vast majority of forms. Consider large government departments and organisations such as banks with thousands of forms—the cost becomes almost too large to imagine.

Where this leads
This sad state of affairs means that in most organisations, NO ONE is responsible for even basic form design, let alone responsibility for content and language. In many organisations every employee becomes an amateur 'form designer'. Even worse, forms are often left in the hands of people who are highly skilled in their particular field, but have little or no training in human communication. Typical of these groups of people are graphic designers, advertising agencies, computer programmers and people who work in printing companies. Many of these people are extremely competent in their relevant professions, but graphic design, advertising, IT and printing skills are not necessarily compatible with human communication skills. Human communication should be taught in universities and colleges to all these people, but unfortunately, what is often taught is nothing more than subjective opinions instead of knowledge based on research and empirical evidence.

It seems that as long as the form looks 'pretty' or follows arbitrary 'rules' of 'plain language' or 'graphic design', the owners of the forms are happy with the result. Then we end up blaming the form fillers for errors and claiming that they are functionally illiterate. I've said many times that it isn't the users who are functionally illiterate, but the people who design the forms—who don't know how to design forms to fulfil their function.

Management worries about the cost of printing and distributing forms and this is often the prime motivator for doing something about them. But this is only a tiny proportion of the total cost. My experience in testing forms over the past 15 years has been that the greatest cost is actually that of dealing with the errors people make. This often goes way beyond just the routine processing cost.

Right now we're seeing an increasing interest in electronic forms with many organisations wanting to place all their forms on the Internet or intranet to eliminate printing, storage and similar costs. Trying to reduce costs is certainly praiseworthy, but I wonder what managers would say if they knew where the REAL cost savings lie. I'll have more to say about this in a future posts and articles on our web site, but for now I'll just comment that putting bad forms on the Internet is not the solution to improving productivity and reducing errors. Management must wake up to where the greatest cost savings lie and not just rely on technology. Part of that is to keep forms in the hands of forms specialists. The Internet is another of the real problems facing organisations where many people with web experience think they know all about communicating. One only has to look at the vast majority of web sites that take ages to navigate (or even find relevant information) to realise how few web page designers really understand human communication.

So what can we do about it?
The first step is to employ people who know about human communication as well as forms analysis and design. Notice I said "employ" people. There's a great move all around the world right now for outsourcing the forms function, but I still believe that it should be in-house in most organisations, especially the large ones. This may sound strange coming from a consultant who earns his living from other people's forms problems, but to give sound advice, I believe I need to be honest.

The second step is to get all the organisation's forms under control and that is no small task. Nevertheless it CAN be done. I've had the privilege of implementing forms management programs in a number of large organisations, both government and private enterprise, and while it takes time, the processes are straightforward. My book Managing Business Forms shows how to do it and we have some other free papers on our web site under the Free Literature heading.

In conclusion:
There is no excuse for any organisation to have problems with its forms. Once management realises the enormous cost of bad forms, the solution is up to them.

US Army Forms Management WWII (1944)

Just received the latest addition to my forms book library: SUGGESTIONS FOR ORGANIZATION OF FORMS CONTROL AND STANDARDIZATION PROGRAM.

I found it interesting to read the objectives and advantages of the program. Naturally, in war time, expenditure savings are vital.

OBJECTIVES:
a. To effect a continuous and substantial reduction in the number of printed and duplicated forms used by all elements of the Army Service Forces.
b. To effect simplification and standardization of sizes and design of all forms remaining in use.

ADVANTAGES:
Achievement of these objectives will produce obvious advantages to all concerned. Savings of approximately $20,000,000.00 a year in expenditures for printed forms are anticipated. Even greater savings in man hours will be achieved by the speeding up and streamlining of procedures which fewer, simpler and modernized forms will bring about.

But is this enough for organizations today?

Scientific research into forms usage over the past few years has revealed that between 80% and 100% of most completed public-use forms contain errors in the data content. The cost to the organization generally far exceeds the printing cost. Yet most organizations aren't willing to take the simple and necessary corrective action, making use of error analysis and usability testing to improve their forms.

Seems like most organizations (government and private) are stuck in the dark ages, generally using form design techniques that haven't changed since World War II days.

I've written a lot more about this in my book Forms For People: designing forms that people can use and will have even more in a forthcoming book on error reduction. But there is no excuse for this disastrous state of affairs.